RESUMEN PATRONES

Primeramente en la parte de introducción, ya se explicó que es un patrón , en esta parte veremos

, los elementos principales de un patrón.

Elementos principales de un Patrón:

Nombre del patrón: Es utilizado para describir un problema de diseño, su solución y

consecuencias, representando todo en una palabra o dos.

El problema: Describirá cuando debe aplicarse el patrón y que condiciones deben cumplirse para
poder aplicar dicho patrón. Explicando el problema y su contexto(es decir en que circunstancia se
podrá aplicar)

La solución: Describe un problema de diseño y como un conjunto de elementos lo puede

solucionar. Describe los elementos que forman el diseño, sus relaciones, responsabilidades y
colaboraciones.

Consecuencias: Nos describe los resultados luego de aplicar un patrón, con lo cual se puede
comprender los costos y beneficios cuando se aplica un determinado patrón.

Patrón y Algoritmo:

Los patrones de diseño tienen un cierto nivel de abstracción. Los patrones de diseño no son
diseños tales como la realización de listas y tablas hash que pueden ser codificadas en clases y
reutilizadas.

Según las diapositivas dice que un algoritmo puede ser un ejemplo de implementación de un
patrón, pero es demasiado incompleto, especifico y rígido para ser un patrón.(Según entiendo es
que no necesariamente al mirar una parte de código se podría reconocer que patrón se esta
utilizando)

Los patrones de diseño son descripciones de las comunicaciones de objetos y clases que son
personalizadas para resolver un problema general de diseño en un contexto particular. Solucionan
cuestiones como mantenibilidad, reusabilidad, comunicabilidad y encapsulación.

Mientras que los algoritmos y estructuras de datos están muy relacionadas con lo que es contexto
de optimización o tiempo. Tratando de encontrar la más compacta y eficiente solución.

Por lo tanto los algoritmos y estructuras de datos pueden ser usados en la implementación de uno
o varios patrones (pero no son lo mismo).

Patrón y Framework

Ambos son cosas totalmente diferentes, mientras que un patrón de diseño es un modelo de como
resolver un problema especifico, un framework ya esta listo para usar , normalmente
empaquetado de una manera que hace que crear una aplicación sea mucho mas fácil.

Los frameworks pueden escribirse en los lenguajes de programación y no solo estudiarse sino
ejecutarse y reutilizarse directamente. Mientras que los patrones de diseño deben implementarse
cada vez que se utilizan.
Los patrones de diseño son elementos arquitectónicos mas pequeños que los frameworks . Un
framework típico contiene varios patrones de diseño, pero el reverso no se da. Los patrones de
diseño son menos especializados que los frameworks.

Donde usar los patrones:

Permite determinar el número y tamaño de los objetos.-

Por ejemplo hay patrones de diseño que describen formas de descomponer un objeto en objetos
más pequeños.
Permite especificar las interfaces de los objetos , es decir ayudan a definir las interfaces e incluso
indican que no poner en la interface.

Antipatron:

Se considera a un antipatron como una mala practica. Hay dos nociones de esto:
Aquellos que describen una mala solución a un problema que da como resultado una mala
situación
Aquellos que describen como salir de una mala situación y convertirla en una buena solución.
Ejemplo:

De desarrollo de software

 The Blob (“clases gigantes”).

 Lava Flow (“código muerto”).
 Funcional Decomposition (“diseño no orientado a objetos”).
 Poltergeists (“no se sabe bien lo que hacen algunas clases”).
 Golden hammer (“para un martillo todo son clavos”).
 Spaghetti code (“muchos if o switch”).
 Cut-and-paste programming (“cortar y pegar código”).

De arquitectura

 Stovepipe enterprise (“aislamiento en la empresa”).

 Stovepipe system (“aislamiento entre sistemas”).
 Vendor Lock-In (“arquitectura dependiente de producto”).
 Arquitecture by implication.
 Design by committee (“navaja suiza”).
 Reinvent the Wheel (“reinventar la rueda”).

FACTORIA ABSTRACTA -- Abstracto es algo no especifico, que no cuenta con realidad propia.

Este patrón de diseño permite crear una familia de objetos mediante una interfaz, los cuales
dependan mutuamente sin la necesidad de especificar cuál es el objeto concreto.
Esto significa que factoría Abstracta permite que una clase devuelva una fábrica de clases
(objetos) relacionados, sin especificar explícitamente las clases.
Por eso se dice que es de más alto nivel que el patrón de Factoría.
Este patrón proporciona una de las mejores maneras de crear un objeto.
La Fábrica Abstracta se genera debido a la búsqueda de una manera sencilla de modificar objetos
que tienen atributos comunes pero con ciertas diferencias.
Los clientes o Main solamente tienen que confiar en una interfaz definida por una clase abstracta
y no por una clase particular concreta.

