Semana 1 Patrones de Diseño

1. PATRONES DE
DISEÑO
Mg. Richard E. Mendoza G.

5. https://refactoring.guru/es/design -patterns/abstract-factory

6. Un patrón de diseño es, la
solución a un problema de
diseño, el cual debe haber
comprobado su efectividad
resolviendo problemas similares
en el pasado, también tiene que
ser reutilizable, por lo que se
deben poder usar para resolver
problemas parecidos en
contextos diferentes.
PATRON DE DISEÑO

7. A Pattern Language (1979)
Christopher Alexander
• Captura de problemas
esenciales y plantea
soluciones
• Crea un lenguaje para
expresar ideas
arquitectónicas
• Influencia relativa en la
arquitectura
HISTORIA

8. Kent Beck & Ward Cunningham (1987)
mostraron la aplicabilidad que tenían
las ideas de Alexander con el Software
1994, sale a luz el libro que cambiaría
para siempre el concepto de Patrones
de diseño.
Patrones GoF (23)
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides
HISTORIA

9. • Demuestra la madurez de un
programador de software
• Evita reinventar la rueda
• Agiliza el desarrollo de
software
• Se basa en las mejores
prácticas de programación
• Permite utilizar un
vocabulario común
IMPORTANCIA DE LOS PDD

10. • Proporcionar un catálogo de soluciones probadas de
diseño para problemas comunes conocidos.
• Evitar la reiteración en la búsqueda de soluciones a
problemas ya conocidos y solucionados
anteriormente .
• Crear un lenguaje estándar entre los desarrolladores .
• Facilitar el aprendizaje a nuevas generaciones de
programadores .
QUE SE BUSCA CON LOS PDD

11. • Imponer ciertas alternativas de diseño frente a otras.
• Imponer la solución definitiva a un problema de
diseño.
• Eliminar la creatividad inherente al proceso de diseño
QUE SE BUSCA CON LOS PDD

12. Solution
Architect
Arquitecto
Developer Sr
Developer Jr Habla en código
Mezcla patrones con código
Habla de patrones y componentes
Habla de procesos, componentes e integraciones
@sgcampus
PDD Y LA
EVOLUCION PROFESIONAL

13. El programador ve Variables
El programador ve funciones/métodos El arquitecto ve Interfaces
El programador ve Clases El arquitecto ve Componentes
El arquitecto ve Configuraciones
@sgcampus
Cuando
EVOLUCIONANDO A
LA ARQUITECTURA

14. @sgcampus
SUELDO ARQUITECTO

15. Patrones
Patrones de
diseño
Patrones
Arquitectónicos
Afecta la forma de trabajar del todo el
componente, impone restricciones,
así como la forma con que se
comunica con otros componentes.
Tiene un contexto mas pequeño, pues
se centran en la forma en que los
objetos se crean, estructuran o
interactúan con el resto.
@sgcampus
TIPOS DE
PATRONES DE DISEÑO

16. Patrones
Patrones de
diseño
Creacionales
Estructurales
Comportamiento
Patrones
Arquitectónicos
Integración
Seguridad
Web
Controlan la forma en que los
objetos son creados
Define la forma en que las
clases deben de
estructurarse
Define la forma en que los
objetos deben de
comportarse en Runtime
@sgcampus
TIPOS DE
PATRONES DE DISEÑO

17. <subcomponent>
Singleton
<subcomponent>
Factory Method
<subcomponent>
Composite
Patrón de diseño
Component
@sgcampus
EJEMPLO DE
PATRONES DE DISEÑO

18. Negocio
Datos
• Patrón Arquitectónico
• Component (3 layers)
• Presentación
@sgcampus
EJEMPLO DE
PATRONES DE DISEÑO

