Patrones de diseño
Joan Sebastián Ramírez Pérez
2016
1
Agenda
¿Qué son patrones de diseño?
Patrones POSA
Patrones GOF
Bibliografía
2
¿Qué son patrones de
diseño?
3
“Cada patrón describe un problema que ocurre
una y otra vez en nuestro medio ambiente y, a
continuación describe el núcleo de la solución a
ese problema, de tal manera que se puede
utilizar esta solución un millón de veces, sin
tener que hacerlo de la misma manera dos
veces”
1977, A Pattern Language, Christopher Alexander
4
“ Un patrón es principalmente una forma de
masticar consejos sobre un tema”
– Martin Fowler
“Un patrón describe un problema de diseño
recurrente, que surge en contextos específicos
de diseño, y presenta un esquema genérico
probado para la solución de este.
El esquema de la solución describe un conjunto
de componentes, responsabilidades y
relaciones entre de éstos, y formas en que
dichos componentes colaboran entre sí.”
– Buschmann
¿Qué es un patrón de software?
Solución probada a un problema recurrente.
Solución reutilizable a un problema común en
un contexto dado.
Consideraciones importantes
Un patrón de diseño no es un silver bullet.
Un patrón de diseño no depende de un
lenguaje de programación.
El patrón de diseño en si es la solución, no el
problema.
¿Por qué usar patrones de
diseño?• Vocabulario y entendimiento común para el diseño de
software.
• Suministra alternativas de diseño para tener un software
flexible y reutilizable.
• Construir arquitecturas de software complejas y
heterogéneas.
• Favorece la vida y mantenibilidad del software desarrollado.
¿Cuando debo usar un patrón de
diseño?
Cuando tengo el mismo problema al cual
responde el patrón.
Cuando conozco el efecto colateral que
conlleva el patrón de diseño y es viable la
aparición de este efecto.
Patrones POSA (Pattern
Oriented Software Architecture)
11
Objetivos patrones POSA
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.
Estructura patrones POSA
El volumen 1 de POSA se enfoca a los patrones fundamentales de
arquitectura de software
El volumen 2 de POSA se enfoca a la arquitectura del software para
manejo de concurrencia y de gestión con la red
El volumen 3 de POSA se 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 POSA se enfoca a tratar un modelo para definir
lenguajes de patrones
Distribución POSA
Del fango a la estructura
- Capas
- Tubería-filtros
- Pizarra
Sistemas distribuidos
- Broker (p. ej. CORBA, DCOM, Web
Services, WWW)
Sistemas interactivos
- Model-View-Controller - Presentation-
Abstraction-Control
Categoría patrones POSA
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.
Patrón Layers (Capas)
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
Participantes patrón Layers
Patrón Broker (Mediador)
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.
Ejemplo Broker
Modelo-Vista-Controlador
MVC es un patrón de diseño orientado a objetos.
Divide una aplicación de software dado en tres partes
interconectadas.
Especifica el uso de clases para dividir nuestra aplicación:
Lógica del negocio -> datos persistentes
Lógica de presentación -> como visualizamos los datos
Flujo de la aplicación -> a través del controlador
Patrones GOF
21
Clasificación de los patrones GOF
• Propósito
• Refleja lo que hace un patrón
• Se divide en Patrones de Creación , Estructura y
Comportamiento
• Alcance
• Especifica si el patrón se aplica principalmente a clases u
objetos
• Patrones de Clase y de Objeto
Clasificación patrones GOF
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
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.
Patrones de comportamiento
• 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
Patrones de comportamiento
• 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.
• Template method: difiere los pasos exactos de un algoritmos a
una subclase.
• Visitor: define una nueva operación a una clase sin cambiarla.
Bibliografía
28
Bibliografía
• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides,
John(1995). Design Patterns: Elements of Reusable Object-
Oriented Software. Reading, Massachusetts: Addison Wesley
Longman, Inc.
• Larman, C.: UML y Patrones: Introducción al análisis y diseño
orientado a objetos, 2 ed. Prentice Hall. 2005.
•Buschmann, Frank et al.: Pattern Oriented Software
Architecture, Volume 1: A System of Patterns, Willey & Sons,
1996.

