CLASIFICACINDEPATRONES Lospatronesdediseovaranensugranularidadyniveldeabstraccin. PROPSITO:Reflejaquehaceunpatrn.Puedeser: DeCreacin Estructurales DeComportamiento MBITO:Especificasielpatrnseaplicaprincipalmenteaclasesoaobjetos. AplicacinaClases AplicacinaObjetos Seocupandelasrelacionesentreclasesysussubclases.Estas relacionesseestablecenatravsdelaherencia,demodoque sonrelacionesestticas(fijadasentiempodecompilacin). Tratanconrelacionesentreobjetos,quepuedencambiarseen tiempodeejecucinysonmsdinmicas Tienenqueverconelprocesodecreacindeobjetos.

eobjetos. Tratanconlacomposicindeclasesuobjetos. Caracterizanelmodoenquelasclasesyobjetosinteractany serepartenlaresponsabilidad.

DEFINICIONES
SIGNATURA:Cadaoperacindeclaradaporunobjetoespecificaelnombredelaoperacin,los objetos que toma como parmetros y el valor de retorno de la operacin. Esto es lo que se conocecomosignaturadelaoperacin. INTERFAZDEOBJETO:Eselconjuntodetodaslassignaturasdefinidasporlasoperacionesde unobjeto. TIPO:Esunnombrequeseusaparadenotarunadeterminadainterfaz.Decimosqueunobjeto tiene el tipo ventana, si acepta todas las peticiones definidas en una interfaz llamada ventana.

CLASEABSTRACTA:Esaquellacuyopropsitoprincipalesdefinirunainterfazcomnparasus subclases. Una clase abstracta delegar parte o toda su implementacin en las operaciones definidasenlassubclases. OPERACIONES ABSTRACTAS: Son las operaciones que una clase abstracta define pero no implementa. CLASESCONCRETAS:Lasclasesquenosonabstractas,sedenominanconcretas.

MECANISMOSDEREUTILIZACIN
Lasdostcnicasmscomunesparareutilizarfuncionalidadensistemasorientadosaobjetos, son: HerenciadeClases ComposicindeObjetos HERENCIADECLASES Laherenciadeclasespermitedefinirunaimplementacinentrminosdeotra.Aestaforma dereutilizacinseladenominaReutilizacindeCajaBlanca. COMPOSICINDEOBJETOS Se obtiene ensamblando o componiendo objetos para obtener una funcionalidad ms compleja.AestaformadereutilizacinseladenominaReutilizacindeCajaNegra. DELEGACIN:Esunmododelograrquelacomposicinseatanpotenteparalareutilizacin cmo lo es la herencia. Con la delegacin, dos son los objetos de tratar una peticin: Un objetoreceptordelegaoperacionesensudelegado.

DISEARPARAELCAMBIO
Paramaximizarlareutilizacin,sedebeanticiparnuevosrequisitosycambiosenlosrequisitos existentes. Los patrones de diseo, ayudan a evitar esto, al asegurar que un sistema pueda cambiardeformasconcretas. Causascomunesderediseo: Crearunobjetoespecificandosuclaseexplcitamente. Dependenciadeoperacionesconcretas. Dependenciadeplataformasdehardwareosoftware. Fuerteacoplamiento. Incapacidadparamodificarclasesconvenientemente.

TOOLKITS: Es un conjunto de clases relacionadas y reutilizables diseadas para proporcionar funcionalidadtildepropsitogeneral. FRAMEWORKS:Es unconjuntodeclases cooperantesque constituyen un diseo reutilizable paraunaclaseespecficaesoftware.

CMOSELECCIONARUNPATRNDEDISEOAUTILIZAR?
UN PATRON DE DISEO SOLO DEBE SER APLICADO, CUANDO LA FLEXIBILIDAD QUE PROPORCIONE,SEAREALMENTENECESARIA. Considerarcmolospatronesdediseosolucionanelproblemadeldiseo? Revisarelpropsitoporelculfuecreadoelpatrn. Estudiarcmoserelacionanlospatrones. Estudiarpatronesdepropsitosimilar. Examinarlacausaderediseo.

PROPSITO PATRONESDECREACIN

Propsito Conocido como Motivacin

Factory Method Define un interfaz para crear un objeto, pero permite a las subclases decidir la clase a instanciar: instanciacindiferida a las subclases. Contructor Virtual Una clase C cliente de una clase abstracta A necesita crear instancias de subclases de A que no conoce. En un framework para aplicaciones que pueden presentar al usuario documentos de distinto tipo: Clases Aplicaciny Documento. Se conoce cundo crear un documento, no se conoce de qu tipo. Una clase no puede anticipar la clase de objetos que debe crear. Una clase desea que sus subclases especifiquen los objetos que debe crear. Una clase delega responsabilidad a una entre varias subclases clases accesorias (helper) y se quiere localizar el conocimiento de en qu subclase helper se delega. Producto: define la interfaz de los objetos que crea el metodo de fabricacin ProductoConcreto: implementa la interfaz Producto Creador: declara el metodo de fabricacion, el cual devuelve un objeto de tipo Producto. Tambien puede definir una implementacion predeterminada del metodo de fabricacion que devuelve un objeto ProductoConcreto. - puede llamar al metodo de fabricacion para crear un objeto Producto CreadorConcreto: redefine el metodo de fabricacion para devolver una instancia de un ProductoConcreto El Creador se apoya en sus subclases para definir el metodo apropiado de fabricacion de manera que este devuelva una instancia del ProductoConpreto apropiado Evita ligar un cdigo a clases especficas de la aplicacin. Puede suceder que las subclases de Creador slo se crean con el fin de la creacin de objetos. Mayor flexibilidad en la creacin: subclases ofreciendo versiones extendidas de un objeto. El mtodo factora puede ser invocado por un cliente, no slo por la clase Creador: jerarquas paralelas

Aplicabilidad

Participantes

Colaboraciones

Consecuencias

Implementacin

Dos posibilidades Creadores una clase abstracta con un mtodo factora abstracto. Creadores una clase concreta que ofrece una implementacin por defecto del mtodo factora. El mtodo factora puede tener un parmetro que identifica a la clase del objeto a crear. Se evita crear subclases de Creadorcon: Metaclases(Smalltalky Java) Genericidad(C++) Si tuvieramos clases mas complejas de logica de negocio, podriamos definir una interfaz y delegar la responsabilidad de la creacion de objetos a las subclases de logica de negocio Abstract Factory - Prototype