19. Creacionales
• *Factory Method
• *Abstract Factory
• *Singleton
• *Builder
• Prototype
• *Object Pool
Estructurales
• Adapter
• Bridge
• *Composite
• Decorator
• Facade
• Flyweight
• *Proxy
Comportamiento
• *Iterator
• *Commando
• *Observer
• Templete Method
• *Strategy
• Chain of
reponsability
• Iterpreter
• Mediator
• Memento
• State
• Visitor
@sgcampus
PRINCIPALES DE
PATRONES DE DISEÑO

20. PATRONES CREACIONALES
Factory Method
Crea una instancia de varias clases derivadas
Abstract Factory
Crea una instancia de varias familias de clases
Builder
Separa la construcción de un objeto de su representación
Prototype
Genera una instancia y la inicializa, que puede ser copiada o
clonada.
Singleton
Una clase de la cual solo puede existir una única instancia

21. PATRONES DE ESTRUCTURA
Adapter : relaciona interfaces de diferentes clases.
Bridge: separa la interfaz de un objeto de su implementación.
Composite: una estructura de árbol de objetos simples y
compuestos.
Decorator : añadir responsabilidades a los objetos
dinámicamente.
Facade: una única clase que representa todo un subsistema.
Flyweight : una instancia usada para compartir de manera
eficiente.
Proxy: un objeto que representa a otro objeto.

22. PATRONES DE
COMPORTAMIENTOS
Chain of responsability : una manera de pasar una petición a
una cadena de objetos.
Command: encapsula una petición de comandos como un
objeto.
Interpreter : una manera de incluir elementos del lenguaje en un
programa.
Iterator : acceso secuencial a los elementos de una colección
Mediator: define una comunicación simplificada entre clases
Memento: captura y restaura el estado interno de un objeto.
Observer : una forma de notificar cambios a varias clases.
State : altera el comportamiento de un objeto cuando cambia de
estado.
Strategy : encapsula un algoritmo dentro de una clase.

23. • Presentar y dar el esquema de
arquitectura de software
orientada a patrones (Pattern
Oriented Software
Architecture )
• Mostrar un lenguaje de
patrones que facilitará el
diseño de la arquitectura de
software a partir de los
diferentes patrones .
OBJETIVOS DE POSA

24. • El volumen 1 de POSAse enfoca alos patrones fundamentales de
arquitectura de software
• El volumen 2 de POSAse enfoca ala arquitectura del software
para manejo de concurrencia y de gestión con la red
• El volumen 3 de POSAse enfoca a patrones para la
arquitectura de recursos de computación
• El volumen 4 de POSA conjunta los patrones de cómputo
distribuido y conocidos por la comunidad (incluyendo GoF, PEAA,
EIP)
• El volumen 5 de POSAse enfoca atratar un modelo para definir
lenguajes de patrones
ESTRUCTURA POSA

25. • Patrones de Arquitectura : Layers, MVC, EDA,
etc.
• Patrones de Diseño: Factory Method , Façade,
Strategy , Observer, etc.
• Idioms/Modismos : Manejo de memoria,
uso del lenguaje, convenciones de nombrado,
etc.
CATEGORIA PATRONES POSA

26. Problema:
Diseñar un sistema cuya característica dominante sea una
mezcla de problemas de alto nivel y de bajo nivel
El flujo de comunicación consta de peticiones que van del
nivel más superior al
nivel inferior, y las respuestas en sentido inverso
Contexto:
Una aplicación grande que requiere
descomposición
Solución:
Estructurar aplicaciones que puedan ser descompuestas
en grupos de subtareas, en las que cada grupo de
subtareas está en un nivel particular de abstracción
PATRON LAYERS(CAPAS)

27. Patrón para estructurar sistemas
distribuidos usando el
desacoplamiento de componentes y
que interactúan entre ellos a través
de invocación a servicios remotos. El
mediador coordina la comunicación
de solicitudes del cliente al servidor y
coordina el retorno del resultado del
servidor al cliente, procurando la
transparencia en el formato de datos
y el protocolo de transporte.
PATRON BROKER(MEDIADOR)

28. https://refactoring.guru/es/design -patterns