Patrones diseño y arquitectura

  • 1.
    Patrones de diseño JoanSebastián Ramírez Pérez 2016 1
  • 2.
    Agenda ¿Qué son patronesde diseño? Patrones POSA Patrones GOF Bibliografía 2
  • 3.
    ¿Qué son patronesde diseño? 3
  • 4.
    “Cada patrón describeun problema que ocurre una y otra vez en nuestro medio ambiente y, a continuación describe el núcleo de la solución a ese problema, de tal manera que se puede utilizar esta solución un millón de veces, sin tener que hacerlo de la misma manera dos veces” 1977, A Pattern Language, Christopher Alexander 4
  • 5.
    “ Un patrónes principalmente una forma de masticar consejos sobre un tema” – Martin Fowler
  • 6.
    “Un patrón describeun problema de diseño recurrente, que surge en contextos específicos de diseño, y presenta un esquema genérico probado para la solución de este. El esquema de la solución describe un conjunto de componentes, responsabilidades y relaciones entre de éstos, y formas en que dichos componentes colaboran entre sí.” – Buschmann
  • 7.
    ¿Qué es unpatrón de software? Solución probada a un problema recurrente. Solución reutilizable a un problema común en un contexto dado.
  • 8.
    Consideraciones importantes Un patrónde diseño no es un silver bullet. Un patrón de diseño no depende de un lenguaje de programación. El patrón de diseño en si es la solución, no el problema.
  • 9.
    ¿Por qué usarpatrones de diseño?• Vocabulario y entendimiento común para el diseño de software. • Suministra alternativas de diseño para tener un software flexible y reutilizable. • Construir arquitecturas de software complejas y heterogéneas. • Favorece la vida y mantenibilidad del software desarrollado.
  • 10.
    ¿Cuando debo usarun patrón de diseño? Cuando tengo el mismo problema al cual responde el patrón. Cuando conozco el efecto colateral que conlleva el patrón de diseño y es viable la aparición de este efecto.
  • 11.
    Patrones POSA (Pattern OrientedSoftware Architecture) 11
  • 12.
    Objetivos patrones POSA Presentary 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.
  • 13.
    Estructura patrones POSA Elvolumen 1 de POSA se enfoca a los patrones fundamentales de arquitectura de software El volumen 2 de POSA se enfoca a la arquitectura del software para manejo de concurrencia y de gestión con la red El volumen 3 de POSA se 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 POSA se enfoca a tratar un modelo para definir lenguajes de patrones
  • 14.
    Distribución POSA Del fangoa la estructura - Capas - Tubería-filtros - Pizarra Sistemas distribuidos - Broker (p. ej. CORBA, DCOM, Web Services, WWW) Sistemas interactivos - Model-View-Controller - Presentation- Abstraction-Control
  • 15.
    Categoría patrones POSA Patronesde 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.
  • 16.
    Patrón Layers (Capas) Problema: Diseñarun 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
  • 17.
  • 18.
    Patrón Broker (Mediador) Patrónpara 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.
  • 19.
  • 20.
    Modelo-Vista-Controlador MVC es unpatrón de diseño orientado a objetos. Divide una aplicación de software dado en tres partes interconectadas. Especifica el uso de clases para dividir nuestra aplicación: Lógica del negocio -> datos persistentes Lógica de presentación -> como visualizamos los datos Flujo de la aplicación -> a través del controlador
  • 21.
  • 22.
    Clasificación de lospatrones GOF • Propósito • Refleja lo que hace un patrón • Se divide en Patrones de Creación , Estructura y Comportamiento • Alcance • Especifica si el patrón se aplica principalmente a clases u objetos • Patrones de Clase y de Objeto
  • 23.
  • 24.
    Patrones creacionales• FactoryMethod 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
  • 25.
    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.
  • 26.
    Patrones de comportamiento •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
  • 27.
    Patrones de comportamiento •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. • Template method: difiere los pasos exactos de un algoritmos a una subclase. • Visitor: define una nueva operación a una clase sin cambiarla.
  • 28.
  • 29.
    Bibliografía • Gamma, Erich;Helm, Richard; Johnson, Ralph; Vlissides, John(1995). Design Patterns: Elements of Reusable Object- Oriented Software. Reading, Massachusetts: Addison Wesley Longman, Inc. • Larman, C.: UML y Patrones: Introducción al análisis y diseño orientado a objetos, 2 ed. Prentice Hall. 2005. •Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, 1996.