Uso en el proyecto Patrones Relacionados

AMBITO : CLASES

Propsito Conocido como Motivacin Aplicabilidad

Abstract Factory proporciona una interfaz para crear familias de objetos relacionados o que dependen entre si, sin especificar sus clases concretas Kit Un toolkitinterfaz de usuario que soporta diferentes formatos: Windows, Motif, X-Windows,.. Un sistema debera ser independiente de cmo sus productos son creados, compuestos y representados Un sistema debera ser configurado para una familia de productos. Una familia de objetos productosrelacionados es diseada para ser utilizado juntos y se necesita forzar la restriccin. Se quiere proporcionar una librera de clases de productos y se quiere revelar slo la interfaz, no la implementacin. FabricaAbstracta: declara una interfaz de operaciones que crean objetos productos abstractos FabricaConcreta: implementa las operaciones para crear objetos producto concretos ProductoAbstracto: declara una interfaz para un tipo de objeto producto ProductoConcreto: define un objeto producto para que sea creado por la fabrica correspondiente - implementa la interfaz ProductoAbstracto Cliente: solo usa interfaces declaradas por las clases FabricaAbstracta y ProductoAbstracto normalmente solo se crea una unica instancia de una clase FabricaConcreta en tiempo de ejecucin. Esta fabrica concreta crea objetos que tienen una determinada implementacin. Para crear diferentes objetos producto, los clientes deben usar una fabrica concreta diferente.

Participantes

Colaboraciones

FabricaAbstracta delega la creacin de objetos en su subclase FabricaConcreta. Aisla a los clientes de las clases concretas de implementacin. Facilita el intercambio de familias de productos. Favorece la consistencia entre productos Es difcil soportar nuevas clases de productos. Implementacin Factoras como singleton. Se necesita una subclase de AbstractFactorypor cada clase de producto que redefine un mtodo factora. Posibilidad de usar el patrn Prototype. Definir factoras extensibles: AbstractFactoryslo necesita un mtodo de creacin. se puede utilizar como metodo de creacion de menues dinamicos dependiendo de los permisos Uso en el proyecto de los usuarios, tambien para la distribucion dinamica de los reportes (en el caso de generarlos con alguna herramienta distinta a Crystal Report) Patrones Factory Method - Prototype - Singleton Relacionados Consecuencias

AMBITO : OBJETOS

Propsito Conocido como Motivacin Aplicabilidad

Builder Separa la construccin de un objeto complejo de su representacin, asq ue el mismo proceso de construccin puede crear diferentes representaciones.
Constructor

Un traductor de documentos RTF a otros formatos. Es posible aadir una nueva conversin sin modificar el traductor? Cuando el algoritmo para crear un objeto complejo debe ser independiente de las piezas que conforman el objeto y de cmo se ensamblan. El proceso de construccin debe permitir diferentes representaciones para el objeto que se construye. Constructor: especifica una interfaz abstracta para crear las partes de un objeto Producto ConstructorConcreto: implementa la interfaz Constructor para construir y ensamblar las partes del Producto - define la representacion a crear - proporciona una interfaz para devolver el producto Director: construye un objeto usando la interfaz Constructor Producto: representa el objeto complejo e construccion. EL ConstructorConcreto construye la representacion interna del producto y define el proceso de ensamblaje. Incluye las clases que definen sus partes constituyentes, incluyendo interfaces para ensamblar las partes en el resultado final. El cliente crea el objeto Director y lo configura con el objeto Constructor deseado. El Directos notifica al constructor cada vez que hay que construir una parte de un producto El Constructor maneja las peticiones del director y las aade al producto El cliente obtiene el producto del constructor. Permite cambiar la representacin interna del producto. Separa el cdigo para la representacin y para la construccin. Los clientes no necesitan conocer nada sobre la estructura interna. Diferentes directorespueden reutilizarun mismo builder Proporciona un control fino del proceso de construccin. La interfaz de Builderdebe ser lo suficientemente general para permitir la construccin de productos para cualquier Builderconcreto. La construccin puede ser ms complicada de aadir el nuevo tokenal producto en construccin. Los mtodos de Builderno son abstractos sino vacos. Las clases de los productos no tienen una clase abstracta comn.

Participantes

Colaboraciones

Consecuencias

Implementacin

Uso en el proyecto Patrones Relacionados Abstract Factory - Composite

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Prototype Especificar los tipos de objetos a crear utilizando una instancia prototpica, y crear nuevas instancias mediante copias del prototipo. Necesidad de abstraer lgica de decisin La aplicacin debe decidir el uso de objetos Uso en tiempo de ejecucin Cuando un sistema deba ser independiente de cmo sus productos son creados, compuestos y representados y: las clases a instanciarson especificadas en tiempo de ejecucin. para evitar crear una jerarqua de factoras paralela a la de productos.
cuando las instancias de una clase slo pueden encontrarse en uno de un pequeo grupo de estados. Inicializar un objeto es costoso

Aplicabilidad

Participantes

Prototipo: declara una interfaz para clonarse PrototipoConcreto: implementa una operacin para clonarse Cliente: crea un nuevo objeto pidiendole a un prototipo que se clone un Cliente le pide a un prototipo que se clone Al igual que con Buildery FactoryAbstract oculta al cliente las clases producto concretas. Es posible aadir y eliminar productos en tiempo de ejecucin: mayor flexibilidad que los anteriores. La composicin reduce el nmero de clases que es necesario crear. Un objeto prototipo puede estar formado por otros primitivos.
Reduce la necesidad de crear subclases. Posibilidad de usar clases cargadas dinmicamente.

Colaboraciones Consecuencias

Implementacin

Importante en lenguajes que no soportan el concepto de metaclase, as en Smalltalk o Java es menos importante. Usar un manejador de prototipos que se encarga del mantenimiento de una tabla de prototipos. Implementar la operacin clone es lo ms complicado. A veces se requiere inicializar el objeto creado mediante copia: prototipo con operaciones set.

Uso en el proyecto El tamaoy complejidad del desarrollo no justifica la implementacion de este patron Patrones Relacionados Abstract Factory - Composite - Decorator

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Singleton Asegurar que una clase tiene una nica instancia y asegurar un acceso global Una nica instancia de la clase que maneja las ventanas, o de un spooler de impresoras o de un sistema de ficheros o de una factora. La clase se encarga de asegurar que exista una nica instancia y de su acceso. Debe existir una nica instancia de una clase, accesible globalmente. Singleton: define una operacin que permite que los clientes accedan a su unica instancia. Instancia es una operacin de clase. Puede ser responsable de crear su unica instancia Los clientes acceden a la instancia de un Songleton exclusivamente a traves de la operacin Instancia de ste. Acceso controlado a la nica instancia Evita usar variables globales Generalizar a un nmero variable de instancias La clase Singleton puede tener subclases. Garantizar una nica instancia Crear una sublcase de Singleton