Hay que tener cierto cuidado con este patrón debido a que si se desea agregar nuevos productos,
unos botones por ejemplo, no es tan sencillo; pues hay que cambiar la interfaz de la fábrica lo cual
implica una dificultad en el mantenimiento.

Ventajas:
El patrón aísla el código del cliente de las clases concretas (de la ejecución).
Facilita el intercambio de familias de objetos.
Promueve la consistencia entre los objetos
Uso de patrón factoría abstracta
● Cuando el sistema necesita ser independiente de cómo su objeto es creado, compuesto y
representado.
● Cuando la familia de objetos relacionados tiene que usarse juntos, entonces esta restricción
necesita ser reforzada. Cuando desea proporcionar una biblioteca de objetos que no muestra
implementaciones y sólo revela interfaces.
● Cuando el sistema necesita ser configurado con uno de una familia múltiple de objetos

Diagrama general del patrón:

 Fábrica Abstracta: declara una interfaz para operaciones que crea objetos abstractos de
productos.
 Fábrica Concreta: implementa las operaciones para crear objetos concretos de productos.
 Producto Abstracto: declara una interfaz para un tipo de objeto producto.
 Producto Concreto: define un objeto producto para ser creado por la correspondiente
fábrica concreta. También la interfaz del producto abstracto.
 Cliente: usa solamente la interfaz declarada por las clases AbstractFactory y
AbstractProduct.
Como reconocer un diagrama que tiene aplicado Factoría abstracta:
Para reconocer que un diagrama “X” está usando factoría abstracta se tiene que observar que
cuente con todos los elementos mencionados en la parte superior, pero principalmente con
CLASE ABSTRACTA Y UN PRODUCTO ABSTRACTO; por lo tanto siempre en un diagrama que use
FACTORIA ABSTRACTA se encontrara una familia abstracta que permita crear familias concretas y
un producto abstracto que permita crear productos concretos.
Ya que el programa principal o MAIN solo trabajara con la clase abstracta, es decir usara solo un
método y no le importara que clase concreta le den, porque acepta cualquier clase concreta que
implemente la clase abstracta y solamente ejecutara sus métodos.
En cambio sí se trabajara con la clase concreta, se tendría que definir diferentes métodos para
poder usar las diferentes clases o productos concretos.

En el ejemplo del color y objeto se crea una clase adicional como creador de familias , en dicha
clase se introducen casos para reconocer productos concretos y devolverlos como objetos, no es
NECESARIO crear esta clase creadora de familias, se puede instanciar directamente en el main y
llamar a los métodos mediante un método adicional.
La idea es crear objetos de clases distintas, pero que tienen métodos en común.

ServicioFactoria(interface) es la factoria abstracta que contiene un método de instanciación que devuelve un Producto
abstracto(servicio informatico), en ese caso podrían ser cualquiera de las clases que tiene implementado servici-Informatico.

ServicioInformatico(Interface) es el producto abstracto que contiene los métodos que los productos concretos deberán tener
necesariamente.

Ambos definen los métodos que las clases concretas deberían tener, y son los métodos generales.

Las factorías concretas implementan a la factoría abstracta, son DesignFactory, SoftwareFactory,WebsiteFactory. Estas concretas
instancian los productos concretos que les corresponden.

En el main o cliente,se llama a un método que actuaria como creador de familias, usarServicio(ServicioFactory factory) , este método
acepta como parámetro cualquier factoria concreta(design,software o website), factory puede ser cualquier clase que implemente
ServicioFactory, ya que se esta pasando como parámetro una factoria Abstracta.

Luego se crea un ServicioInformatico el cual puede contener objetos de cualquiera de los servicios concretos, esto por
ser producto abstracto.

ServicioInformatico servicio = factory.crearServicio();

Dependiendo de que factoria se haya pasado desde el main se instanciara un tipo de producto u otro, independientemente de que
tipo de producto sea ,los métodos de el producto abstracto , que son usados en los productos concretos serán ejecutados con
normalidad, porque todos los productos tienen esos métodos.

Finalmente permite manipular la creación de objetos de distintas clases para no crearse los
objetos directamente sino por medio de factorías, si se quiere añadir otro servicio se crearía una
factoria para el nuevo servicio .

https://series.programacionymas.com/patrones-de-diseno-en-java/patron-de-diseno-abstract-
factory---> EN CASO NO ME HAYAN ENTENDIDO T_T
 https://blog.pcollaog.cl/2008/02/11/torpedo-de-patrones-de-diseno/

