patrones gof

Download Patrones GOF

Post on 16-Jan-2017

164 views

Category:

Software

0 download

Embed Size (px)

TRANSCRIPT

Patrones GOFJoan Sebastin Ramrez Prez2016

AgendaQu es un patrn de diseo?Patrones GOFPatrones de creacinPatrones de estructuraPatrones de comportamientoBibliografa

Qu es un patrn de software?

1977, A Pattern Language, Christopher AlexanderCada patrn describe un problema que ocurre una y otra vez en nuestro medio ambiente y, a continuacin describe el ncleo de la solucin a ese problema, de tal manera que se puede utilizar esta solucin un milln de veces, sin tener que hacerlo de la misma manera dos veces

Qu es un patrn de software?Solucin probada a un problema recurrente.Solucin reutilizable a un problema comn en un contexto dado.

Patrones GOF

Patrones GOFGang of Four: Ralph JohnsonErich GammaRichard HelmJohn Vlissides

Clasificacin de los patrones GOF Propsito Refleja lo que hace un patrnSe divide en Patrones de Creacin , Estructura y Comportamiento Alcance Especifica si el patrn se aplica principalmente a clases u objetos Patrones de Clase y de Objeto

Clasificacinpatrones GOF

Patrones de creacin

Patrones de creacinFactory Method: crea una instancia de varias clases derivadas Abstract Factory: crea una instancia de varias familias de clases BuilderSepara la construccin de un objeto de su representacin Prototype: genera una instancia y la inicializa, que puede ser copiada o colgada.Singleton: una clase de la cual solo puede existir una nica instancia

Factory MethodProblema: una clase no puede anticipar la clase de objetos que debe crear. Una clase quiere sus subclases especifiquen los objetos que crean.Contexto: los frameworks utilizan clases abstractas para definir y mantener las relaciones entre objetos. Una responsabilidad es crear tales objetos.Solucin: definir una interfaz para crear un objeto, pero dejando la eleccin de su tipo a las subclases, la creacin se aplaza hasta el tiempo de ejecucin.

Factory MethodPatrones de creacin

Participantes Factory MethodProduct: define la interfaz para los objetos que FactoryMethod crea.ConcreteProduct: implementa la interfaz Product. Creator(o Factory): declara el mtodo FactoryMethod, que devuelve un objeto Producto. Puede llamar al mtodo de generacin para la creacin de objetos Product ConcreteCreator: sobre-escribe el mtodo de generacin para crear objetos ConcreteProduct.

Abstract FactoryProblema: se desea proporcionar una biblioteca de clases de productos. Tambin se quiere revelar slo sus interfaces, no sus implementaciones. Contexto: evitar aadir cdigo a las clases existentes con el fin de hacer que encapsule informacin ms general. Solucin: proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.

Abstract FactoryPatrones de creacin

Participantes Abstract FactoryAbstractFactory: declara una interfaz para las operaciones que crean AbstractProduct.ConcreteFactory: implementa operaciones para crear Product concretos.AbstractProduct: declara una interfaz para un tipo de objetos Product.Product: define un producto a ser creado por el ConcreteFactory correspondiente; que implementa la interfaz AbstractProduct.Client: utiliza las interfaces declaradas por las clases AbstractFactory y AbstractProduct.

BuilderProblema: cuanto ms complejo es una aplicacin, la complejidad de las clases y los objetos que utiliza aumenta.Contexto: una aplicacin necesitar un mecanismo para la creacin de objetos complejos que es independiente de los que componen el objeto.Solucin: define una instancia para la creacin de un objeto dejando que las subclases decidan qu clase instanciar.

BuilderPatrones de creacin

Participantes BuilderBuilder: especifica una interfaz abstracta para crear partes de un objeto de Product. ConcreteBuilder: construye une las partes del producto mediante la implementacin de la interfaz Builder.Director: construye el objeto complejo mediante la interfaz Builder.Product: representa el objeto complejo que se est construyendo.

SingletonAsegura que una clase tiene una nica instancia y proveer un punto de acceso global a ella.Inicializacin "just-in-time" o inicializacin "on first use" encapsulada.