Aplicabilidad Participantes

Colaboraciones Consecuencias

Implementacin

Uso en el proyecto Conexin a la BD Patrones Relacionados Abstract Factory - Builder - Prototype

PROPSITO PATRONESESTRUCTURALES

Propsito Conocido como Motivacin

Adapter Convertir la interfaz de una clase en otra que el cliente espera. Permite la colaboracin de ciertas clases a pesar de tener interfaces incompatibles Wrapper Un editor grfico incluye una jerarqua que modela elementos grficos (lneas, polgonos, texto,..) y se desea reutilizar una clase existente TextView para implementar la clase que representa elementos de texto, pero que tiene una interfaz incompatible. Se desea usar una clase existente y su interfaz no coincide con la que se necesita: se quiere usar una clase que invoca a un mtodo a travs de una interfaz, pero quiere usarse con otra clase que no implementa la interfaz

Aplicabilidad

Se desea crear una clase reutilizable que debe colaborar con clases no relacionadas o imprevistas.
(slo adaptador-objeto) se necesita usar varias subclases y es incmodo adaptar su interfaz aplicando subclassing.

Participantes

Objetivo: define la interfaz especifica del dominio que usa el cliente Cliente: colabora con objetos que se ajustan a la interfaz Objetivo Adaptable: define una interfaz existente que necesita ser adaptada Adaptador: adapta la interfaz de Adaptable a la interfaz Objetivo los Clientes llaman a operaciones de una instancia da Adaptador. A su vez, el adaptador llama a operaciones de Adaptable, que son las que satisfacen la peticin Un adaptador-clase no funciona cuando queramos adaptar una clase y sus subclases. Un adaptador-clase puede redefinir comportamiento heredado de Adaptado. Un adaptador-clase no implica ninguna indireccin, slo introduce un objeto. Un adaptador-objeto permite adaptar una clase y sus subclases, pudiendo aadir funcionalidad a todos los adaptados a la vez.
Para un adaptador-objeto es complicado redefinir comportamiento de Adaptado. La funcionalidad de Adaptador depende de la similitud entre la interfaz de las clases Objetivoy Adaptado. Adaptorespluggable: Clases que incorporan una adaptacin de interfaz Cmo podemos conseguir que una clase reutilizable pueda incorporarse en sistemas existentes que esperan interfaces diferentes a la de la clase? Ejemplo: Clase TreeDisplaypara visualizar estructuras jerrquicas (widget), exige que los objetos a visualizar tengan una determinada interfaz, p.e. clase abstracta Tree?

Colaboraciones

Consecuencias

Implementacin

En C++, la clase Adaptadorhereda en modo privado de Adaptadoy en modo pblico de Objetivo. Tres posibles implementaciones de adaptadoresplugabbles: Con operaciones abstractas Con delegacin de objetos Adaptadores parametrizados

Uso en el proyecto se puede definir un Wrapper de cliente si existe un tipo de cliente especifico Patrones Relacionados Bridge - Decorator - Proxy

AMBITO : CLASES / OBJETOS

Propsito Conocido como Motivacin

Bridge Desacoplar una abstraccin de su implementacin, de modo que los dos puedan cambiar independientemente. Handle / Body Clase que modela la abstraccin con subclases que la implementan de distintos modos. Herencia hace difcil reutilizar abstracciones e implementaciones de forma independiente Si refinamos la abstraccin en una nueva subclase, esttendrtantas subclases como tena su superclase.
El cdigo cliente es dependiente de la plataforma. Implementacin de una abstraccin windowportableen una librera GUI.

Aplicabilidad

Se quiere evitar una ligadura permanente entre una abstraccin y su implementacin, p.e. porque se quiere elegir en tiempo de ejecucin. Abstracciones e implementaciones son extensibles. Cambios en la implementacin de una abstraccin no deben afectar a los clientes (no recompilacin).
Ocultar a los clientes la implementacin de la interfaz. Se tiene una proliferacin de clases, como suceda en la Motivacin.

Participantes

Abstraccion: define la interfaz de la abstraccion - mantiene una referencia a un objeto de tipo Implementador AbstraccionRedefinida: extiende la interfaz definida por Abstraccion Implementador_ define la interfaz de las clases de Implementacion. Esta interfaz no tiene por qu corresponderse exactamente con la de Abstraccion; de hecho, ambas interfaces pueden ser muy distintas. Normalmente la interfaz Implementador slo proporciona operaciones primitivas y Abstraccion define operaciones de mas alto nivel basadas en dichas primitivas ImplementadorConcreto: implementa la interfaz Implementador y define su implementacion concreta

Colaboraciones Consecuencias

Abstraccion redirige las peticiones del cliente a su objeto Implementador Un objeto puede cambiar su implementacin en t.e. Cambios en la implementacin no motivarn recompilacionesde la clase Abstracciny sus clientes. Se mejora la extensibilidad Se ocultan detalles de implementacin a los clientes Aunque exista una nica implementacin puede usarse el patrn para evitar que un cliente se vea afectado si cambia. Cmo, cundo y dnde se decide que implementacin usar? Constructor de la clase Abstraccion Elegir una implementacin por defecto Delegar a otro objeto, p.e. un objeto factora Se puede usar herencia mltiple para heredar de la abstraccin y de una implementacin concreta, pero se liga una interfacea una implementacin de forma permanente.

Implementacin

Uso en el proyecto idem al wrapper dependiendo de la necesidad Patrones Relacionados Abstract Factory - Adapter

AMBITO : OBJETOS