PATRON OBSERVER

Este patrón es uno de los patrones de diseño de comportamiento. El patrón de diseño Observer es útil cuando estás
interesado en el estado de un objeto y deseas ser notificado cuando hay algún cambio. En el patrón observador, el
objeto que observa el estado de otro objeto se llama Observer (Observador) y el objeto que se está observando se
llama Subject (Sujeto).

Debe ser utilizado cuando:

 Un objeto necesita notificar a otros objetos cuando cambia su estado. La idea es encapsular estos aspectos en
objetos diferentes permite variarlos y reutilizarlos independientemente.
 Cuando existe una relación de dependencia de uno a muchos que puede requerir que un objeto notifique a
múltiples objetos que dependen de él cuando cambia su estado
Una explicación mas clara para entender observer

El contexto de este patrón es cuando tenemos varios objetos observadores y un objeto observado por los
observadores. Los observadores necesitan saber cuando se produce un cambio en el objeto observado. El primer
planteamiento que se puede pensar, es que haya un proceso/thread/tarea/… que se encargara de que los observadores
vayan haciendo peticiones periódicamente el estado del objeto observado, para así detectar cuando sucede el cambio.

El problema surge cuando el intervalo entre petición es muy corto, o hay demasiados objetos observadores haciendo
peticiones al objeto observado, o es necesario que el observador sea notificado inmediatamente después del cambio
del objeto observado.

La solución que se aplicaría usando el patrón Observador, trata de que los objetos observadores se añadan a una lista
de objetos, y el objeto observado notificará el cambio a todos los objetos de esta lista cuando se produzca el cambio.
De esta manera, se produce un cambio de papeles: el observador que tenía la tarea de estar pendiente del cambio,
ahora esta a la espera de que el observador le avise. Vamos a intentar detallarlo:

 el objeto observador necesita ser notificado de los cambios de un objeto observado.

 el objeto observador se añade a la lista de objetos a notificar, de ese objeto observado.
 en el objeto observado se produce un cambio.
 el objeto observado recorre la lista de objetos observadores apuntados, y les va notificando el cambio.

Bajando al lenguaje de programación, se puede conseguir esta relación con una interface y una clase abstracta:

Interface Observador:

 notificar(): los objetos observadores necesitan una función, que será la ejecutada desde el objeto Observado
cuando se produzca un cambio.

Clase abstracta Observado:

 observadores: lista de los objetos Observadores añadidos.

 registrarObservador(Observador): añade el objeto Observador a la lista de objetos a notificar cuando se produzca
el cambio.
 borrarObservador(Observador): elimina el objeto Observador de la lista.
 notificarObservadores(): recorre los objetos Observadores de la lista, para llamarles a su función notificar().

El resultado final, es que los objetos observadores no hacen ninguna petición mientras nada cambie. Cuando se
produce un cambio, son notificados de que se ha producido el cambio. La función notify() del objeto observador se
puede programar de dos maneras:

 cuando es ejecutada, realizan la petición al objeto observado para saber el cambio hecho.
 cuando es ejecutada, recibe un parámetro del objeto observado, con el cambio hecho.

Ya depende del contexto. Se ve claramente que la primera opción requiere de una petición extra.
 Subject: conoce a sus observadores y ofrece la posibilidad de añadir y eliminar observadores. Posee un método llamado
attach() y otro detach() que sirven para agregar o remover observadores en tiempo de ejecución.
 Observer: define la interfaz que sirve para notificar a los observadores los cambios realizados en el Subject.
  SubjectConcreto: almacena el estado que es objeto de interés de los observadores y envía un mensaje a sus
observadores cuando su estado cambia.
 ObserverConcreto: mantiene una referencia a un SubjectConcreto. Almacena el estado del Subject que le resulta de
interés. Implementa la interfaz de actualización de Observer para mantener la consistencia entre los dos estados.

Consecuencias
EL patrón Observer permite variar los sujetos y los observadores independientemente. Se puede
rehusar sujetos sin el rehúso de observadores y viceversa. Permite agregar observadores sin
modificar el sujeto o los observadores.

Algunas ventajas y desventajas del patrón Observer son:

Acoplamiento abstracto entre Subject y Observer. Todo lo que un objeto sabe de sus
observadores es que tiene una lista de objetos que satisfacen la interfaz Observer. Con lo que
podrían incluso pertenecer a dos capas distintas de la arquitectura de la aplicación.

No se especifica el receptor de una actualización. Se envía a todos los objetos interesados

Actualizaciones inesperadas. Se podrían producir actualizaciones en cascada muy ineficientes.