Edson ezequiel andi jipa- Tarea A 1

Vista previa del material en texto

Lenguaje de programación IV 
Tarea Académica 1 
EDSON EZEQUIEL ANDI JIPA 
Docente: Ing. Angel Alberto Marthans Ruiz 
 
Tarea Académica: Investigar los patrones de diseño de código: (propósito, 
problema, solución y ejemplo de código) 
 PATRONES CREACIONALES(SINGLETON) 
Los patrones de creación proporcionan diversos mecanismos de creación de 
objetos, que aumentan la flexibilidad y la reutilización del código existente de una 
manera adecuada a la situación. Esto le da al programa más flexibilidad para 
decidir qué objetos deben crearse para un caso de uso dado. 
 
Estos son los patrones creacionales: 
 
 
ABSTRACT FACTORY 
En este patrón, una interfaz crea conjuntos o familias de objetos relacionados sin 
especificar el nombre de la clase. 
 
 
BUILDER PATTERNS 
 
Permite producir diferentes tipos y representaciones de un objeto utilizando el mismo 
código de construcción. Se utiliza para la creación etapa por etapa de un objeto complejo 
combinando objetos simples. La creación final de objetos depende de las etapas del 
proceso creativo, pero es independiente de otros objetos. 
 
FACTORY METHOD 
 
Proporciona una interfaz para crear objetos en una superclase, pero permite que las 
subclases alteren el tipo de objetos que se crearán. Proporciona instanciación de objetos 
implícita a través de interfaces comunes. 
 
PROTOTYPE 
 
Permite copiar objetos existentes sin hacer que su código dependa de sus clases. Se utiliza 
para restringir las operaciones de memoria / base de datos manteniendo la modificación al 
mínimo utilizando copias de objetos 
 
 
SINGLETON 
 
Este patrón de diseño restringe la creación de instancias de una clase a un único objeto. 
 
 
 
Propósito: 
El propósito es garantizar que una clase solo tenga una instancia y proporcionar un 
punto de acceso global a ella. 
Ya que el propósito de una clase singleton es que solo se pueda crear un único objeto 
de ella, el mecanismo de creación de objetos debe ser modificado de tal manera que 
se utilice solo una vez el constructor, pero ¿cómo logramos esto? la manera correcta 
es dejar que la clase misma controle su propio constructor y que ninguna otra entidad 
pueda tener acceso a este, en otras palabras, habrá que declarar el constructor como 
privado y programar lo necesario para que este solo sea usado una vez en todo el 
programa. El singleton es uno de los patrones más simples, pero más poderosos en el 
desarrollo de software. 
 
 
Problemas que Soluciona: 
La instrumentación del patrón puede ser del icada en programas con múltiples hilos 
de ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y 
esta no existe todavía, solo uno de ellos debe lograr crear el objeto. La solución 
clásica para este problema es utilizar exclusión mutua en el método de creación de la 
clase que implementa el patrón. 
Los patrones de diseño son soluciones de arquitectura de software aplicables a 
diferentes problemas. El patrón Singleton permite restringir la creación de objetos 
pertenecientes a una clase o al valor de un tipo a un único objeto. 
Propuesta de Solución: 
En los diferentes lenguajes de programación, hay diferentes métodos para lograrlo. 
Para asegurarse de que permanezca con una sola instancia única, se debe impedir 
que los usuarios creen nuevas instancias. Esto se logra mediante el constructor, 
declarando el patrón como “privado”. Esto significa que sólo el código en el singleton 
puede instanciar el singleton en sí mismo. Por lo tanto, esto garantiza que sólo un 
mismo objeto puede llegar al usuario. Si esta instancia ya existe, no se crea ninguna 
nueva instancia. Un posible singleton pattern se ve así: 
Aplicación: 
El singleton se utiliza principalmente cuando hay que completar tareas recurrentes 
en la rutina de un programa. Esto incluye los datos que tienen que ser escritos en un 
archivo, por ejemplo, durante el registro, o los trabajos de impresión que tienen que 
ser escritos en una sola memoria intermedia de la impresora una y otra vez. Dado que 
los controladores y los mecanismos de caché también tienen procesos recurrentes, el 
patrón singleton se utiliza comúnmente para éstos también. 
Ilustraremos su funcionamiento con el ejemplo de una pequeña empresa en la que 
varios empleados utilizan una sola impresora. 
 
 
 