Composite Propsito Conocido como Motivacin Componer objetos en estructuras jerrquicas para representar jerarquas parte/todo. Permite a los clientes manejar a los objetos primitivos y compuesto de forma uniforme. Modelar figuras compuestas Modelar paquetes de valores (acciones, bonos,..) Se quiere representar jerarquas parte/todo Se quiere que los clientes ignoren la diferencia entre objetos compuestos y los objetos individuales que los forman. Componente: declara la interfaz de los objetos de la composicion - implementa el comportamiento predeterminado de la interfaz que es comun a todas las clases - declara una interfaz para acceder a sus componentes hijos y gestionarlos - define una interfaz para acceder al padre de un componente en la estructura recursiva y, si es necesario, la implementa Hoja: representa objetos hoja en la composicion. Una hoja no tiene hijos - define el comportamiento de los objetos primitivos de la composicion Compuesto: define el comportamiento de los componentes que tienen hijos - almacena componentes hijos - implementa las operaciones de la interfaz Componente relacionadas con los hijos Cliente: manipula objetos en la composicion a traves de la interfaz Componente Los Clientes usan la interfaz de la clase Componente para interactuar con los objetos de la estructura compuesta, Si el recipiente es una hoja, la peticion se trata correctamente. Si es un Compuesto, normalmente redirige las peticiones a sus componentes hijos, posiblemente realizando operaciones adicionales antes o despues Jerarqua con clases que modelan objetos primitivos y objetos compuestos, que permite composicin recursiva. Clientes pueden tratar objetos primitivos y compuestos de modo uniforme. Es fcil aadir nuevos tipos de componentes. No se puede confiar al sistema de tipos que asegure que un objeto compuesto slo contendrobjetos de ciertas clases, necesidad de comprobaciones en tiempo de ejecucin. Referencias de componentes hijos a su padre puede ayudar a el recorrido y manejo de la estructura compuesta. Debe contener Componenteoperaciones que no tienen significado para sus subclases? Dnde colocamos las operaciones de aadir y eliminar hijos? Compromiso entre seguridad y transparencia. Transparencia: clase Componente Seguridad: clase hijo Seguridad: Puede ser necesario especificar un orden en los hijos.
Uso de cach. Qu estructura de datos es la adecuada?

Aplicabilidad

Participantes

Colaboraciones

Consecuencias

Implementacin

Uso en el proyecto si utilizamos el MVC la parte vista es una implementacion de composite Patrones Relacionados Chain of Responsability - Decorator - Flyweight - Iterator - Visitor

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Decorator Asignar dinmicamente nuevas responsabilidades a un objeto. Alternativa ms flexible a crear subclases para extender la funcionalidad de una clase. Wrapper Algunas veces se desea aadir atributos o comportamiento adicional a un objeto concreto no a una clase. Ejemplo: bordes o scrolling a una ventana. Herencia no lo permite. Aadir dinmicamente responsabilidades a objetos individuales de forma transparente, sin afectar a otros objetos. Responsabilidades de un objeto pueden ser eliminadas. Para evitar una explosin de clases que produce una jerarqua inmanejable. Componente: define la interfaz para objetos a los que se puede aadir responsabilidades dinamicamente ComponenteConcreto: define un objeto al que se pueden aadir responsabilidades adicionales Decorador: mantiene una referencia a un objeto Componente y define una interfaz que se ajusta a la interfaz del Componente DecoradorConcreto: aade responsabilidades al componente

Aplicabilidad

Participantes

Colaboraciones

el Decorador redirige peticionesa su objeto Componente. Opcionalmente puede realizar operaciones adicionales antes y despus de reenviar la peticin. Ms flexible que la herencia: responsabilidades pueden aadirse y eliminarse en tiempo de ejecucin. Diferentes decoradores pueden ser conectados a un mismo objeto. Reduce el nmero de propiedades en las clases de la parte alta de la jerarqua. Es simple aadir nuevos decoradores de forma independiente a las clases que extienden.
Un objeto decorador tiene diferente OID al del objeto que decora. Sistemas con muchos y pequeos objetos.

Consecuencias

Implementacin

La interfaz de un objeto decorador debe conformar con la interfaz del objeto que decora. Clases decorador deben heredar de una clase comn. Componentes y decoradores deben heredar de una clase comn que debe ser ligeraen funcionalidad. Si la clase Componente no es ligera, es mejor usar el patrn Strategy que permite alterar o extender el comportamiento de un objeto. Un componente no sabe nada acerca de sus decoradores, con Strategy sucede lo contrario. El decorador enva los mensajes al componente que decora, pudiendo extender la operacin con nuevo comportamiento. Las clases que modelan los decoradores concretos pueden aadir responsabilidades a las que heredan de Decorator.

Uso en el proyecto se puede usar el patron Decorator en la parte vista de MVC Patrones Relacionados Adapter - Composite - Strategy

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Facade Proporciona una nica interface a un conjunto de interfaces de un subsistema. Define una interfaz de ms alto nivel que facilita el uso de un subsistema. Reducir las dependencias entre subsistemas. Un entorno de programacin que ofrece una librera de clases que proporcionan acceso a su subsistema compilador: Scanner, Parser, ProgramNode, ByteCodeStreamy ProgramNodeBuilder. Clase Compileracta como fachada. Proporcionar una interfaz simple a un subsistema. Hay muchas dependencias entre clientes y las clases que implementan una abstraccin.

Aplicabilidad

Se desea una arquitectura de varios niveles: una fachada define el punto de entrada para cada nivel subsistema.

Participantes

Fachada: sabe que clases el subsitema son las responsables ante una peticion - delega las peticiones de los clientes en los objetos apropiados del subsistema Clases del subsitema: implementacion la funcionalidad del subsistema - realizan las labores encomendadas por el objeto Fachada - no conocen a la fachada, es decir, no tienen referencias a ella Los clientes se comunican con el subsistema a travs de la fachada, que reenva las peticiones a los objetos del subsistema apropiados y puede realizar tambin algn trabajo de traduccin.
Los clientes que usan la fachada no necesitan acceder directamente a los objetos del sistema

Colaboraciones

Consecuencias

Una fachada ofrece los siguientes beneficios: 1) Facilita a los clientes el uso de un subsistema, al ocultar sus componentes. 2) Proporciona un acoplamiento dbil entre un subsistema y los clientes: cambios en los componentes no afectan a los clientes. 3) No se impide a los clientes el uso de las clases del subsistema si lo necesitan. Es posible reducir el acoplamiento entre clientes y subsistema, definiendo la fachada como una clase abstracta con una subclase por cada implementacin del subsistema. La fachada no es la nica parte pblica de un subsistema, sino que es posible declarar clases individuales del subsistema como pblicas (paquetes en Java, namespaceen C++). si implementaramos que es sistema desarrollado envie un mail en caso de un error al administracion Abstract Factory - Mediator - Singleton

Implementacin

