Un patrón de diseño (en programación orientada a objetos, POO) es una descripción de diversos objetos y clases preparados para resolver un problema de diseño general aplicado a un contexto específico. Un patrón de diseño identifica las instancias y clases que participan en dicho patrón además de sus papeles, sus relaciones y sus responsabilidades para llevar a cabo la tarea a resolver. Cada patrón de diseño se centra en resolver un problema particular en la POO. Describe cuando se puede aplicar, si puede ser aplicado desde el punto de vista de las limitaciones del diseño y las consecuencias tanto positivas como negativas que tiene su utilización.
Pongamos un ejemplo: MVC (model-view-controller) consiste en 3 tipos de objetos. El modelo son los objetos de la aplicación (lógica de la aplicación), la vista es su representación a los usuarios y el controlador define la manera en el que la interfaz con el usuario (generado por la vista) reacciona ante la introducción de datos por parte del usuario. Dentro de MVC hay varios patrones de diseño que pueden ser empleados para facilitar el desarrollo de este tipo de arquitectura.
Por ejemplo la relación vista-controlador es un ejemplo del patrón de diseño "Strategy". Strategy es un objeto que representa un algoritmo. El patrón es útil en realidad cuando pretendes reemplazar este algoritmo estática o dinamicamente cuanto tienes varias variantes del algoritmo o cuando el algoritmo tiene una estructura de datos compleja que quieres encapsular.
MVC usa otro patrón de diseño "Factory Method" para especificar la clase controladora por defecto para una vista y "Decorator" se puede emplear por ejemplo para añadir scroll a una vista. Pero la principal relación en MVC es dado por los patrones "Observer", "Composite" y "Strategy"
Antes de describir alguno de ellos defino brevemente los parámetros que se emplean para describir los patrones de diseño:
Nombre del patrón y clasificación, intención (¿Que hace este patrón?) ,otros nombres por los que también es conocido, motivación (escenario que ilustra su funcionamiento), aplicabilidad (en que escenarios es válido), estructura (representación gráfica de las clases involucradas y diagramas de interacción para ilustrar secuencias de peticiones y colaboraciones entre objetos), participantes (clases, objetos y sus responsabilidades), colaboraciones (como los participantes pueden colaborar en sus responsabilidades), consecuencias (¿Cómo el patrón realiza su cometido?¿Cuales son los compromisos a tener en cuenta al aceptar esta solución?), implementación (dificultades, riesgos, pistas o técnicas a tener en cuenta a la hora de implementar el patrón), ejemplo de código, usos conocidos y patrones relacionados.
Nombre: Observer
Clasificación: Behavioral Patterns
También conocido como: Dependents, Publish-Subscribe, Event-Observer
Motivación: Un problema muy común al particionar un sistema en una colección de clases cooperativas es la necesidad de mantener la consistencia entre objetos relacionados pero sin tenerlos fuertemente acoplados ya que esto reduce su reusabilidad. El patrón define un sujeto y uno o varios observadores de este suejto. Todos los observadores son notificados si el sujeto lleva a cabo un cambio de estado (evento).
Aplicabilidad:
- Cuando un objeto cambia y esto requiere el cambio de varios objetos y se desconoce el número de objetos que necesitarán este cambio
- Cuando una abstracción tiene dos aspectos, una dependiente de la otra. Encapsular estos aspectos te permite variarlos y reusarlos independientemente
- Cuando un objeto tiene que notificar a otros objetos sin hacer asunciones sobre su naturaleza. En otras palabras no se quiere que estos objetos esten fuertemente acoplados
Estructura: Diagrama de clases
Participantes:
- Subject (conoce sus observers que pueden ser uno, ninguno o varios y proporciona un interfaz para registrar y desregistrar observadores)
- Observer (define un intefaz para actualizar que debe ser llamado cuando el subject cambia de estado)
- ConcreteSubject (almacena el estado de interes para los objetos ConcreteObserver y les envia notificaciones cuando su estado cambia)
- ConcreteObserver (Mantiene referencia al objeto ConcreteSubject, almacena estado de manera consistente con el del objeto ConcreteSubject e implementa interfaz de actualización para las notificaciones)
Colaboraciones: ConcreteSubject notifica a sus observadores sobre un cambio que podría hacer el estado de los observadores fuera inconsistente con el suyo propio. Después de ser informado el observador del cambio en el sujeto. El observador podría requerir informacion al sujeto para conciliar su estado
Consecuencias: El patrón observer te permite cambiar sujetos y observadores de manera independiente de manera que se pueden rehusar ambos. Puede violar la separación en capas de tu aplicación pues los observadores pueden pertenecer a capas diferentes de la del sujeto. Las actualizaciones en el sujeto pueden generar un coste desconocido pues no se sabe cuantos ni cuales observadores pueden estar registrados al sujeto.
Implementación: Temas conflictivos: mapear subjects a observers y observers a más de un subject. ¿Quien dispara la actualización? 2 opciones, el propio subject cuando cambia de estado o hacer a los clientes responsables de enviar la notificacion.
Ejemplos de código:
Symfony event dispatcher
Usos conocidos: Cualquier interfaz de usuario GUI implementado empleando OOP como KDE
Patrones relacionados: Mediator, Singleton
Espero que os sea de utilidad. No puedo acabar si pasar la referencia a la biblia de los patrones de diseño creado por el Gang of Four (sus 4 autores)
Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)
Publicado por Abraham Covelo
Powered by Novanebula