Вы находитесь на странице: 1из 6

PATRONES DE DISEO DE SOFTWARE

Los patrones de software son soluciones reusables de problemas recurrentes. Un patron de diseo es una descripcin de clases y objetos comunicndose entre s, adaptado para resolver un problema de diseo general en un contexto particular Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno y describe tambin el ncleo de la solucin al problema, de forma que pueda utilizarse un milln 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 disear Interfaces de usuario. 1987 PATRONES ARQUITECTURALES, creados por el arquitecto Christopher Alexander 1977

Ventajas
Estn 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 especficos de un caso concreto, sino que se presentan una y otra vez en distintas aplicaciones Son expresivos: cuando un equipo de desarrolladores tiene un vocabulario comn de patrones, se puede comunicar de manera fluida y precisa las ideas fundamentales sobre el diseo de una aplicacin.

Elementos Fundamentales
Nombre: Identifica al patron, define un vocabulario comn. El problema a Resolver: Describe cuando aplicar un patron, explica el problema y su contexto.

La Solucin: Describe los elementos que participan del diseo, sus relaciones, responsabilidades y colaboraciones, Da una descripcin abstracta de un problema de diseo y la manera en que un grupo general de elementos lo resuelven.No describe una implementacin concreta particular. Consecuencias (+ o -): Resultados de aplicar el patrn, Impacto en la flexibilidad, extensibilidad y portabilidad de un sistema.

Clasificacin de los patrones GoF (Banda De Los Cuatro)

FACTORY METHOD Define una interfaz para la creacin de objetos, pero delega en las subclases la decisin 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 cmo se crean, componen o representan sus productos Si se cambia la implementacin, se cambian todos sus elementos a la vez.

BUILDER Construir de manera flexible un objeto 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 cmo se ensamblan. El proceso de construccin 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 jerarquas todo - parte y permitir a los clientes tratar objetos simples y compuestos de manera Uniforme Aplicabilidad: Permite representar jerarquas de objetos similares a una estructura de rbol. Permite tratamiento uniforme de objetos simples y complejos as como composiciones recursivas. Simplifica el cdigo de los clientes, que slo usan una interfaz. Facilita aadir 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 patrn obliga a que las llamadas a mtodos de un objeto ocurran indirectamente a travs de un objeto proxy, que acta como sustituto del objeto original, delegando luego las llamadas a los mtodos de los objetos respectivos. Aplicabilidad: los proxys remotos deben codificar las peticiones y envirselas al sujeto real remoto los proxys virtuales pueden tener un cach con informacin sobre el sujeto real para evitar accesos innecesarios los proxys de proteccin comprueban que el cliente tenga permisos de acceso para realizar una peticin Proxy de Sincronizacin: Controla accesos de mltiples clientes a un recurso.

COMMAND Su propsito es encapsular una solicitud como un objeto. Facilita la parametrizacin de los clientes con diferentes peticiones, el encolado de las mismas y su reordenacin. Aplicabilidad: Permite implementar el hacer/deshacer (do/undo) mediante mtodos. Presenta una forma sencilla de implementar un sistema basado en comandos facilitndose su uso y ampliacin. Se independiza la parte de la aplicacin que invoca los comandos de la implementacin 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 cmo interactan un conjunto de objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la interaccin 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 difcil porque tenga que tener referencias a muchos objetos para comunicarse con ellos

ITERATOR

Este patrn define una interfaz que declara mtodos para el acceso secuencial de objetos en una coleccin. Una clase que accesa una coleccin nicamente a travs de esta interfaz, se mantiene independiente de la clase que implementa la interfaz. Aplicabilidad: Es conveniente usar este patrn cuando una clase necesita accesar el contenido de una coleccin, sin hacerse dependiente de la clase que implementa la coleccin. La clase que accede a la coleccin solamente a travs de dicho interfaz permanece independiente de la clase que implementa la interfaz. Proporcionar una interfaz uniforme para recorrer diferentes estructuras de agregacin (iteracin polimrfica) OBSERVADOR Definir una dependencia 1:n de forma que cuando el objeto 1 cambie su estado, los n objetos sean notificados y se actualicen automticamente. Aplicabilidad: Un cambio en un objeto requiera cambiar otros y no se sepa cuantos objetos necesitan cambiar. Este patrn 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 cundo no usar herencia. Cuando una clase que hereda de otra quiere ocultar algunos de los mtodos heredados. La solucin general propuesta en este patrn es: incorporar la funcionalidad de la clase original usando una instancia de la clase original y llamando sus mtodos. INTERFACE Mantiene una clase (la interfaz) que usa datos y servicios provistos por otras clases independientes, para proveer un acceso uniforme. Aplicabilidad: Usando indireccin, esta clase interfaz provee a sus clases herederas acceso uniforme a mtodos y atributos especficos, sin que deban saber a cul clase especfica pertenecen.

INMUTABLE

Este patrn recomienda que para evitar la administracin de la propagacin y sincronizacin de cambios en el estado de los objetos, se usen mltiples objetos de ese tipo, haciendo estos objetos inmutables, es decir, deshabilitando cualquier cambio en su estado despus de construido. Hay entonces dos aspectos en la implementacin de este patrn: (1) Ningn mtodo (a excepcin del constructor) debe modificar los valores de las variables de instancia de la clase; (2) Cualquier mtodo que calcula un nuevo estado, debe almacenar la informacin 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, hacindolo ms fcil 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, hacindolo ms independiente y portable. Se quiera dividir los sistemas en niveles: las fachadas seran 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 aplicacin en tres reas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicacin. El componente Vista despliega la informacin 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, activacin de los botones del mouse, o entradas de teclado).

Вам также может понравиться