Uso en el proyecto Patrones Relacionados

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Flyweight Uso de la comparticin para soportar eficientemente un gran nmero de objetos de poco tamao En una aplicacin editor de documentos, modelamos los caracteres mediante una clase? Un flyweight es un objeto compartido que puede ser utilizado en diferentes contextos simultneamente. No hace asunciones sobre el contexto
Estado intrnseco vs. Estado extrnseco Estado intrnseco se almacena en el flyweighty consiste de informacin que es independiente del contexto y se puede compartir. Estado extrnseco depende del contexto y por tanto no puede ser compartido. Objetos clientes son responsables de pasar el estado extrnseco al flyweightcuando lo necesita. Flyweight se usan para modelar conceptos o entidades que son muy abundantes para representarse con objetos, p.e. caracteres de un texto.

Aplicabilidad

Aplicarlo siempre que se cumplan las siguientes condiciones: 1) Una aplicacin utiliza un gran nmero de objetos.
2) El coste de almacenamiento es alto debido al excesivo nmero de objetos. 3) La mayor parte del estado de un objeto puede hacerse extrnseco.

4) Muchos grupos de objetos pueden reemplazarse por unos pocos objetos compartidos al separar el estado extrnseco.
5) La aplicacin no depende de la identidad de los objetos.

Participantes

PesoLigero: declara una interfaz a traves de la cual los pesos ligeros pueden recibir un estado extrinseco y actuar sobre l PesoLigeroConcreto PesoLigeoConcretoNoCompartido FabricaDePesoLigero
Cliente

Colaboraciones

el estado que un peso ligero necesita para funcionar debe ser caracterizado como intrinseco o extrinseco
los clientes no deberian crear instancias de PesoLigeroConcreto directamente

Consecuencias

Puede introducir costes run-timedebido a la necesidad de calcular y transferir el estado extrnseco. La ganancia en espacio depende de varios factores: la reduccin en el nmero de instancias el tamao del estado intrnseco por objeto
si el estado extrnseco es calculado o almacenado Interesa un estado intrnseco calculado Se suele combinar con el Composite.

Implementacin

La aplicabilidad depende de la facilidad de obtener el estado extrnseco. Idealmente debe poder calcularse a partir de una estructura de objetos que necesite poco espacio de memoria. Debido a que los flyweight son compartidos, no deberan ser instanciados directamente por los clientes: clase FlyweightFactory.

Uso en el proyecto .Net implementa iunternamente esta patron (barras de scroll, botones, menus) Patrones Relacionados Composite - State - Strategy

AMBITO : OBJETOS

Proxy Propsito Conocido como Motivacin Proporcionar un sustituto (surrogate) de un objeto para controlar el acceso a dicho objeto. Surrogate Diferir el coste de crear un objeto hasta que sea necesario usarlo: creacin bajo demanda. Un editor de documentos que incluyen objetos grficos. Cmo ocultamos que una imagen se crear cuando se necesite?: manejar el documento requiere conocer informacin sobre la imagen. Aplicabilidad Siempre que hay necesidad de referenciar a un objeto mediante una referencia ms rica que una referencia normal. Situaciones comunes;
1) Proxyacceso remoto(acceso a un objeto en otro espacio de direcciones) 2) Proxyvirtual(crea objetos grandes sobre demanda)

3) Proxypara proteccin(controlar acceso a un objeto)

4) Referencia inteligente(smartreference)

Participantes

Proxy Sujeto SujetoReal

Colaboraciones Consecuencias

El proxy redirihe peticiones al SujetoReal cuando sea necesario, dependiendo del tipo de proxy Introduce un nivel de indireccinpara: 1) Un proxyremoto oculta el hecho que objetos residen en diferentes espacios de direcciones. 2) Un proxyvirtual tales como crear o copiar un objeto bajo demanda. 3) Un proxypara proteccin o las referencias inteligentes permiten realizar tareas de control sobre los objetos accedidos.

Implementacin

Sobrecargar el operador de acceso a miembros (->) en C++. En Smalltalk, posibilidad de definir Proxy como una clase que hereda de nil(no comprende ningn mensaje) y redefinir doesNotUnderstand para redirigir los mensajes al objeto sujeto. Puede suceder que baste con definir una nica clase Proxypara todos los tipos de sujetos.

Uso en el proyecto Patrones Relacionados Adapter - Decorator

AMBITO : OBJETOS

PROPSITO PATRONESDE COMPORTAMIENTO

Interpreter Propsito Conocido como Motivacin Dado un lenguaje, definir una representacin para su gramtica junto con un intrprete que utiliza la representacin para interpretar sentencias en dicho lenguaje. Interpretar una expresin regular. Usa una clase para representar cada regla, los smbolos en la parte derecha son atributos. Usar si la gramtica es simple y la eficiencia no es importante. El uso de este patrn est indicado cuando hay un lenguaje que interpretar y se pueden representar sus palabras como rboles sintcticos abstractos. Funciona mejor si: La gramtica es simple. Para gramticas complejas la jerarqua de clases se vuelve inmanejable.
La eficiencia no es importante. Los intrpretes ms eficientes no se consiguen interpretando rboles; normalmente se hace con mquinas de estados.

Aplicabilidad

Participantes

ExpresionAbstracta ExpresionTerminal ExpresionNoTerminal Contexto

Cliente

Colaboraciones

el cliente construye la sentencia como un arbol sintactico abstracto formado por instancias de ExpresionNoTerminal y ExpresionTerminal. A continuacion el cliente inicializa el contexto e invoca la operacin Interpretar
Cada nodo ExpresionNoTerminal define Interpretar en terminos del Interpretar de cada subexpresion. La operacin Interpretar de cada ExprecionTerminal define el caso base de la recursion Las operaciones Interpretar de cada nodo usan el contexto para almacenar y acceder al estado del interprete

Consecuencias

Es fcil cambiar y ampliar la gramtica. Aprovechando la herencia. Es fcil implementar la gramtica. Las clases son fciles de escribir.
Aadir nuevos modos de interpretar expresiones. Facilita evaluar una expresin de una manera distinta. Como inconveniente las gramticas complejas son difciles de mantener Si la gramtica tiene muchas reglas, el nmero de clases se hace muy grande.

Implementacin

Los problemas especficos de Interpreter: No hay que definir la operacin Interpretar en cada clase de expresin. Si un lenguaje tiene varias interpretaciones, es mejor colocarlos en instancias del patrn Visitor. Las gramticas con un gran nmero de smbolos terminales pueden beneficiarse compartiendo una copia nica de cada smbolo terminal con el patrn Flyweight.

