Patrones GoF

En ingeniería de software, un patrón de diseño es una solución repetible general a un problema común en el diseño de software. Un patrón de diseño no es un diseño terminado que pueda transformarse directamente en código. Es una descripción o plantilla sobre cómo resolver un problema que se puede utilizar en muchas situaciones diferentes.

A principios de la década de 1990 los patrones de diseño tuvieron un gran éxito en el mundo de la informática gracias a la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, en el que se recogían 23 patrones de diseño comunes.

Los patrones GoF se dividen en tres tipos fundamentales, agrupados según el tipo de soluciones que aplican.

•    Los patrones creacionales, que son aquellos que aplican soluciones que crean objetos de manera determinada. De este modo buscan encapsular la instanciación de objetos dentro de los métodos de otros objetos opacos, ocultándola al usuario del código.
•     Los patrones estructurales, que abstraen la composición de interfaces a través de otros recursos, como la herencia o la agregación. Se encargan de proporcionar al usuario del código un objeto de firma simple que agrupa múltiples objetos de manera opaca.
•     Los patrones de comportamiento, que buscan proporcionar al usuario del código objetos que aporten una funcionalidad determinada. De este modo los objetos presentan una firma cuyos métodos resuelven un problema específico sin exponer su funcionamiento.

PATRONES CREACIONALES

Estos patrones de diseño tienen que ver con la creación de instancias de clase. Este patrón se puede dividir en patrones de creación de clases y patrones de creación de objetos. Mientras que los patrones de creación de clases usan la herencia de manera efectiva en el proceso de creación de instancias, los patrones de creación de objetos usan la delegación de manera efectiva para hacer el trabajo.

Abstract Factory/Fabrica Abstracta: Este patrón creacional proporciona una interfaz para crear familias de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas. Puede ser utilizado cuando:

• Un sistema debe ser independiente de cómo se crean, componen y representan sus productos.
• Un sistema debe ser configurado como una familia de productos entre varias.
• Una familia de objetos producto relacionados está diseñada para ser usada conjuntamente, y es necesario hacer cumplir esta restricción.
• Se quiere proporcionar una biblioteca de clases de productos, y solo quiere revelar sus interfaces, no sus implementaciones.

Abstract Factory define un método de fábrica por producto. Cada Método de Fábrica encapsula al new operador y las clases concretas de productos específicos de la plataforma. Cada "plataforma" se modela con una clase derivada de Factory.

El propósito de Abstract Factory es proporcionar una interfaz para crear familias de objetos relacionados, sin especificar clases concretas. Este patrón se encuentra en el equipo de estampado de chapa utilizado en la fabricación de automóviles japoneses. El equipo de estampado es una Fábrica abstracta que crea partes del cuerpo del automóvil. La misma maquinaria se utiliza para estampar puertas derechas, puertas izquierdas, guardabarros delanteros derechos, guardabarros delanteros izquierdos, capós, etc. para diferentes modelos de automóviles. Mediante el uso de rodillos para cambiar los troqueles de estampado, las clases de concreto producidas por la maquinaria se pueden cambiar en tres minutos.

 *Ver ejemplo de este patrón en lenguaje Java*

Builder/Constructor: Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones. Suele utilizarse cuando:

• El algoritmo para crear un objeto complejo debiera ser independiente de las partes de que se compone dicho objeto y de cómo se ensamblan
• El proceso de construcción debe permitir diferentes representaciones del objeto que está siendo construido.

El lector encapsula el análisis de la entrada común. La jerarquía de constructores hace posible la creación polimórfica de muchas representaciones u objetivos peculiares.

El patrón Builder separa la construcción de un objeto complejo de su representación para que el mismo proceso de construcción pueda crear diferentes representaciones. Este patrón es utilizado por los restaurantes de comida rápida para construir las comidas de los niños. Las comidas para niños generalmente consisten en un artículo principal, un artículo secundario, una bebida y un juguete (por ejemplo, una hamburguesa, papas fritas, Coca-Cola y un dinosaurio de juguete). Tenga en cuenta que puede haber variaciones en el contenido de la comida de los niños, pero el proceso de construcción es el mismo. Ya sea que un cliente ordene una hamburguesa, una hamburguesa con queso o un pollo, el proceso es el mismo. El empleado en el mostrador dirige a la tripulación a ensamblar un artículo principal, un artículo secundario y un juguete. Estos artículos se colocan en una bolsa. La bebida se coloca en una taza y permanece fuera de la bolsa. Este mismo proceso se usa en restaurantes competidores.

*Ver ejemplo de este patrón en lenguaje Java*

Factory Method/Método de Fabrica: Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan que clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos. Suele usarse cuando:

• Una clase no puede prever la clase de objetos que debe crear.
• Una clase quiere que sean sus subclases quienes especifiquen los objetos que esta crea.
• Las clases delegan la responsabilidad en una de entre varias clases auxiliares, y se quiere localizar que subclase de auxiliar concreta es en la que se delega.

La implementación del Factory Method discutido por el grupo Gang of Four  se superpone en gran medida con la de Abstract Factory. Por esa razón, la presentación de este patrón se centra en el enfoque que se ha vuelto popular desde entonces.

Una definición cada vez más popular del Factory Method es: un static método de una clase que devuelve un objeto del tipo de esa clase. Pero a diferencia de un constructor, el objeto real que devuelve podría ser una instancia de una subclase. A diferencia de un constructor, un objeto existente podría reutilizarse, en lugar de crearse un nuevo objeto. A diferencia de un constructor, los métodos de fábrica pueden tener nombres diferentes y más descriptivos (por ejemplo, Color.make_RGB_color (float red, float green, float blue) y Color.make_HSB_color (float hue, float saturation, float brightness).

El cliente está totalmente desacoplado de los detalles de implementación de las clases derivadas. La creación polimórfica ahora es posible.

El Factory Method define una interfaz para crear objetos, pero permite que las subclases decidan qué clases instanciar. Las prensas de moldeo por inyección demuestran este patrón. Los fabricantes de juguetes de plástico procesan polvo de moldeo de plástico e inyectan el plástico en moldes de las formas deseadas. La clase de juguete (automóvil, figura de acción, etc.) está determinada por el molde.

*Ver ejemplo de este patrón en lenguaje Java*

Prototype/Prototipo: Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crea nuevos objetos copiando dicho prototipo. Se utiliza cuando un sistema deba ser independiente de cómo se crean, se componen y se representan sus productos, así como también:

• Cuando las clases a instanciar sean especificadas en tiempo de ejecución (por ejemplo, mediante carga dinámica).
• Para evitar construir una jerarquía de clases de fábricas paralela a la jerarquía de clases de los productos.
• Cuando las instancias de una clase puedan tener uno de entre solo unos pocos estados diferentes. Puede ser más adecuado tener un número equivalente de prototipos y clonarlos, en vez de crear manualmente instancias de la clase cada vez con el estado apropiado.

La fábrica sabe cómo encontrar el prototipo correcto, y cada producto sabe cómo generar nuevas instancias de sí mismo.

El patrón Prototype especifica el tipo de objetos para crear utilizando una instancia prototípica. Los prototipos de nuevos productos a menudo se construyen antes de la producción completa, pero en este ejemplo, el prototipo es pasivo y no participa en la copia. La división mitótica de una célula, que da como resultado dos células idénticas, es un ejemplo de un prototipo que juega un papel activo en copiarse y, por lo tanto, demuestra el patrón del prototipo. Cuando una célula se divide, resultan dos células de genotipo idéntico. En otras palabras, la célula se clona a sí misma.

*Ver ejemplo de este patrón en lenguaje Java*

Singleton/Único: Garantiza que una clase solo tenga una instancia, y proporciona un punto de acceso global a ella. Se utiliza el patrón Singleton cuando:

• Se debe hacer exactamente una instancia de una clase, y esta deba ser accesible a los clientes desde un punto de acceso conocido.
• La única instancia debería ser extensible mediante herencia, y los clientes deberían ser capaces de usar una instancia extendida sin modificar su código.

Permite que la clase de la instancia única sea responsable del acceso y la "inicialización en el primer uso". La instancia única es un atributo estático privado. La función de acceso es un método público estático.

El patrón Singleton garantiza que una clase tenga solo una instancia y proporciona un punto de acceso global a esa instancia. Lleva el nombre del conjunto singleton, que se define como un conjunto que contiene un elemento. La oficina del Presidente de los Estados Unidos es Singleton. La Constitución de los Estados Unidos especifica los medios por los cuales se elige a un presidente, limita el mandato y define el orden de sucesión. Como resultado, puede haber como máximo un presidente activo en un momento dado. Independientemente de la identidad personal del presidente activo, el título, "El presidente de los Estados Unidos" es un punto de acceso global que identifica a la persona en la oficina.

En el siguiente vídeo se explicará mediante un ejemplo el uso de este patrón: 

PATRONES ESTRUCTURALES

Los patrones estructurales se ocupan de combinar clases y objetos para formar estructuras más complejas. Los patrones estructurales de clases utilizan la herencia múltiple para componer interfaces, mientras que los patrones estructurales de objetos sirven para crear nuevas funcionalidades al mismo. La ventaja de estos patrones es que agregan a la estructura flexibilidad y que la misma puede cambiar en tiempo de ejecución, lo cual es imposible con una composición de clases estáticas.

Dentro de los patrones de diseño estructurales tenemos: Adapter (estructural de clases y objetos), Bridge (estructural de objetos), Composite (estructural de objetos), Decorator (estructural de objetos), Facade (estructural de objetos), Flyweight (estructural de objetos) y Proxy (estructural de objetos).

Adapter/Adaptador: Es capaz de convertir la interfaz de una clase a otra interfaz que esperan los clientes, cuando sea necesario usar una clase ya existente pero su interfaz no concuerde con lo que se necesita. Por otro lado, permite que cooperen clases que de otra forma no podrían por tener interfaces incompatibles, debido a que en ocasiones se crean clases reutilizables para que cooperen con otras clases no relacionadas y es por ello que no contienen interfaces compatibles.

El adaptador consiste en crear una abstracción intermedia que traduzca, o asigne, el componente antiguo al nuevo sistema. Los clientes llaman a métodos en el objeto Adaptador que los redirige a llamadas al componente heredado. Esta estrategia se puede implementar con herencia o con agregación. El adaptador funciona como un contenedor o modificador de una clase existente. Proporciona una vista diferente o traducida de esa clase.

Supongamos que, el "display()" método de un componente Rectangle heredado espera recibir los parámetros "x, y, w, h". Pero el cliente quiere pasar "superior izquierda x e y" e "inferior derecha x e y". Esta incongruencia se puede remediar agregando un nivel adicional de indirección, es decir, un objeto Adaptador.

El adaptador también podría considerarse como un "envoltorio".

El patrón Adaptador permite que las clases incompatibles trabajen juntas al convertir la interfaz de una clase en una interfaz esperada por los clientes. Las llaves de vaso proporcionan un ejemplo del adaptador. Se conecta un zócalo a un trinquete, siempre que el tamaño de la unidad sea el mismo. Los tamaños de unidad típicos en los Estados Unidos son 1/2 "y 1/4". Obviamente, un trinquete de 1/2 "no encajará en un receptáculo de 1/4" a menos que se use un adaptador. Un adaptador de 1/2 "a 1/4" tiene una conexión hembra de 1/2 "para encajar en el trinquete de accionamiento de 1/2", y una conexión macho de 1/4 "para encajar en el zócalo de accionamiento de 1/4".

*Ver ejemplo de este patrón en lenguaje Java*

Bridge/Puente: Su principal intención es desacoplar una abstracción de su implementación para que los dos puedan variar de forma independiente.

Puente es sinónimo del lenguaje "manejar / cuerpo". Este es un mecanismo de diseño que encapsula una clase de implementación dentro de una clase de interfaz. El primero es el cuerpo, y el segundo es el mango. El usuario ve el identificador como la clase real, pero el trabajo se realiza en el cuerpo. "El idioma de clase de identificador / cuerpo se puede usar para descomponer una abstracción compleja en clases más pequeñas y más manejables. El idioma puede reflejar el intercambio de un solo recurso por múltiples clases que controlan el acceso a él (por ejemplo, el recuento de referencias)". 

Bridge enfatiza la identificación y desacoplamiento de la abstracción de "interfaz" de la abstracción de "implementación".

El patrón Bridge desacopla una abstracción de su implementación, de modo que los dos pueden variar independientemente. Un interruptor doméstico que controla luces, ventiladores de techo, etc. es un ejemplo del Puente. El propósito del interruptor es encender o apagar un dispositivo. El interruptor real puede implementarse como una cadena de tracción, un interruptor simple de dos posiciones o una variedad de interruptores de atenuación.

*Ver ejemplo de este patrón en lenguaje Java*

Composite/Compuesto: Se encarga de componer objetos en estructuras de árbol para representar jerarquías de partes enteras. Compuesto permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.

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 fila-columna que contienen widgets, cada uno de los cuales podría ser un administrador de diseño de GUI de columna-fila.

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.

Aunque el ejemplo es abstracto, las expresiones aritméticas son compuestos. Una expresión aritmética consiste en un operando, un operador (+ - * /) y otro operando. El operando puede ser un número u otra expresión aritmética. Por lo tanto, 2 + 3 y (2 + 3) + (4 * 6) son expresiones válidas.

*Ver ejemplo de este patrón en lenguaje Java*

Decorator/Decorador: Se emplean para asignar responsabilidades adicionales a un objeto dinámicamente. Los decoradores proporcionan una alternativa flexible a la herencia para ampliar la funcionalidad.

Suponga que está trabajando en un kit de herramientas de interfaz de usuario y desea admitir la adición de bordes y barras de desplazamiento a las ventanas. Podría definir una jerarquía de herencia como ...

Pero el patrón Decorador sugiere dar al cliente la capacidad de especificar cualquier combinación de "características" que se desee.

Esta flexibilidad se puede lograr con el siguiente diseño:

El decorador asigna responsabilidades adicionales a un objeto de forma dinámica. Los adornos que se agregan a los pinos o abetos son ejemplos de decoradores. Se pueden agregar luces, guirnaldas, bastones de caramelo, adornos de vidrio, etc., a un árbol para darle un aspecto festivo. Los adornos no cambian el árbol en sí, que es reconocible como un árbol de Navidad, independientemente de los adornos particulares utilizados. Como ejemplo de funcionalidad adicional, la adición de luces permite "iluminar" un árbol de Navidad.

Otro ejemplo: el arma de asalto es un arma mortal en sí misma. Pero puede aplicar ciertas "decoraciones" para hacerlo más preciso, silencioso y devastador.

*Ver ejemplo de este patrón en lenguaje Java*

Facade/Fachada: Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.

SubsystemOne y SubsystemThree no interactúan con los componentes internos de SubsystemTwo. Utilizan la SubsystemTwoWrapper "fachada" (es decir, la abstracción de nivel superior).

Los consumidores encuentran una Fachada cuando hacen un pedido desde un catálogo. El consumidor llama a un número y habla con un representante de servicio al cliente. El representante de servicio al cliente actúa como una fachada, proporcionando una interfaz para el departamento de cumplimiento de pedidos, el departamento de facturación y el departamento de envío.

*Ver ejemplo de este patrón en lenguaje Java*

Flyweight/Peso ligero: Usa compartimiento para permitir grandes cantidades de objetos de grano fino de manera eficiente.

El patrón Flyweight describe cómo compartir objetos para permitir su uso con granularidad fina sin costo prohibitivo. Cada objeto "flyweight" se divide en dos partes: la parte dependiente del estado (extrínseca) y la parte independiente del estado (intrínseca). El estado intrínseco se almacena (comparte) en el objeto Flyweight. El estado extrínseco es almacenado o calculado por los objetos del cliente, y se pasa al Flyweight cuando se invocan sus operaciones.

El cliente se abstiene de crear Flyweights directamente y los solicita a Factory.

Flyweight utiliza el uso compartido para admitir grandes cantidades de objetos de manera eficiente. Los navegadores web modernos usan esta técnica para evitar cargar las mismas imágenes dos veces. Cuando el navegador carga una página web, atraviesa todas las imágenes de esa página. El navegador carga todas las imágenes nuevas de Internet y las coloca en la memoria caché interna. Para las imágenes ya cargadas, se crea un objeto Flyweight, que tiene algunos datos únicos como la posición dentro de la página, pero todo lo demás está referenciado al caché.

*Ver ejemplo de este patrón en lenguaje Java*

Proxy/Apoderado: Proporciona un representante o sustituto de otro objeto para controlar el acceso a éste.

Hay cuatro situaciones comunes en las que se aplica el patrón Proxy.

·        Un proxy virtual es un marcador de posición para objetos "caros de crear". El objeto real solo se crea cuando un cliente primero solicita / accede al objeto.

·        Un proxy remoto proporciona un representante local para un objeto que reside en un espacio de direcciones diferente. Esto es lo que proporciona el código de "código auxiliar" en RPC y CORBA.

·        Un proxy de protección controla el acceso a un objeto maestro sensible. El objeto "sustituto" verifica que la persona que llama tenga los permisos de acceso requeridos antes de reenviar la solicitud.

·        Un proxy inteligente interpone acciones adicionales cuando se accede a un objeto. Los usos típicos incluyen:

§  Contando el número de referencias al objeto real para que pueda liberarse automáticamente cuando no haya más referencias (también conocido como puntero inteligente),

§  Cargando un objeto persistente en la memoria cuando se hace referencia por primera vez,

§  Comprobar que el objeto real esté bloqueado antes de acceder a él para asegurarse de que ningún otro objeto pueda cambiarlo.

Al definir una interfaz Subject, la presencia del objeto Proxy en lugar del RealSubject es transparente para el cliente.

El Proxy proporciona un sustituto o un titular de lugar para proporcionar acceso a un objeto. Un cheque o giro bancario es un proxy de fondos en una cuenta. Se puede usar un cheque en lugar de efectivo para realizar compras y, en última instancia, controla el acceso al efectivo en la cuenta del emisor.

*Ver ejemplo de este patrón en lenguaje Java*