Si un usuario envía una solicitud a la impresora, el patrón singleton hace la 
“pregunta”: “¿Ya hay un objeto de la impresora? Si no, entonces crea uno.” 
Esto se resuelve con un if/then-statement (devolver impresora == cero ?). 
Para evitar el acceso y los cambios, las variables individuales y la impresora se 
establecen como “privadas” en lugar de “públicas”. 
 
 
 
El siguiente paso es “encapsular” a los empleados de la sucursal. Las cadenas para 
los nombres, posición y función dentro de la compañía también se establecen como 
“privados”. 
 
 
 
 
Finalmente, los dos singleton se integran en una rutina de salida. 
 
 
 
 PATRONES ESTRUCTURALES(decorador ) 
Facilitan soluciones y estándares eficientes con respecto a las composiciones de 
clase y las estructuras de objetos. El concepto de herencia se utiliza para 
componer interfaces y definir formas de componer objetos para obtener nuevas 
funcionalidades. 
 
ADAPTER 
Se utiliza para vincular dos interfaces que no son compatibles y utilizan sus 
funcionalidades. El adaptador permite que las clases trabajen juntas de otra 
manera que no podrían al ser interfaces incompatibles. 
 
BRIGDE 
En este patrón hay una alteración estructural en las clases principales y de 
implementador de interfaz sin tener ningún efecto entre ellas. Estas dos clases 
pueden desarrollarse de manera independiente y solo se conectan utilizando una 
interfaz como puente. 
 
COMPOSITE 
Se usa para agrupar objetos como un solo objeto. Permite componer objetos en 
estructuras de árbol y luego trabajar con estas estructuras como si fueran objetos 
individuales. 
 
DECORATOR 
Este patrón restringe la alteración de la estructura del objeto mientras se le agrega 
una nueva funcionalidad. La clase inicial permanece inalterada mientras que una 
clase decorator proporciona capacidades adicionales. 
 
FACADE 
Proporciona una interfaz simplificada para una biblioteca, un marco o cualquier 
otro conjunto complejo de clases. 
 
 
 
 
FLYWEIGHT 
El patrón Flyweight se usa para reducir el uso de memoria y mejorar el 
rendimiento al reducir la creación de objetos. El patrón busca objetos similares que 
ya existen para reutilizarlo en lugar de crear otros nuevos que sean similares . 
 
PROXY 
Se utiliza para crear objetos que pueden representar funciones de otras clases u 
objetos y la interfaz se utiliza para acceder a estas funcionalidades 
 
 
 
 
Propósito: 
Al igual que otros patrones GoF, como, por ejemplo, el patrón Strategy o el Builder, 
el patrón Decorator tiene como objetivo hacer que los componentes del software 
orientado a objetos sean más flexibles y fáciles de reutilizar. Con este fin, el enfoque 
permite a los desarrolladores añadir y eliminar las dependencias de un objeto de 
manera dinámica y, cuando sea necesario, durante el tiempo de ejecución. Esto 
convierte al nombrado patrón en una buena alternativa al uso de subclases, las 
cuales 
pueden complementar a una clase, pero no permiten hacer ajustes durante el tiempo 
de ejecución. 
 
 
Problemas que Soluciona: 
Imagina que estás trabajando en una biblioteca de notificaciones que permite a otros 
programas notificar a sus usuarios acerca de eventos importantes. 
La versión inicial de la biblioteca se basaba en la clase Notificador que solo contaba 
con unos cuantos campos, un constructor y un único método send. El método podía 
aceptar un argumento de mensaje de un cliente y enviar el mensaje a una lista de 
correos electrónicos que se pasaban a la clase notificadora a través de su 
constructor. 
Una aplicación de un tercero que actuaba como cliente debía crear y configurar el 
objeto notificador una vez y después utilizarlocada vez que sucediera algo 
importante. 
 
 
Un programa puede utilizar la clase notificadora para enviar notificaciones sobre 
eventos importantes a un grupo predefinido de correos electrónicos. 
 
