Modulo 3 Tema 1 2 3

Patrones de Diseño – Introducción
posted on 23/09/2015 by [email protected] | Leave your thoughts
¿Qué es un patrón de diseño?

Un Patrón de Diseño es una solución a un problema de diseño en un contexto:
 El contexto es escenario particular en el que el patrón puede ayudar.
 El problema se refiere al objetivo que se pretende lograr en este contexto.
 La solución facilita el logro del objetivo en el contexto.
Por ejemplo, para dibujar una cara (el problema) mirando al frente (el contexto) se puede
aplicar un patrón al que podríamos llamar “Ovalo Particionado”. Es fundamental asignar un
nombre a un patrón de manera tal que sea posible nombrarlos durante el diseño del software
sin entrar en los detalles de la solución propuesta por el patrón.
¿Qué NO es un patrón de diseño?
Un patrón de diseño no es:
 Un artefacto ejecutable como una librería o un framework.
 Un algoritmo
 Una solución completa a un problema. Es más bien una estrategia que describe los
componentes de una propuesta de solución y sus relaciones en términos generales.
Categorías de Patrones de Diseño

A continuación se mencionan algunas de las categorías o grupos de patrones más usuales;
estas categorías están en permanente crecimiento y adecuación a medida que la experiencia
de diseño en varios ámbitos se va sistematizando en un catálogos de patrones. Al final de este
artículo hay algunas referencias a recursos que describen patrones en diversos ámbitos.
Patrones de creación
Estos patrones están orientados a la creación de objetos y apuntan separar la creación de
objetos de manera tal que el cliente que los requiere no incluya los detalles de la creación de
objetos.
 Abstract Factory. Permite la creación de familias de objetos sin conocer las clases

concretas.
 Singleton. Permite asegurar la creación de un objeto y sólo un objeto de cierto tipo.
Patrones estructurales
Estos patrones están orientados a la composición de clases y objetos en estructuras más
grandes.
 Composite. Permite el tratamiento uniforme de colecciones de objetos u objetos

individules.
 Decorator. Encapsula un objeto y provee nueva funcionalidad.
 Facade. Simplifica la interfaz para acceder a la funcionalidad de un conjunto de clases
Patrones de comportamiento
Estos patrones están orientados a distribuir las responsabilidades de la manera más adecuada
al problema a resolver.
 Command. Encapsula una solicitud como un objeto.

 Observer. Notifica el cambio de estado a una colección de objetos
 Strategy. Encapsula funcionalidad intercambiable y usa la delegación para decidir cuál
emplear.
 State. Encapsula funcionalidad basada en estados y usa la delegación para decidir el
cambio entre funcionalidades.
Referencias
[1] Design Patterns: Elements of Reusable Object-Oriented Software
[2] Patterns of Enterprise Application Architecture
[3] Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
[4] Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web
Services
[5] Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked
Objects
[6] Reactive Design Patterns
Abstract Factory
Abstract Factory
Abstract Factory es un patrón de diseño que separa la creación de un objeto (o una familia de
objetos relacionados) del uso del objeto de manera tal que un cliente que requiera el objeto
solicita la creación del mismo a un Factory (factoría) sin tener que especificar la clase concreta
del objeto que requiere. La decisión del tipo del objeto a crear está encapsulada en el Factory.
Cuando un cliente requiere objeto de tipo “ ProductoA” (que es una interfaz), lo solicita a una
implementación de la factoría, por ejemplo “ Factoría Concreta 1”, que es la responsable de
proveer una instancia de una clase que implementa la interfaz “ProductoA”. Gracias a este
patrón de diseño, el nombre de la clase concreta que implementa la interfaz está
completamente encapsulado en la implementación de la factoría; el cliente, desconoce el
nombre de la clase concreta de la instancia que recibe de la factoría.
Este patrón es muy útil para mantener la inversión de dependencias entre los módulos que
contienen las abstracciones de alto nivel (reglas de negocios y/o casos de uso, por ejemplo) y
los módulo encargados de la construcción de las clases que implementan las abstracciones
definidas en los módulos más abstractos. En otras palabras, con éste patrón de diseño es
posible que un módulo solicite la creación de los objetos que requiere sin tener dependencias
de código fuente con dichos objetos.
La ejecución de la lógica de negocios de una aplicación y la construcción de misma son