Uso en el proyecto si utilizaramos un arbol (automata) de validaciones se podria implementar este patron Patrones Relacionados Composite - Flyweight - Iterator - Visitor

AMBITO : CLASES

Propsito Conocido como Motivacin

Template Method Define el esqueleto (esquema, patrn) de un algoritmo en una operacin, difiriendo algunos pasos a las subclases. Permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo. Fundamental para escribir cdigo en un framework framework. Clase Aplicacin que maneja objetos de la clase Documento: mtodo OpenDocument

Aplicabilidad

Implementar las partes fijas de un algoritmo y dejar que las subclases implementen el comportamiento que puede variar. Cuando el comportamiento comn entre varias subclases debe ser factorizado y localizado en una superclase comn.
Controlar extensiones de las subclases: algoritmos con puntos de extensin

Participantes P ti i t Colaboraciones Consecuencias

ClaseAbstracte Cl Ab t t ClaseConcreta

Tcnica fundamental para la reutilizacin: factorizar comportamiento comn en libreras de clases Estructura de control invertida conocida como Principio de Hollywood: No nos llames, nosotros te llamaremos. Un mtodo plantilla (template) invoca a los siguientes tipos de mtodos: operaciones concretas en la subclase concreta o en clientes
operaciones concretas en la clase abstracta operaciones abstractas (primitivas) mtodos factora mtodos hookque proporcionan comportamiento por defecto

Implementacin

Minimizar el nmero de mtodos que es necesario redefinir en las subclases. Nombrar a los mtodos que se deben redefinir aadindole cierto prefijo, p.e. do. En C++, mtodos a redefinir son protegidos y virtuales, el mtodo plantilla no ser virtual.

Uso en el proyecto en todo el proyecto Patrones Relacionados Factory - Strategy

AMBITO : CLASES

Propsito Conocido como Motivacin

Chain of Responsability Evita acoplar el emisor de un mensaje a su receptor dndole a ms de un objeto la posibilidad de manejar la solicitud. Se define una cadena de objetos, de modo que un objeto pasa la solicitud al siguiente en la cadena hasta que uno la maneja. Facilidad de ayuda sensible al contexto. El objeto que proporciona la ayuda no es conocido al objeto (p.e. Un Button) que inicia la solicitud de ayuda. Ms de un objeto puede manejar una solicitud, y el manejador no se conoce a priori. Se desea enviar una solicitud a uno entre varios objetos sin especificar explcitamente el receptor.
El conjunto de objetos que puede manejar una solicitud puede ser especificado dinmicamente.

Aplicabilidad

Participantes

Manejador: define una interfaz para tratar las peticiones - implementa el enlace al sucesor ManejadorConcreto: trata las peticiones de las que es responsable - puede acceder a su sucesor - si el ManejadorConcreto puede manejar la peticin, lo hace; en caso contrario la reenvia a su sucesor Cliente: inicializa la peticin a un objeto ManejadorConcreto de la cadena

Colaboraciones Consecuencias

cuando un Cliente envia una peticion, sta se propaga a traves de la cadena hasta que un objeto ManejadorConcreto se hace responsable de procesarla Reduce acoplamiento Proporciona flexibilidad al asignar responsabilidades No se garantiza el manejo de la solicitud Dos posibles formas de implementar la cadena Definir nuevos enlaces (en Manejador) Usar enlaces existentes (p.e. un objeto composite) Qu sucede si tenemos diferentes tipos de solicitudes? En Manejadorun mtodo para cada solicitud En el caso de Java, una interfaz por solicitud En Manejador un nico mtodo con un parmetro que representa el tipo de solicitud, por ejemplo un String.
En Manejador un nico mtodo que tiene un parmetro de una clase Solicitud que representa la solicitud.

Implementacin

Uso en el proyecto Para administrar eventos de los usuarios (.NET lo implementa internamente) Patrones Relacionados Composite

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Command Encapsula un mensaje como un objeto, permitiendo parametrizar los clientes con diferentes solicitudes, aadir a una cola las solicitudes y soportar funcionalidad deshacer/rehacer(undo/redo) Action - Transaction Algunas veces es necesario enviar mensaje a un objeto sin conocer el selector del mensaje o el objeto receptor. Por ejemplo widgets(botones, mens,..) realizan una accin como respuesta a la interaccin del usuario, pero no se puede explicitar en su implementacin. Parametrizar objetos por la accin a realizar (en lenguajes proceduralesc on funciones Callback: funcin que es registrada en el sistema para ser llamada ms tarde; en C++ se puede usar punteros a funciones). Especificar, aadir a un cola y ejecutar mensajes en diferentes instantes: un objeto Command tiene un tiempo de vida independiente de la solicitud original.
Soportar facilidad undo/redo. Recuperacin de fallos.

Aplicabilidad

Modelar transacciones

Participantes

Orden: declara una interfaz para ejecutar una operacin OrdenConcreta: define un enlace entre un objeto Receptor y una accion - implmenta Ejecutar invocando la correspondiente operacin u operaciones del Receptor Cliente: crea un objeto OrdenConcreta y establece su receptor Invocador: le pide a la orden que ejecute la peticion
Receptor: sabe como llevar a cabo las operaciones asociadas a una peticion. Cualquier clase puede hacer actuar como receptor

Colaboraciones

el cliente crea un objeto OrdenConcreta y especifica su receptor

un objeto Invocador almacena el objeto ordenConcreta el Invocador envia una peticion llamando a Ejecutar sobre la orden el objeto OrdenCOncreta invoca operaciones de su receptor para llevar a cabo la peticion

Consecuencias

Desacopla el objeto que invoca la operacin del objeto que sabe cmo realizarla. Cada subclase CommandConcreto especifica un par receptor/accion, almacenando el receptor como un atributo e implementando el mtodo ejecutar. Objetos command pueden ser manipulados como cualquier otro objeto. Se pueden crear command compuestos (aplicando el patrn Composite).
Es fcil aadir nuevos commands.

Implementacin

Cul debe ser la inteligencia de un command? No delegar en nadie Encontrar dinmicamente el objeto receptor y delegar en l Soportar undo/redo Atributos para almacenar estado y argumentos de la operacin. Lista de objetos commands En la lista se colocan copias.
Un objeto Command es realmente un Adapter: Command plugabble. Podemos evitar la jerarqua de subclases de Command si no necesitamos la facilidad undo/redo. Es posible asociar a un command ms de una accin (evento en un widget).