Propuesta de Solución: 
Considerar el patrón de diseño Decorator al diseñar un programa es útil por varias 
razones. En primer lugar, utilizar la estructura Decorador conlleva un alto grado de 
flexibilidad: las funcionalidades de las clases pueden ampliarse durante la 
compilación y durante el tiempo de ejecución sin necesidad de recurrir a una 
jerarquía 
de clases basadas en la herencia. Esto mejora significativamente la legibilidad del 
código del programa. 
 
Aplicación: 
Como acabamos de ver, el patrón Decorador no es adecuado para todos los tipos de 
software. Sin embargo, cuando una clase tiene que modificarse a posterior , y 
especialmente en proyectos en los que esto no se puede conseguir mediante el uso 
de subclases, el patrón Decorador es una gran solución. 
En el ejemplo que presentamos a continuación, el punto de partida es un programa 
que permite consultar nombres de personas a través de la clase abstracta 
“Empleado”. Sin embargo, la primera letra de los nombres recuperados siempre está 
en minúsculas. Al ser imposible un ajuste en retrospectiva, se implementa la clase 
Decorador EmpleadoDecorator, que opera en la misma interfaz y también permite 
llamar al método getName(). El decorador recibe una lógica que garantiza que la 
primera letra se escribe correctamente en mayúsculas. En código, esto se escribe 
así: 
 
 
 
 PATRONES DE COMPORTAMIENTO(OBSERVER) 
El patrón de comportamiento se ocupa de la comunicación entre objetos de 
clase. Se utilizan para detectar la presencia de patrones de comunicación ya 
presentes y pueden manipular estos patrones. 
 
Estos patrones de diseño están específicamente relacionados con la 
comunicación entre objetos. 
 
CHAIN OF RESPONSIBILITY 
El patrón de diseño Chain of Responsibility es un patrón de comportamiento que 
evita acoplar el emisor de una petición a su receptor dando a más de un objeto la 
posibilidad de responder a una petición. 
 
COMMAND 
Convierte una solicitud en un objeto independiente que contiene toda la 
información sobre la solicitud. Esta transformación permite parametrizar métodos 
con diferentes solicitudes, retrasar o poner en cola la ejecución de una solicitud y 
respaldar operaciones que no se pueden deshacer. 
 
INTERPRETER 
https://profile.es/blog/que-es-la-programacion-orientada-a-objetos/
Se utiliza para evaluar el lenguaje o la expresión al crear una interfaz que indique 
el contexto para la interpretación. 
 
ITERATOR 
Su utilidad es proporcionar acceso secuencial a un número de elementos presentes 
dentro de un objeto de colección sin realizar ningún intercambio de información 
relevante. 
 
MEDIATOR 
Este patrón proporciona una comunicación fácil a través de su clase que permite la 
comunicación para varias clases. 
 
MEMENTO 
El patrón Memento permite recorrer elementos de una colección sin exponer su 
representación subyacente. 
 
OBSERVER 
Permite definir un mecanismo de suscripción para notificar a varios objetos sobre 
cualquier evento que le suceda al objeto que está siendo observado. 
 
STATE 
En el patrón state, el comportamiento de una clase varía con su estado y, por lo 
tanto, está representado por el objeto de contexto. 
 
STRATEGY 
Permite definir una familia de algoritmos, poner cada uno de ellos en una clase 
separada y hacer que sus objetos sean intercambiables. 
 
