PATRONES DE DISEÑO DE SOFTWARE
Los patrones de software son soluciones r eusables de problemas recurrentes. Un patron de diseño es una descripción de clases y objetos comunicándose entre sí, adaptado para resolver un problema de diseño general en un contexto particular Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de la solución al problema, de forma que pueda utilizarse un millón de veces sin tener que hacer dos veces lo mismo.
Historia
Patterns in Java, Grand Mark, Usa UML y JAVA – 1998
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (The Gang of Four [GOF]) publicaron El libro Design Pattern Elements of Reusable Object-Oriented Sofware. – 1994.
Ward Cunnigham y Ken Beck, basados en c. Desarrollaron 5 patrones para diseñar Interfaces de usuario. – 1987
PATRONES ARQUITECTURALES, creados por el arquitecto Christopher Alexander – 1977
Ventajas
Están ya probados: son soluciones que han sido utilizadas con anterioridad de manera repetida y se ha comprobado que funciona.
Son reutilizables: corresponden con problemas que no son específicos de un caso concreto, sino que se presentan una y otra vez en distintas aplicaciones
Son expresivos: cuando un equipo de desarrolladores desarrolladores tiene un vocabulario común de patrones, se puede comunicar de manera fl uida y precisa las i deas fundamentales sobre el diseño de una aplicación.
Elementos Fundamentales
Nombre: Identifica al patron, define un vocabulario común.
El problema a Resolver: Describe cuando aplicar un patron, explica el problema y su contexto.
La Solución: Describe los elementos que participan del diseño, sus relaciones, responsabilidades y colaboraciones, Da una descripción abstracta de un problema de diseño y la manera en que un grupo general de elementos lo resuelven.No describe una implementación concreta particular.
Consecuencias (+ o -): Resultados de aplicar el patrón, Impacto en la flexibilidad, extensibilidad y portabilidad de un sistema.
Clasificación de los patrones GoF (Banda De Los Cuatro)
FACTORY METHOD Define una interfaz para la creación de objetos, pero delega en las subclases la decisión de qué o cual clase instanciar. Aplicabilidad:
Cuando una clase no pueda anticipar que tipo de objetos debe crear. Cuando una clase quiere que sus clases especifiquen los objetos que deben crear.
ABSTRACT FACTORY
Provee una interface que permite crear familias de objetos relacionados o dependientes, sin especificar sus clases concretas. Aplicabilidad:
Usado cuando, es necesario organizar un conjunto de elementos que trabajan con productos diferentes, pero relacionados de alguna manera. Un sistema deba ser independiente de cómo se crean, componen o representan sus productos Si se cambia la implementación, se cambian todos sus elementos a la vez.
BUILDER
Construir de manera flexible un o bjeto Complejo a partir de otro objeto Complejo en una serie de pasos Aplicabilidad:
El algoritmo para crear un objeto complejo deba ser independiente de las partes que componen el objeto y de cómo se ensamblan.
El proceso de construcción deba permitir distintas representaciones para el objeto que es construido
SINGLETON
Asegurar que solo existe una única instancia de una clase, y que hay un punto global de acceso a la misma. Aplicabilidad:
Es necesario cuando hay clases que tienen que gestionar de manera centralizada un recurso. Asegurarse de que una clase tiene una sola instancia y proporcionar un punto de acceso global a ella.
COMPOSITE
Componer objetos en jerarquías todo - parte y permitir a los clientes tratar objetos simples y compuestos de manera Uniforme Aplicabilidad:
Permite representar jerarquías de objetos similares a una estructura de árbol. Permite tratamiento uniforme de objetos simples y complejos así como composiciones recursivas. Simplifica el código de los clientes, que sólo usan una interfaz. Facilita añadir nuevos componentes sin afectar a los clientes. Cuando se quiera que los clientes puedan ignorar la diferencia entre objetos simples y compuestos y tratarlos uniformemente
PROXY
El patrón obliga a que las llamadas a métodos de un objeto ocurran indirectamente a través de un objeto proxy, que actúa como sustituto del objeto original, delegando luego las llamadas a los métodos de los objetos respectivos. Aplicabilidad:
los proxys remotos deben codificar las peticiones y enviárselas al sujeto real remoto los proxys virtuales pueden tener un caché con información sobre el sujeto real para evitar accesos innecesarios los proxys de protección comprueban que el cliente tenga permisos de acceso para realizar una petición Proxy de Sincronización: Controla accesos de múltiples clientes a un recurso.
COMMAND
Su propósito es encapsular una solicitud como un objeto. Facilita la parametrización de los clientes con diferentes peticiones, el encolado de las mismas y su reordenación. Aplicabilidad:
Permite implementar el hacer/deshacer (do/undo) mediante métodos.
Presenta una forma sencilla de implementar un sistema basado en comandos facilitándose su uso y ampliación.
Se independiza la parte de la aplicación que invoca los comandos de la implementación de los mismos.
Los comandos se tratan como objetos, entonces se puede realizar herencia o composiciones de comandos (Composite).
MEDIATOR
Definir un objeto que encapsule cómo interactúan un conjunto de objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la interacción de forma independiente Aplicabilidad:
Encapsula el comportamiento de todo un conjunto de objetos en un solo objeto. Un conjunto de objetos se comunique de una forma bien definida pero compleja, con interdependencias complicadas. Reutilizar un objeto sea difícil porque tenga que tener referencias a muchos objetos para comunicarse con ellos
ITERATOR
Este patrón define una interfaz que declara métodos para el acceso secuencial de objetos en una colección. Una clase que accesa una colección únicamente a través de esta interfaz, se mantiene independiente de la clase que implementa la interfaz. Aplicabilidad:
Es conveniente usar este patrón cuando una clase necesita accesar el contenido de una colección, sin hacerse dependiente de la clase que implementa la colección. La clase que accede a la colección solamente a través de dicho interfaz permanece independiente de la clase que implementa la interfaz. Proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregación (iteración polimórfica)
OBSERVADOR
Definir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean notificados y se actualicen automáticamente. Aplicabilidad:
Un cambio en un objeto requiera cambiar otros y no se sepa cuantos objetos necesitan cambiar. Este patrón es útil cuando se tienen relaciones de dependencias uno-a-muchos, que requieren que un objeto notifique a otros sobre cambios en su estado.
DELEGATION
Cuando se quiere extender y reutilizar la Funcionalidad de una clase SIN UTILIZAR LA HERENCIA Aplicabilidad:
Indica cuándo no usar herencia.
Cuando una clase que hereda de otra quiere ocultar algunos de los métodos heredados.
La solución general propuesta en este patrón es: incorporar la funcionalidad de la clase original usando una instancia de la clase original y llamando sus métodos.
INTERFACE
Mantiene una clase (la interfaz) que usa datos y servicios provistos por otras clases independientes, para proveer un acceso uniforme. Aplicabilidad:
Usando indirección, esta clase interfaz provee a sus clases herederas acceso uniforme a métodos y atributos específicos, sin que deban saber a cuál clase específica pertenecen.
INMUTABLE
Este patrón recomienda que para evitar la administración de la propagación y sincronización de cambios en el estado de los objetos, se usen múltiples objetos de ese t ipo, haciendo estos objetos inmutables, es decir, deshabilitando cualquier cambio en su estado después de construido. Hay entonces dos aspectos en la implementación de este patrón: (1) Ningún método (a excepción del constructor) debe modificar los valores de las variables de instancia de la clase; (2) Cualquier método que calcula un nuevo estado, debe almacenar la información en una nueva instancia de la misma clase, en lugar de modificar el estado de un objeto ya existente.
ADAPTER
Convertir la interfaz de una clase en otra interfaz esperada por los clientes.Permite que clases con interfaces incompatibles puedan comunicarse. Aplicabilidad:
Se quiera utilizar una clase ya existente y su interfaz no se corresponda con la interfaz que se necesita. Convertir la interfaz de una clase en otra interfaz esperada por los clientes. Permite que clases con interfaces incompatibles se comuniquen
FACADE
Proporcionar una interfaz unificada para un conjunto de interfaces en un subsistema, haciéndolo más fácil de usar. Aplicabilidad:
Se quiera proporcionar una interfaz sencilla para un subsistema complejo. Se quiera desacoplar un subsistema de sus clientes y de otros subsistemas, haciéndolo más independiente y portable. Se quiera dividir los sistemas en niveles: las fachadas serían el punto de entrada a cada nivel.
MODELO VISTA CONTROLADOR
Las interfaces de usuario son especialmente propensas a cambios de requerimientos. Aplicabilidad:
MVC divide una aplicación en tres áreas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicación.
El componente Vista despliega la información al usuario, a partir de los datos del Modelo. Cada Vista tiene un componente Controlador asociado, que se encarga de recibir las entradas del usuario (usualmente en forma de eventos como: movimiento del mouse, activación de los botones del mouse, o entradas de teclado).