SingletonPatrones de creacin

Patrones de estructura

Patrones de estructuraAdapter: relaciona interfaces de diferentes clases.Bridge: separa la interfaz de un objeto de su implementacin.Composite: una estructura de rbol de objetos simples y compuestos. Decorator: aadir responsabilidades a los objetos dinmicamente.Facade: una nica clase que representa todo un subsistema.Flyweight: una instancia usada para compartir de manera eficiente.Proxy: un objeto que representa a otro objeto.

AdapterProblema: se desea utilizar una clase existente, y su interfaz no coincide con la que necesita. Aplica de igual modo cuando se quieren crear clases reutilizables que cooperen con clases sin relacin o imprevistas. Contexto: relacionar dos componentes que no tienen una interfaz comn.Solucin: convertir la interfaz de una clase en otra interfaz que el clientes espera.

AdapterPatrones de estructura

Participantes AdapterTarget: define la interfaz de dominio especfico que utiliza Client. Adapter: adapta la interfaz Adaptee para la interfaz de destino. Adaptee: define una interfaz existente que necesita adaptarse. Client: colabora con objetos de acuerdo con la interfaz Target.

FacadeProblema: proveer una interfaz simple a un subsistema complejo. Contexto: minimizar la comunicacin y dependencias entre subsistemas. Solucin: proporcionar una interfaz unificada para un conjunto de interfaces de un subsistema.

FacadePatrones de estructura

Participantes FacadeFaade: conoce cules clases del subsistema son responsables por una peticin y delegan peticiones del cliente a los objetos del subsistema apropiado. Clases del subsistema: Implementan una funcionalidad del subsistema y llevan a cabo el trabajo asignado por el objeto Faade.

Patrones de comportamiento

CommandProblema: especificar, encolar y ejecutar peticiones en diferentes tiempos. Aplica tambin para callbacks.Contexto: emisin de peticiones a objetos sin saber nada de la operacin que se solicite o el receptor de la solicitud.Solucin: encapsular una peticin como un objeto y almacenar las peticiones en una cola.

CommandPatrones comportamiento

Participantes CommandCommand: declara una interfaz para ejecutar una operacin.ConcreteCommand: extiende de Command para implementar el mtodo ejecute al invocar las operaciones correspondientes en el Receiver.Invoker: le pide al Command que ejecute la peticin.Receiver: sabe cmo ejecutar las operaciones.Client: crea un objeto ConcreteCommand y le asigna su Receiver.

ObserverProblema: un cambio en un objeto requiere cambios en otros,y no se sabe cuntos objetos necesitan ser cambiados. Una abstraccin tiene dos aspectos dependientes.Contexto: al fragmentar un sistema en una coleccin de clases cooperativas, se requiere mantener la consistencia entre objetos relacionados.Solucin: definir un dependencia uno-a-muchos entre objetos, para que al cambiar un objeto, todos sus dependientes sean notificados automticamente.

ObserverPatrones de comportamiento

Participantes ObserverObservable: declara una interfaz para aadir o remover Observers del cliente.ConcreteObservable: extiende Observable. Mantiene el estado del objeto y cuando cambia, notifica a los Observers ligados.Observer: interfaz que define las operaciones a ser usadas para notificar a este objeto.ConcreteObserverA, ConcreteObserver2: implementaciones concretas de Observer.

StrategyProblema: se requieren diferentes variantes de un algoritmo.Contexto: clases relacionadas slo difieren en su comportamiento.Solucin: define una familia de algoritmos, los encapsula, y los hace intercambiables.

StrategyPatrones de comportamiento

Participantes StrategyStrategy: declara una interfaz para soportar todos los algoritmos ConcreteStrategy: extiende a Strategy. Cada ConcreteStrategy implementa un algoritmo. Context: mantiene una referencia al objeto Strategy y define una interfaz para una interface que deja a Strategy accesar sus datos.

Bibliografa

BibliografaGamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John(1995). Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Massachusetts: Addison Wesley Longman, Inc.