TEMPLATE METHOD 
Se usa con componentes que tienen similitud donde se puede implementar una 
plantilla del código para probar ambos componentes. El código se puede cambiar 
con pequeñas modificaciones. 
 
VISITOR 
El propósito de un patrón Visitor es definir una nueva operación sin introducir las 
modificaciones a una estructura de objeto existente. 
 
Propósito: 
El patrón Observer trabaja con dos tipos de actores: por un lado, el sujeto, es 
decir, el objeto cuyo estado quiere vigilarse a largo plazo. Por otro lado, están los 
objetos observadores, que han de ser informados de cualquier cambio en el sujeto. 
El patrón Observer se basa en la idea de centralizar la tarea de informar en manos 
del sujeto. Para conseguirlo, existe una lista en la que los observadores pueden 
registrarse. En caso de modificación, el sujeto los informa uno tras otro, sin 
necesidad de que los observadores lo pidan activamente. 
Problemas que Soluciona: 
El patrón Observer puede ser la solución adecuada a numerosos problemas de 
diseño. Por ejemplo: Imagina que tienes dos tipos de objetos: un objeto Cliente y 
un objeto Tienda. El cliente está muy interesado en una marca particular de 
producto (digamos, un nuevo modelo de iPhone) que estará disponible en la tienda 
muy pronto. El cliente puede visitar la tienda cada día para comprobar la 
disponibilidad del producto. Pero, mientras el producto está en camino, la mayoría 
de estos viajes serán en vano. 
 
 
Por otro lado, la tienda podría enviar cientos de correos (lo cual se podría 
considerar spam) a todos los clientes cada vez que hay un nuevo producto 
disponible. Esto ahorraría a los clientes los interminables viajes a la tienda, pero, al 
mismo tiempo,molestaría a otros clientes que no están interesados en los nuevos 
productos. 
 
Propuesta de Solución: 
Su mayor ventaja es el alto grado de independencia entre el objeto observado 
(sujeto) y los objetos observadores interesados en el estado actual del sujeto. El 
objeto observado no requiere ningún tipo de información acerca de los 
observadores, puesto que la interacción se realiza de manera independiente a 
través de la interfaz de los observadores, que reciben actualizaciones 
automáticamente. De esta manera, ya no se realizan solicitudes en vano (cuando el 
sujeto no se ha modificado desde la última solicitud). 
 
Aplicación: 
El patrón de diseño Observer se implementa sobre todo en aplicaciones basadas 
en componentes cuyo estado, 
• por un lado, es muy observado por otros componentes 
• y, por otro, es modificado regularmente. 
Algunos de los casos de aplicación típicos de este patrón son las GUI (interfaces 
gráficas de usuario), que actúan como interfaz de comunicación de manejo sencillo 
entre los usuarios y el programa. Cada vez que se modifican los datos, estos deben 
actualizarse en todos los componentes de la GUI. Esta situación es perfecta para la 
aplicación de la estructura sujeto-observador del patrón Observer. Incluso los 
programas que trabajan con conjuntos de datos en formato visual (ya sean tablas 
clásicas o diagramas gráficos) pueden beneficiarse de la estructura de este patrón 
de diseño. 
Algunos de los lenguajes más utilizados para implementar el patrón Observer son 
C#, 
C++, Java, JavaScript, Python y PHP. 
En el ejemplo se quiere mostrar un texto publicado por el emisor en los campos de 
texto de varios receptores. Para ello, la subjectclass (emisor, sujeto) añade a la 
observableclass el método addObserver(). De este modo, pueden añadirse 
receptores. Además, se introduce el método setChanged(), que registra cambios en 
el sujeto y hace una llamada a notifyObservers() en caso de cambios, para informar 
así a todos los observadores. 
 
 
Los observadores necesitan, además, una implementación de la interfaz de 
observación, incluyendo el método udpate() y dos argumentos: el objeto observado 
y el cambio en forma de instancia de objeto (ConcreteSubject).