Uso en el proyecto Patrones Relacionados

se podria implementar una serie de acciones que respondan al un boton cancelar (se define como interfaz) y cada form haria su implementacion Composite - Memento - Prototype

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Iterator Proporciona una forma para acceder a los elementos de una estructura de datos sin exponer los detalles de la representacin. Cursor Un objeto contenedor tal como una lista debe permitir una forma de recorrer sus elementos sin exponer su estructura interna. Debera permitir diferentes mtodos de recorrido Debera permitir recorridos concurrentes
No queremos aadir esa funcionalidad a la interfaz de la coleccin Una clase Iterator define la interfaz para acceder a una estructura de datos (p.e. una lista). Iteradores externos vs. Iteradores internos. Iteradore sexternos: recorrido controlado por el cliente Iteradores internos: recorrido controlado por el iterador

Aplicabilidad

Acceder al contenido de un objeto agregado sin exponer su representacin interna. Permitir varios recorridos sobre objetos agregados.
Proporcionar una Interfaz uniforme para recorrer diferentes estructuras agregadas (Iteracin Polifrmica).

Participantes

Iterador: Define una Interfaz para recorrer los elementos y acceder a ellos. IteradorConcreto: Implementa la interfaz Iterador. - Mantiene la posicin actual en el recorrido del agregado. Agregado: Define una interfaz para crear un objeto Iterador. AgregadoConcreto: Implementa la interfaz de creacin de Iterador para devolver una instancia del IteradorConcreto apropiado. un IteradorConcreto sabe cual es el objeto actual del agregado y puede calcular el objeto siguiente en el recorrido Simplifica la interfaz de un contenedor al extraer los mtodos de recorrido Permite varios recorridos, concurrentes Soporta variantes en las tcnicas de recorrido El patrn Iterador tiene muchas variantes y alternativas de implementacin. Quien controla la Iteracin? Quin define el algoritmo de recorrido? Cmo es de robusto el Iterador? Operadores adicionales de Iterador Usar iteradores polimrficos en C++ Los iteradores pueden tener un acceso restringido
Iteradores en lugar compuesto Iteradores Nulos

Colaboraciones Consecuencias

Implementacin

Uso en el proyecto si la logica de persistencia la delegamos en la BD, podemos usar cursores en los sp Patrones Relacionados Factory Method - Memento - Composite

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Mediator Define un objeto que encapsula como interaccionan un conjunto de objetos. Favorece un bajo acoplamiento, liberando a los objetos de referenciarse unos a otros explcitamente, y permite variar la interaccin de manera independiente. Muchas interconexiones entre objetos dificulta la reutilizacin y la especializacin del comportamiento. Ventana que incluye un conjunto de elementos grficos con dependencias entre ellos.

Aplicabilidad

Un conjunto de objetos se comunica entre s de una forma bien definida, pero compleja. Las interdependencias son poco estructuradas y difciles de comprender. Reutilizar una clase es difcil porque tiene dependencias con muchas otras clases.
Un comportamiento que es distribuido entre varias clases debera ser adaptable sin crear subclases.

Participantes

Mediador: define una interfaz para comunicarse con sus objetos Colega MediadorConcreto: implementa el comportamiento cooperativo coordinando objetos Colegas Clases Colega: cada clase Colega conoce a su objeto Mediador - cada Colega se comunica con su mediador cada vez que, de no existir ste, se hubiera comunicado con otro Colega

Colaboraciones Consecuencias

Los Colegas envan y reciben peticiones a traves de un Mediador. El mediador implementa el comportamient cooperativo encaminando estas peticiones a los Colegas apropiados Evita crear subclases Desacopla a los colegas. Simplifica los protocolos entre las clases Abstrae el cmo cooperan los objetos
Centraliza el control en el mediador: clase difcil de mantener

Implementacin

No hay necesidad de definir una clase abstracta Mediator si los colegas trabajan con un nico mediador. Los colegas deben comunicarse con el mediador cuando un evento de inters ocurre, varias posibilidades: patrn Observer interfaz de notificacin especializada en Mediator(Smalltalk-V): clase ViewManager

Uso en el proyecto Patrones Relacionados Facade - Observer

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Memento Captura y exterioriza el estado interno de un objeto, sin violar la encapsulacin, de modo que el objeto puede ser restaurado a este estado ms tarde. Token Algunas veces es necesario registrar el estado interno de un objeto: mecanismos checkpoints y deshacer cambios que permiten probar operaciones o recuperacin de errores. Mecanismo de transacciones

Aplicabilidad

Una parte del estado de un objeto debe ser guardado para que pueda ser restaurado ms tarde. Una interfaz para obtener el estado de un objeto podra romper la encapsulacin exponiendo detalles de implementacin. Memento:El Memento puede almacenar mucho o parte del estado interno de Creador. Tiene dos interfaces. Una para Conserje, que le permite manipular el Memento nicamente para pasarlo a otros objetos. La otra interfaz sirve para que el Creador pueda almacenar y restaurar su estado interno. Creador: Creador crea un objeto Memento conteniendo una fotografa de su estado interno. Creador usa a Memento para restaurar su estado interno. Conserje:Es responsable por mantener a salvo a Memento. No opera solo examina el contenido de Memento. un Conserje solicita un memento a un creador, lo almacena un tiempo y se lo devuelve a su creador.

Participantes

Colaboraciones Consecuencias

Mantiene la encapsulacin Simplifica la clase Creador ya que no debe preocuparse de mantener las versiones del estado interno. Podra incurrir en un considerable gasto de memoria: encapsular y restaurar el estado no debe ser costoso. Puede ser difcil en algunos lenguajes asegurar que slo el Creador tenga acceso al estado del Memento. Memento tiene dos interfaces, una para los creadores y otra para el resto de clases: clase amiga Implementacin (C++), exportacin selectiva (Eiffel). Un memento puede registrar cambio incremental sobre el estado del creador: cuando se usa el patrn Command para el mecanismo undo/redo. persistir a disco un objeto para realizar alguna validacion externa y luego continuar con ese Uso en el proyecto objeto (ABM) Patrones Command - Iterator Relacionados

AMBITO : OBJETOS