responsabilidades que deberían estar asignadas a módulos diferentes con las
implementaciones de las factorías incluidas en los módulos que construyen/inicializan un
sistema (módulos “main”):
AbstractFactory e Inyección de dependencias

Los frameworks para inyección de dependencias y el patrón AbtractFactory pueden
complementarse de manera tal que estos frameworks se empleen como los mecanismos de
creación de objetos en diferentes implementaciones del Factory; es decir, podemos tener
factorías basadas en Spring o factorías basadas en Google Guice. De esta manera, es posible
evitar que módulos abstractos tengan dependencias de código fuente con estos frameworks.
Limitaciones
Una de las limitaciones tiene que ver con el estado en el cuál se crean los objetos; es decir, con
este patrón de diseño y otros similares, se brinda al cliente la posibilidad de solicitar la creación
de un objeto pero (al menos en la versión inicialmente propuesta) no incluye un mecanismo
para inicializar el estado del objeto a crear.
Singleton (Instancia Única)

El patrón Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de
acceso global a ésta instancia. Se emplea cuando una aplicación sólo requiere una instancia de
un objeto como en el caso de las factorías.
La creación de la instancia única es responsabilidad y está completamente encapsulada en una
clase. La implementación de este patrón debe considerar si esta se va a emplear en entornos
de ejecución concurrente.
Finalmente, debido a su utilidad, muchos lenguajes han incorporado facilidades para la

creación de instancias únicas (Scala, por ejemplo).
Referencias
[2] Dependency Injection Inversion
[3] El patrón de diseño Singleton
Strategy y Template Method

Strategy
Con este patrón es posible definir una familia de algoritmos para resolver el mismo problema de
manera tal que se pueda seleccionar el algoritmo de acuerdo al contexto que requiere
emplearlo. Permite en definitiva, separar las variaciones de determinado comportamiento de
manera tal que el contexto más abstracto que las usa (StrategyClient) quede cerrado a los
cambios y nuevas implementaciones de dichos comportamientos.
Template Method
Define el esqueleto de una operación, delegando en las subclases algunos de sus pasos.
Permite que las subclases redefinan ciertos pasos de la operación sin cambiar la estructura
definida en un nivel de abstracción mayor.
Costos y Beneficios
Ambos patrones abordan el mismo problema de diseño: aislar las variaciones en el
comportamiento de ciertos aspectos de una tarea. Strategy emplea composición y herencia,
Template Method emplea herencia. En ambos casos el polimorfismo juega un papel central en
el diseño y reemplaza la utilización de estructuras condicionales.
Con Strategy se deben crear al menos dos objetos: el contexto (o cliente) y la estrategia.
Template Method demanda la creación de una instancia. Debido a que en Strategy el cliente y
la estrategia están separados, es posible cambiar la estrategia en tiempo de ejecución; con
Template Method, no. Incluso es posible que el cliente y las estrategias estén en proyectos o
módulos desarrollados y desplegados de manera independiente.
Referencias
Posted in Desarrollo de Software

Modulo 3 Tema 1 2 3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo 3 Tema 1 2 3

Cargado por

Copyright:

Formatos disponibles

Patrones de Diseño – Introducción

posted on 23/09/2015 by [email protected] | Leave your thoughts

¿Qué es un patrón de diseño?

 El contexto es escenario particular en el que el patrón puede ayudar.

 El problema se refiere al objetivo que se pretende lograr en este contexto.

 La solución facilita el logro del objetivo en el contexto.

Categorías de Patrones de Diseño

 Abstract Factory. Permite la creación de familias de objetos sin conocer las clases

 Composite. Permite el tratamiento uniforme de colecciones de objetos u objetos

 Command. Encapsula una solicitud como un objeto.

La ejecución de la lógica de negocios de una aplicación y la construcción de misma son

AbstractFactory e Inyección de dependencias

Singleton (Instancia Única)

Finalmente, debido a su utilidad, muchos lenguajes han incorporado facilidades para la

Strategy y Template Method

También podría gustarte