República Bolivariana de Venezuela
Ministerio del Poder Popular para la Defensa
Universidad Nacional Experimental Politécnica de la Fuerza Armada Nacional
Bolivariana
U.N.E.F.A.
Núcleo Miranda
Extensión: Ocumare del Tuy
Carrera: Ing. en Sistemas
Semestre: 7MO
Unidad curricular: Arquitectura del Software
Patrones de diseño
Profesor:
Alexis Martínez
Alumno:
Josué Torres C.I: 28.007.339
Ocumare del Tuy 09/12/2022
Patrones de Diseño
Patrón lineal
Abstract Factory (Fábrica abstracta):
1. Intención
Proporcione una interfaz para crear familias de objetos relacionados o
dependientes sin especificar sus clases concretas.
Una jerarquía que encapsula: muchas "plataformas" posibles y la construcción de
un conjunto de "productos".
El new operador consideró perjudicial.
2. Problema
Si una aplicación va a ser portátil, debe encapsular las dependencias de la
plataforma. Estas "plataformas" pueden incluir: sistema de ventanas, sistema operativo,
base de datos, etc. Con demasiada frecuencia, esta encapsulación no está diseñada de
antemano y muchas #ifdef declaraciones de casos con opciones para todas las
plataformas compatibles actualmente comienzan a procrear como conejos a lo largo del
código.
3. Discusión
Proporcione un nivel de indirección que abstraiga la creación de familias de objetos
relacionados o dependientes sin especificar directamente sus clases concretas. El
objeto "fábrica" tiene la responsabilidad de proporcionar servicios de creación para toda
la familia de plataformas. Los clientes nunca crean objetos de plataforma directamente,
le piden a la fábrica que lo haga por ellos.
Este mecanismo facilita el intercambio de familias de productos porque la clase
específica del objeto de fábrica aparece solo una vez en la aplicación, donde se
instancia. La aplicación puede reemplazar al por mayor toda la familia de productos
simplemente instanciando una instancia concreta diferente de la fábrica abstracta.
Debido a que el servicio proporcionado por el objeto de fábrica es tan generalizado,
se implementa de manera rutinaria como Singleton.
4. Estructura
Abstract Factory define un método de fábrica por producto. Cada Factory Method
encapsula el new operador y las clases de productos concretas y específicas de la
plataforma. Luego, cada "plataforma" se modela con una clase derivada de Factory.
Patrón estructural
Composite(compuesto):
5. Intención
Componga objetos en estructuras de árbol para representar jerarquías de
partes completas. Composite permite a los clientes tratar objetos
individuales y composiciones de objetos de manera uniforme.
composición recursiva
"Los directorios contienen entradas, cada una de las cuales podría ser un
directorio".
1 a muchos "tiene un" en la jerarquía "es un"
6. Problema
La aplicación necesita manipular una colección jerárquica de objetos "primitivos" y
"compuestos". El procesamiento de un objeto primitivo se maneja de una manera y el
procesamiento de un objeto compuesto se maneja de manera diferente. No es deseable
tener que consultar el "tipo" de cada objeto antes de intentar procesarlo.
7. Discusión
Defina una clase base abstracta (Componente) que especifique el comportamiento
que debe ejercerse uniformemente en todos los objetos primitivos y compuestos.
Subclase las clases Primitivo y Compuesto fuera de la clase Componente. Cada objeto
Compuesto se "acopla" a sí mismo solo con el Componente de tipo abstracto, ya que
administra a sus "hijos".
Utilice este patrón siempre que tenga "compuestos que contengan componentes,
cada uno de los cuales podría ser un compuesto".
Los métodos de gestión de niños [p. ej. addChild (), removeChild ()] normalmente
deben definirse en la clase Composite. Desafortunadamente, el deseo de tratar
Primitivos y Compuestos de manera uniforme requiere que estos métodos se trasladen
a la clase de Componente abstracto. Consulte la sección "Opiniones" a continuación
para obtener una discusión sobre los problemas de "seguridad" versus "transparencia".
8. Estructura
Compuestos que contienen Componentes, cada uno de los cuales podría ser un
Compuesto.
Menús que contienen elementos de menú, cada uno de los cuales podría ser
un menú.
Administradores de diseño de GUI de filas y columnas que contienen widgets,
cada uno de los cuales podría ser un administrador de diseño de GUI de filas y
columnas.
Directorios que contienen archivos, cada uno de los cuales podría ser un
directorio.
Contenedores que contienen Elementos, cada uno de los cuales podría ser
un Contenedor.
Patrón de comportamiento
Chain responsability (Cadena de responsabilidad):
9. Intención
Evite vincular al remitente de una solicitud con su receptor dando a más de
un objeto la oportunidad de manejar la solicitud. Encadene los objetos receptores
y pase la solicitud a lo largo de la cadena hasta que un objeto la maneje.
Solicitudes de lanzamiento y abandono con una sola canalización de
procesamiento que contiene muchos controladores posibles.
Una lista enlazada orientada a objetos con recorrido recursivo.
10. Problema
Existe un número potencialmente variable de objetos "manejador", "elemento de
procesamiento" o "nodo", y un flujo de solicitudes que deben manejarse. Necesidad de
procesar de manera eficiente las solicitudes sin relaciones y precedencias de
controlador de cableado fijo, o asignaciones de solicitud a controlador.
11. Discusión
Encapsule los elementos de procesamiento dentro de una abstracción de "tubería"; y
hacer que los clientes "lancen y dejen" sus solicitudes en la entrada de la canalización.
El patrón encadena los objetos receptores y luego pasa cualquier mensaje de
solicitud de un objeto a otro hasta que llega a un objeto capaz de manejar el mensaje.
El número y tipo de objetos handler no se conoce a priori, se pueden configurar
dinámicamente. El mecanismo de encadenamiento utiliza una composición recursiva
para permitir que se vincule un número ilimitado de controladores.
Chain of Responsibility simplifica las interconexiones de objetos. En lugar de que los
remitentes y los receptores mantengan referencias a todos los candidatos a receptores,
cada remitente mantiene una única referencia a la cabeza de la cadena y cada receptor
mantiene una única referencia a su sucesor inmediato en la cadena.
Asegúrese de que exista una "red de seguridad" para "atrapar" cualquier solicitud
que no se atienda.
No utilice la Cadena de responsabilidad cuando cada solicitud solo la maneja un
controlador o cuando el objeto del cliente sabe qué objeto de servicio debe manejar la
solicitud.
12. Estructura
Las clases derivadas saben cómo satisfacer las solicitudes del Cliente. Si el objeto
"actual" no está disponible o no es suficiente, entonces delega a la clase base, que
delega al objeto "siguiente", y el círculo de la vida continúa.
Múltiples manejadores podrían contribuir al manejo de cada solicitud. La solicitud se
puede transmitir a lo largo de toda la cadena, con el último enlace teniendo cuidado de
no delegar a un "siguiente nulo".
Strategy(Estrategia):
13. Intención
Defina una familia de algoritmos, encapsule cada uno y hágalos
intercambiables. La estrategia permite que el algoritmo varíe
independientemente de los clientes que lo utilicen.
Capture la abstracción en una interfaz, oculte los detalles de implementación
en clases derivadas.
14. Problema
Una de las estrategias dominantes del diseño orientado a objetos es el "principio
abierto-cerrado".
La figura demuestra cómo se logra esto de forma rutinaria: encapsule los detalles de
la interfaz en una clase base y oculte los detalles de implementación en las clases
derivadas. Luego, los clientes pueden acoplarse a una interfaz y no tener que
experimentar la agitación asociada con el cambio: ningún impacto cuando cambia el
número de clases derivadas, y ningún impacto cuando cambia la implementación de
una clase derivada.
Un valor genérico de la comunidad de software durante años ha sido "maximizar la
cohesión y minimizar el acoplamiento". El enfoque de diseño orientado a objetos que se
muestra en la figura tiene que ver con minimizar el acoplamiento. Dado que el cliente
está acoplado sólo a una abstracción (es decir, una ficción útil), y no a una realización
particular de esa abstracción, podría decirse que el cliente está practicando un
"acoplamiento abstracto". una variante orientada a objetos de la exhortación más
genérica "minimizar el acoplamiento".
Una caracterización más popular de este principio de "acoplamiento abstracto" es
"Programa para una interfaz, no una implementación".
Los clientes deberían preferir el "nivel adicional de direccionamiento indirecto" que
ofrece una interfaz (o una clase base abstracta). La interfaz captura la abstracción (es
decir, la "ficción útil") que el cliente desea ejercitar, y las implementaciones de esa
interfaz quedan efectivamente ocultas.
15. Estructura
La entidad de interfaz podría representar una clase base abstracta o las expectativas
de firma del método por parte del cliente. En el primer caso, la jerarquía de herencia
representa un polimorfismo dinámico. En el último caso, la entidad de interfaz
representa el código de plantilla en el cliente y la jerarquía de herencia representa el
polimorfismo estático
.