Observer Propsito Conocido como Motivacin Define una dependencia uno-a-muchos entre objetos, de modo que cuando cambia el estado de un objeto, todos sus dependientes automticamente son notificados y actualizados. Dependents - Publish - Subscribe Cmo mantener la consistencia entre objetos relacionados, sin establecer un acoplamiento fuerte entre sus clases? Ejemplo: Separacin Modelo-Vista Cuando un cambio de estado en un objeto requiere cambios en otros objetos, y no sabe sobre cuntos objetos debe aplicarse el cambio. Cuando un objeto debe ser capaz de notificar algo a otros objetos, sin hacer asunciones sobre quines son estos objetos. Sujeto Observador SujetoConcreto ObservadorConcreto leer Permite modificar independientemente subjects y observers. Acoplamiento abstracto y mnimo entre Subject y Observer: puede reutilizarlos por separado observers pueden aadirse sin modificar el subject
Subject no necesita conocer las clases concretas de Observers Soporte para comunicacin de tipo broadcast: el subject no especifica al receptor concreto de la notificacin es posible aadir y eliminar observers en cualquier instante. Actualizaciones inesperadas Interfaz de Observer simple requiere que los observers tengan que deducir el item cambiado

Aplicabilidad

Participantes

Colaboraciones Consecuencias

Implementacin

Es posible que un observer est ligado a ms de un subject: la operacin update tendr como argumento el subject. Quin dispara la notificacin? Mtodos seten la clase Subject Clientes de la clase Subject Asegurarse de notificar siendo el estado de Subject consistente Cunta informacin sobre el cambio se le enva a los observers con la notificacin? Modelo Push(Mucha) y Modelo Pull(Muy Poca)
Al registrar un observer es posible asociarle el evento sobre el que quiere ser notificado attach(Observerobs, Evento interes); Cuando las relaciones de dependencia entre Subject y Observer son complicadas encapsular la semntica de actualizacin en una clase ManejadorCambio(Mediador). En Smalltalk, las interfaces de las clases Subjecty Observer se definen en la clase Object.

Uso en el proyecto MVC Patrones Relacionados Mediator - Singleton

AMBITO : OBJETOS

Propsito Conocido como Motivacin Aplicabilidad

Participantes

State Permite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase. Objects for States Una conexin TCP puede encontrarse en uno de varios estados, y dependiendo del estado responder de un modo diferente a los mensajes de otros objetos para solicitudes tales como abrir, cerrar o establecer conexin. El comportamiento del objeto depende de su estado, y debe cambiar su comportamiento en tiempo de ejecucin dependiendo de su estado. Las operaciones tienen grandes estructuras CASE que dependen del estado del objeto, que es representado por uno o ms constantes de tipo enumerado. Contexto Estado subclases de EstadoConcreto

Colaboraciones Consecuencias Coloca todo el comportamiento asociado a un particular estado en una clase. Subclases vs. Sentencias CASE. Ayuda a evitar estados inconsistentes Transiciones de estado son ms explcitas.
Incrementa el nmero de objetos Los objetos State pueden ser compartidos.

Implementacin

Quin define las transiciones entre estados? Contexto subclases estado. Una alternativa es definir tablas que representan la matriz de transiciones de estado: no es posible asociar acciones a los cambios de estado y ms difcil de comprender. Cundo son creados los objetos estado? Pueden crearse cuando se necesiten o con antelacin y que Context tenga una referencia a ellos.

Uso en el proyecto se puede implementar al verificar el estado de conexin a la BD Patrones Relacionados Flyweight - Singleton

AMBITO : OBJETOS

Propsito Conocido como Motivacin Aplicabilidad

Strategy Define una familia de algoritmos, encapsula cada uno, y permite intercambiarlos. Permite variar los algoritmos de forma independiente a los clientes que los usan Policy Existen muchos algoritmos para justificacin de texto, debe implementarlo el cliente que lo necesita? Configurar una clase con uno de varios comportamientos posibles. Se necesitan diferentes variantes de un algoritmo.
Una clase define muchos comportamientos que aparecen como sentencias CASE en sus mtodos.

Participantes

Estrategia EstrategiaConcreta Contexto

Colaboraciones Consecuencias Define una familia de algoritmos relacionados. Una alternativa a crear subclases de la clase Contexto. Elimina sentencias CASE El cliente puede elegir entre diferentes estrategias o implementaciones: debe conocer detalles
Se incrementa el nmero de objetos: usar Flyweight State y Strategy son similares, cambia el Propsito: ejemplos de composicin con delegacin

Implementacin

Cmo una estrategia concreta accede a los datos del contexto? Pasar datos como argumentos Pasar el contexto como argumento Estrategiaalmacena una referencia al contexto

Uso en el proyecto validaciones independientes de las clases que las implementan (Forms) Patrones Relacionados Flyweight

AMBITO : OBJETOS

Propsito Conocido como Motivacin

Visitor Representa una operacin que debe ser aplicada sobre los elementos de una estructura de objetos. Permite definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera Un compilador que representa los programas como rboles de derivacin de la sintaxis abstracta necesita aplicar diferentes operaciones sobre ellos: comprobacin de tipos, generacin de cdigo, listados cdigo fuente, reestructuracin de programas,... Tenemos una jerarqua de clases que representan objetos de propsito general (p.e. nodos de un rbol de derivacin de sintaxis) y podemos utilizarlo en diferentes aplicaciones, lo que implicara aadir mtodos en las clases de la jerarqua. Una estructura de objetos contiene muchas clases de objetos con diferentes interfaces, y se quiere realizar operaciones sobre los objetos que dependen de las clases concretas.
Las clases definiendo la estructura de objetos cambian con poca frecuencia, pero a menudo se definen nuevas operaciones sobre la estructura. Mejor definir las operaciones en clases aparte.

Aplicabilidad

Participantes

Visitante VisitanteConcreto Elemento ElementoConcreto

EstructuraDeObjetos

Colaboraciones Consecuencias Facilidad para aadir nuevas operaciones: en vez de distribuir la funcionalidad, se aade un nuevo visitor. Un visitor recoge comportamiento relacionado, lo que simplifica las clases de los elementos. Es difcil aadir nuevas subclases de elementos concretos, ya que implica cambiar la jerarqua de Visitor. A diferencia de un iterador, Visitor puede visitar objetos de clases que no tienen una superclase comn.
Compromete la encapsulacin: los elementos concretos deben permitir a los visitorshacer su trabajo.

Implementacin

El patrn permite aadir operaciones a clases sin cambiarlas. Esto se consigue aplicando la tcnica double-dispatch. Quin es responsable del recorrido de la estructura de objetos? Estructura de objetos Un iterador El visitor

Uso en el proyecto Patrones Relacionados

AMBITO : OBJETOS