Áreas de grado CSC UDO

Patrones GoF

Los patrones de diseño, extensamente utilizados en la industria del desarrollo de software, representan soluciones standard a problemas recurrentes.

La idea de patrón en el contexto del desarrollo se inspira en el arte arquitectónico, proporcionando un recurso conceptualmente próximo. Pese a no ser los inventores del término, los cuatro miembros del denominado Gang of Four (GoF) fueron unos de sus primeros impulsores y probablemente sus mayores divulgadores. Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides propusieron en Design Patterns: Elements of Reusable Object-Oriented Software (1994) una novedosa aproximación al desarrollo orientado a objetos que ha sobrevivido hasta a día de hoy en las aulas de ingeniería.

Los autores del GoF proponen dos principios básicos:

·         Programar orientado a una interfaz y no a una implementación.

Este principio busca que el código se utilice como una herramienta que no revele su funcionamiento. La clásica metáfora de la “caja negra” implementada a través del principio de la encapsulación. De este modo, los usuarios del código se centran en la firma abstracta, lo que puede hacer y no puede hacer el código, en vez de en el cómo lo hace. Se establece una separación fundamental entre el programador del código -la persona que lo crea y lo mantiene- y el usuario del código -entendido como el desarrollador que utiliza la librería sin modificar su funcionamiento-. Dicho de otro modo, los patrones GoF buscan proporcionarnos piezas con instrucciones claras sobre con qué se pueden conectar y qué hacen, pero que no nos dicen nada sobre su funcionamiento interno.

·         Favorecer la composición antes que la herencia.

En las arquitecturas orientadas a objetos, la composición y la herencia pueden ser muy próximas funcionalmente, pero conceptualmente son distintas. Ambas permiten la agregación de funcionalidades cuando diseñamos una clase y evitan la redundancia de código, pero tienen una diferencia fundamental: la herencia expone el funcionamiento de una clase, mientras que la agregación no lo hace (si trata con clases bien encapsuladas). Siguiendo el principio anterior, es lógico que los patrones GoF favorezcan la composición, ya que la herencia no garantiza la encapsulación. Los autores del GoF llegan a afirmar que la herencia no es compatible con la encapsulación.

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

·         Los patrones creacionales 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 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 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.

Uno de los hitos más importantes en el diseño orientado a objetos fue la publicación del libro “Design Patterns” por Gamma, Helm, Johnson y Vlissides en 1995; conocidos como “Gang of Four”, GoF. Se revelan 23 patrones ampliamente utilizados. En este apartado se tratarán algunos de ellos.

Adaptador

Problema: ¿Cómo resolver interfaces incompatibles, o proporcionar una interfaz

estable para componentes parecidos con diferentes interfaces?

Solución: Convierta la interfaz original de una componente en otra, mediante un

objeto adaptador intermedio. El propósito de este patrón es convertir la interfaz de una clase en otra interfaz que es la que esperan los clientes. Este patrón permite que cooperen clases que de otra forma no podrían colaborar por no tener compatibilidad entre ellas.

Debería usarse el patrón Adaptador cuando:

*Se quiere utilizar una clase existente y su interfaz no concuerda con lo

que se espera.

·      *Se quiere crear una clase reutilizable que coopere con clases no

relacionadas o que no han sido previstas, i.e. clases que no tienen por qué

tener interfaces compatibles.

Los participantes en este patrón realizan los siguientes roles:

·     *Objetivo: define los servicios del dominio que usa el cliente. Representa un interfaz estable con los servicios tal cual espera el cliente.

·       *Cliente: utiliza los servicios del paquete a través del interfaz Objetivo.

·       * Adaptable: Implementa los servicios del paquete.

·        *Adaptador: adapta la interfaz de Adaptable a la interfaz Objetivo.

Factoría

Problema: ¿Quién debe ser responsable de la creación de los objetos cuando

existen consideraciones especiales, como una lógica de creación compleja, el deseo deseparar las responsabilidades de la creación para manejar la cohesión, etc.?

Solución: Crear un objeto de Fabricación Pura denominado Factoría que maneje

la creación.

Los objetos Factoría tienen varias ventajas:

·         *Separación de responsabilidades en la creación compleja en objetos de apoyo cohesivo.

·        *Ocultan la lógica de creación potencialmente compleja.

·    *Permite introducir estrategias para mejorar el rendimiento de la gestión de la memoria, como objetos caché o de reciclaje.

El cliente sólo utilizará las interfases de sus paquetes servidores, dejando que sea

la lógica externa quien decida sobre la implementación y la factoría quien crea los

objetos que implementan los servicios. A este patrón GoF se le llama Factoría Abstacta. Se empleará 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.

·         *Quiere proporcionar una biblioteca de clases de productos y sólo quiere

revelar sus interfaces, no sus implementaciones.

Singleton

Problema: ¿Cómo garantizar que una clase sólo tenga una instancia y proporciona un punto de acceso global a ella? Solución: Definir un método estático de la clase que devuelva el singleton.

La clave del Singleton es evitar que el cliente no tenga el control sobre la vida del objeto. Para tal fin se declaran todos los constructores como privados y se previene para que el compilador no produzca constructores por defecto ni sobrecarga de operadores de asignación. Se construye el servicio de tipo estático para obtener la referencia Singleton, getInstancia(), y también se colocará como estática la propia referencia. En la notación se puede emplear el estereotipo <> para indicar que sólo existe una única instancia de esta clase.

Estrategia

Problema: ¿Cómo diseñar algoritmos que están relacionados? ¿Cómo diseñar que estos algoritmos se puedan variar dinámicamente? Solución: Defina cada algoritmo o estrategia en una clase independiente, con una interfaz común.

Este patrón define una familia de algoritmos relacionados, los encapsula y los hace intercambiables. La consecuencia de esta estructura es la variación dinámica de los algoritmos sin que los clientes se vean afectados. Los roles de este patrón son:

·         *Estrategia: declara una interfaz común a todos los algoritmos permitidos.

·        *Estrategia concreta: implementa el algoritmo concreto usando la interfaz Estrategia.

*Contexto: este objeto usa la interfaz Estrategia para llamar al algoritmo concreto definido por una Estrategia Concreta. Tiene como atributo a un objeto de Estrategia Concreta, a través de su interfaz. 

Observador

Problema: Diferentes tipos de objetos receptores están interesados en el cambio

de estado o eventos de un objeto emisor y quieren reaccionar cada uno a su manera cuando el emisor genere un evento. Además, el emisor quiere mantener bajo acoplamiento con los receptores ¿qué hacer?

Solución: Defina una interfaz “suscriptor” u “oyente”. Los suscriptores

implementan esta interfaz. El emisor dinámicamente puede registrar los suscriptores que están interesados en un evento y notificarles cuando ocurre un evento.

Los roles que se desempeñan en este patrón son:

ü  Observable

·         Un Observable puede ser observado por cualquier número de objetos Observador.

·         proporciona una interfaz para asignar y quitar objetos Observador.

ü  Observador

·         define una interfaz para actualizar los objetos que deben ser notificados

          ante cambios en un sujeto observable.

ü  ObservableConcreto

·         almacena el estado de interés para los objetos ObservadorConcreto.

·         envía una notificación a sus observadores cuando cambia su estado.

ü  ObservadorConcreto

·         mantiene una referencia a un objeto ObservableConcreto.

·         guarda un estado que debería ser consistente con el sujeto observable.

·         Implementa la interfaz de actualización del Observador para mantener su

          estado consistente con el sujeto observable.

(Grupo java) Dayani España, Andres Maita