Patrones de Diseño Resumen

7/23/2019 Patrones de Diseo Resumen

1/64

Emanuel Blasi Resumen de Patrones de Diseo

1 de 64

Resumen de Patrones de Diseo


2/64


2 de 64

Aclaracin ......................................................................................................................3

Patrones de Creacin......................................................................................................4

Patrn Singleton.........................................................................................................5

Patrn Factory Method ..............................................................................................7

Patrn Abstract Factory ...........................................................................................10

Patrn Prototype.......................................................................................................12Patrn Builder ..........................................................................................................14

Conclusin ...............................................................................................................17

Patrones Estructurales..................................................................................................18

Patrn Adapter .........................................................................................................19

Patrn Bridge ...........................................................................................................22

Patrn Composite.....................................................................................................24

Patrn Decorator ......................................................................................................27

Patrn Facade...........................................................................................................31

Patrn Proxy.............................................................................................................34

Conclusin ...............................................................................................................36

Patrones de Comportamiento.......................................................................................38

Patrn Chain of Responsibility ................................................................................39Patrn Command .....................................................................................................41

Patrn Iterator ..........................................................................................................44

Patrn Mediator .......................................................................................................46

Patrn Observer ......................................................................................................49

Patrn State ..............................................................................................................52

Patrn Strategy.........................................................................................................55

Patrn Template Method..........................................................................................57

Patrn Visitor ...........................................................................................................60

Conclusin ...............................................................................................................63

Resumen de Patrones ...................................................................................................64

Patrones de Creacin .....................................................................................................64

Patrones Estructurales....................................................................................................64

Patrones de Comportamiento...........................................................................................64


3/64


3 de 64

Aclaracin

Este apunte es un resumen de ciertos patrones publicados en el libro Patrones de Diseo, deErich Gamma. El mismo debe ser utilizado como gua de lectura rpida una vez que se hayaledo y comprendido el libro, es decir, no se recomienda en absoluto aprender patrones con

el apunte sin haber ledo previamente el libro ya que en l existen muchos ejemplos y casosde uso que ac no figuran.Los patrones que figuran en el apunte no son todos los del libro, sino aquellos que se dieronen la ctedra Arquitectura de Software de la Universidad de Buenos Aires, Facultad deIngeniera, en el primer cuatrimestre del 2005.


4/64


4 de 64

Patrones de Creacin


5/64


5 de 64

Patrn Singleton

Categora de Patrn:Idiom

Categora de Problema:Creacin

Propsito

Garantiza que una sola clase slo tenga una instancia y proporciona un punto de accesoglobal a ella.

Motivacin

Es importante que algunas clases tengan exactamente una instancia. Cmo lo podemosasegurar y que sta sea fcilmente accesible?. Una variable global no previene de crearmltiples instancias de objetos. Una solucin mejor es hacer que sea la propia clase laresponsable de su nica instancia, quien debe garantizar que no se pueda crear ninguna otra

(interceptando las peticiones para crear nuevos objetos) y proporcione un modo de acceder aella.

Aplicabilidad

Usar Singleton cuando:1) Deba haber exactamente una instancia de una clase y sta debe ser accesible a los

clientes desde un punto de acceso conocido.2) La nica instancia debera ser extensible mediante herencia y los clientes deberan ser

capaces de usar una instancia extendida sin modificar su cdigo.

Estructura

Participantes

1) Singleton: Define una operacin Instancia que permite que los clientes accedan a sunica instancia. Instancia es una operacin de clase. Puede ser responsable de crear sunica instancia.

Colaboraciones

Los clientes acceden a la instancia de un Singleton exclusivamente a travs de la operacinInstancia de sta.


6/64


6 de 64

ConsecuenciasVentajas1) Acceso controlado a la nica instancia: Encapsula su nica instancia, puede tener un

control estricto sobre como y cuando acceden a ella los clientes.2) Espacio de nombres reducido: Es una mejora sobre las variables globales. Evita

contaminar el espacio de nombres con variables globales que almacenan las instancias.3) Permite el refinamiento de operaciones y la representacin: Se puede crear una subclase

de la clase Singleton, y es fcil configurar una aplicacin con una instancia de esta claseextendida, incluso en tiempo de ejecucin.

4) Permite un numero variable de instancias: Hace que sea fcil permitir mas de unainstancia de la clase. Solo se necesitara cambiar la operacin que otorga acceso a lainstancia del Singleton.

Implementacin

Class Singleton {public:

static Singleton* Instancia();protected:

Singleton();

Private:Static Singleton* _instancia;

};

La correspondiente implementacin es

Singleton* Singleton:: _instancia = 0;Singleton* Singleton::Instancia () {

if (_instancia == 0) {_instancia = new Singleton;

}return _instancia;}

Los clientes acceden al Singleton exclusivamente a travs de la funcin miembro Instancia.La variable _instancia se inicializa a 0, y la funcin miembro Instancia devuelve su valor,inicializndola con la nica instancia en caso de que sea 0. Instancia usa inicializacinperezosa; el valor que devuelve no se crea y se almacena hasta que se accede a l porprimera vez.Ntese que el constructor se declara como protegido. Un cliente que trate de crear unainstancia de Singleton directamente obtendr un error en tiempo de compilacin. Estogarantiza que solo se puede crear una instancia.

Patrones relacionados

Muchos patrones pueden implementarse usando Singleton: Abstract Factory, Builder,

Prototype, etc.


7/64


7 de 64

Patrn Factory Method

Categora de Patrn:Idiom


Propsito

Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidanque clases instanciar. Permite que una clase delegue en sus subclases la creacin deobjetos (Constructor Virtual).

Aplicabilidad

Usar Factory Method cuando:1) Una clase no pueda prever la clase de objetos que debe crear.2) Una clase quiere que sean sus subclases quienes especifiquen los objetos que esta

crea.

Estructura

Participantes

1) Producto: Define la interfaz de los objetos que crea el mtodo de fabricacin.2) ProductoConcreto: Implementa la interfaz Producto.3) Creador: Declara el mtodo de fabricacin, el cual devuelve un objeto de tipo Producto.

Tambin puede definir una implementacin predeterminada del mtodo de fabricacin

que devuelve un objeto ProductoConcreto. Puede llamar al mtodo de fabricacin paracrear un objeto Producto.

4) CreadorConcreto: Redefine el mtodo de fabricacin para devolver una instancia de unProductoConcreto.

Colaboraciones


8/64


8 de 64

El Creador se apoya en sus subclases para definir el mtodo de fabricacin de manera queste devuelva una instancia del ProductoConcreto apropiado.

ConsecuenciasLos mtodos de fabricacin eliminan la necesidad de ligar clases especficas de la aplicacina nuestro cdigo, quien solo trata con la interfaz Producto.1) Proporciona enganches para las subclases: Crear objetos con un mtodo de fabricacin

es siempre ms flexible que hacerlo directamente, les da a las subclases un punto deenganche para proveer una versin extendida de un objeto (Ventaja).

2) Los clientes heredan de la clase Creador: Un inconveniente potencial es que los clientespueden tener que heredar de la clase Creador simplemente para crear un determinadoobjeto ProductoConcreto.

Implementacin

Mtodos de fabricacin parametrizados: Permite crear varios tipos de productos. Recibe unparmetro que identifica el tipo de objeto a crear. Tiene la siguiente forma general, dondeMiProducto y TuProducto son subclases de Producto:

class Creador {

public:virtual Producto* Crear (idProducto);

};

Producto* Creador::Crear (idproducto id){

if (id == MIO) return new MiProducto;

if (id == TUYO) return new TuProducto;

// repetir para los productos restantes

return 0;

}

Redefiniendo un mtodo de fabricacin parametrizado se pueden extender o cambiarfcilmente y de manera selectiva los productos fabricados por un Creador. Ejemplo: una

subclase de MiCreador.

Producto* MiCreador::Crear (idproducto id){

if (id == TUYO) return new MiProducto;

if (id == MIO) return new TuProducto;

// NOTA: intercambiados TUYO y MIO

if (id == SUYO) return new SuProducto;

// Llamado cuando falla todo lo dems

return Creador::Crear(id);

}

Ntese que lo ultimo que hace esta operacin es llamar al Crear de la clase padre, debido aque MiCreador::Crear slo trata TUYO, MIO y SUYO de forma diferente a la clase padre. Noesta interesada en otras clases, extiende los tipos de productos creados y delega en supadre la responsabilidad de crear todos los productos excepto unos pocos.



9/64


9 de 64

El patrn Abstract Factory suele implementarse con mtodos de fabricacin que tambingeneralmente son llamados desde el interior de Template Method.El patrn Prototype no necesita heredar de Creador. Sin embargo, suelen requerir unaoperacin Inicializar en la clase Producto. El Creador usa Inicializar para inicializar el objeto.


10/64


10 de 64

Patrn Abstract Factory

Categora de Patrn:Diseo


Propsito

Proporciona una interfaz para crear familias de objetos relacionados o que dependen entres, sin especificar sus clases concretas.

Aplicabilidad

Usar Abstract Factory cuando:1) Un sistema debe ser independiente de cmo se crean, componen y representan sus

productos.2) Una familia de objetos producto relacionados est diseada para ser usada

conjuntamente, y es necesario hacer cumplir esta restriccin.3) Quiere proporcionar una biblioteca de clases de productos y solo quiere revelar sus

interfaces, no sus implementaciones.

Estructura

Participantes

1) FabricaAbstracta: Declara una interfaz para operaciones que crean objetos producto

abstractos.2) FabricaConcreta: Implementa las operaciones para crear objetos producto concreto.3) ProductoAbstracto: Declara una interfaz para un tipo de objeto producto.4) ProductoConcreto: Define un objeto producto para que sea creado por la fbrica

correspondiente. Implementa la interfaz ProductoAbstracto.5) Cliente: Slo usa interfaces declaradas por las clases FabricaAbstracta y

ProductoAbstracto.


11/64


11 de 64

Colaboraciones

Normalmente solo se crea una nica instancia de una clase FabricaConcreta en tiempo deejecucin, quien crea objetos producto que tienen una determinada implementacin. Paracrear diferentes objetos producto, los clientes deben usar una fabrica concreta diferente.FabricaAbstracta delega la creacin de objetos producto en su subclase FabricaConcreta.

Consecuencias

1) Asla las clases concretas: Ayuda a controlar las clases de objetos que crea unaaplicacin, encapsula la responsabilidad y el proceso de creacin de objetos producto,asla a los clientes de las clases de implementacin, manipulan las instancias a travs desus interfaces abstractas. Los nombres de las clases producto quedan aisladas en laimplementacin de la fbrica concreta; no aparecen en el cdigo cliente (Ventaja).

2) Facilita el intercambio de familias de productos: La clase de una fbrica concreta soloaparece una vez en una aplicacin, cuando se crea. Esto facilita cambiarla (como creauna familia completa de productos, cambia toda de una vez) (Ventaja).

3) Promueve la consistencia entre productos: Se disean objetos producto en una familiapara trabajar juntos (Ventaja).

4) Es difcil dar cabida a nuevos tipos de productos: Ampliar las fbricas abstractas para

producir nuevos tipos de productos no es fcil ya que la interfaz FabricaAbstracta fija elconjunto de productos que se pueden crear (implica cambiar la clase FabricaAbstracta ytodas sus subclases) (Desventaja).


Las clases FabricaAbstracta suelen implementarse con el patrn Factory Method, perotambin con el patrn Prototype. Una fbrica concreta suele ser un Singleton.


12/64


12 de 64

Patrn Prototype



Propsito

Especifica los tipos de objetos a crear por medio de una instancia prototpica y crea nuevosobjetos copiando dicho prototipo.

Aplicabilidad

Usar Prototype cuando:1) Un sistema deba ser independiente de cmo se crean, componen y representan sus

productos.2) Las clases a instancias sean especificadas en tiempo de ejecucin.3) Se quiera evitar construir una jerarqua de fbricas paralela a la jerarqua de clases de

productos.4) Las instancias de una clase puedan tener uno de entre solo unos pocos estados

diferentes. Puede ser ms adecuado tener un numero equivalente de prototipos yclonarlos, en vez de crear manualmente instancias de la clase cada vez con el estadoapropiado.

Estructura

Participantes

1) Prototipo: Declara una interfaz para clonarse.2) PrototipoConcreto: Implementa una operacin para clonarse.3) Cliente: Crea un nuevo objeto pidindole a un prototipo que se clone.

Colaboraciones


13/64


13 de 64

Un cliente le pide a un prototipo que se clone.

Consecuencias

Parecidas a las de los patrones Abstract Factory y Builder; oculta al cliente las clasesproducto conreta, reduciendo as el numero de nombres que conocen los clientes.

1) Aadir y eliminar productos en tiempo de ejecucin: Permite incorporar a un sistema unanueva clase concreta de producto simplemente registrando una instancia prototpica conel cliente (ms flexible ya que un cliente puede instalar y eliminar prototipos en tiempo deejecucin) (Ventaja).

2) Especificar nuevos objetos modificando valores: Podemos definir nuevos tipos deobjetos creando instancias de clases existentes y registrando esas instancias comoprototipos de los objetos del cliente. Un cliente puede exhibir comportamiento nuevodelegando responsabilidad en su prototipo. Permite que los usuarios definan nuevasclases sin programacin (clonar un prototipo es parecido a crear una instancia de unaclase) (Ventaja).

3) Reduce la herencia: Permite clonar un prototipo en vez de decirle a un Factory Methodque cree un nuevo objeto. (Ventaja).

4) Configurar dinmicamente una aplicacin con clases: Una aplicacin que quiere crearinstancias de una clase cargada dinmicamente no podr hacer referencia al constructor

de esta estticamente. En vez de eso, en tiempo de ejecucin crea automticamente unainstancia de cada clase cada vez que es cargada y la registra con un gestor deprototipos. Despus puede solicitar al gestor de prototipos instancias de nuevas clasesque no fueron enlazadas con el programa originalmente (Ventaja).

5) Implementar Clonar: Cada subclase de Prototipo debe implementar la operacin Clonar,lo cual puede ser difcil en muchos casos (Desventaja).

Implementacin

Cuando el numero de prototipos de un sistema no es fijo (puede crearse y destruirsedinmicamente), se mantiene un registro de los prototipos disponibles. Los clientes nogestionaran ellos mismos los prototipos, sino que los guardaran y recuperaran del registro.Un cliente le pedir al registro, que llamaremos Gestor de Prototipos, un prototipo antes de

clonarlo.Un gestor de prototipos es un almacn asociativo que devuelve el prototipo que concuerdacon una determinada clave. Tiene operaciones para registrar un prototipo y paradesregistrarlo.


Prototype y Abstract Factory son patrones rivales en algunos aspectos, pero tambin puedenusarse juntos. Un Abstract Factory puede almacenar un conjunto de prototipos a partir de loscuales colar y devolver objetos producto.Los patrones Composite y Decorator suelen beneficiarse tambin del Prototype.


14/64


14 de 64

Patrn Builder



Propsito

Separa la construccin de un objeto complejo de su representacin, de forma que el mismoproceso de construccin pueda crear diferentes representaciones.

Aplicabilidad

Usar Builder cuando:1) El algoritmo para crear un objeto complejo debiera ser independiente de las partes de

que se compone dicho objeto y de cmo se ensamblan.2) El proceso de construccin debe permitir diferentes representaciones del objeto que esta

siendo construido.

Estructura

Participantes

1) Constructor: Especifica una interfaz abstracta para crear las partes de un objetoProducto.

2) ConstructorConcreto: Implementa la interfaz Constructor para construir y ensamblar laspartes del producto. Define la representacin a crear. Proporciona una interfaz paradevolver el producto.

3) Director: Construye un objeto usando la interfaz Constructor.4) Producto: Representa el objeto complejo en construccin. El ConstructorConcreto

construye la representacin interna del producto y define el proceso de ensamblaje.Incluye las clases que definen sus partes constituyentes, incluyendo interfaces paraensamblar las partes en el resultado final.

Colaboraciones

1) El cliente crea el objeto Director y lo configura con el constructor deseado.


15/64


15 de 64

2) El Director notifica al constructor cada vez que hay que construir una parte de unproducto.

3) El Constructor maneja las peticiones del director y las aade al producto.4) El cliente obtiene el producto del constructor.

El siguiente diagrama de interaccin ilustra como cooperan con un cliente el Constructor y elDirector:

Consecuencias

1) Permite variar la representacin interna de un producto: El objeto Constructorproporciona al Director una interfaz abstracta para construir el producto que oculte larepresentacin, la estructura interna del producto y el modo en que este es ensamblado.Todo lo que hay que hacer para cambiar la representacin interna del producto es definirun nuevo tipo de constructor (Ventaja).

2) Asla el cdigo de construccin y representacin: Aumenta la modularidad al encapsularcomo se construyen y representan los objetos complejos. Los clientes no necesitan sabernada de las clases que definen la estructura interna del producto; dichas clases noaparecen en la interfaz del Constructor. Cada ConstructorConcreto contiene todo elcdigo para crear y ensamblar un determinado tipo de producto. El cdigo solo seescribe una vez; despus, los diferentes Directores puede reutilizarlo para construirvariantes de Producto a partir del mismo conjunto de partes (Ventaja).

3) Proporciona un control ms fino sobre el proceso de construccin: Construye el productopaso a paso, bajo el control del director, quien solo obtiene el producto del constructoruna vez que este esta terminado. La interfaz Constructor refleja el proceso deconstruccin del producto mas que otros patrones de creacin (Ventaja).

Implementacin

Los constructores construyen sus productos paso a paso, la interfaz de la clase Constructordebe ser lo suficientemente general como para permitir construir productos por parte detodos los tipos de constructores concretos. Modelo de proceso de construccin: Losresultados de las peticiones de construccin simplemente se van aadiendo al producto.


16/64


16 de 64


El patrn Abstract Factory se parece a un Builder en que tambin puede construir objetoscomplejos. La principal diferencia es que el patrn Builder se centra en construir un objetocomplejo paso a paso. El Abstract Factory hace hincapi en familias de objetos producto(simples o complejos). El Builder devuelve el producto como paso final, mientras que elAbstract Factory lo devuelve inmediatamente.

Muchas veces lo que construye el constructor es un Composite.


17/64


17 de 64

Conclusin

Hay dos formas habituales de parametrizar un sistema con las clases de objetos que crea:

1) Heredar de la clase que crea los objetos: Uso del patrn Factory Method. El principal

inconveniente de este enfoque es que puede requerir crear una nueva subcalsesimplemente para cambiar la clase del producto y dichos cambios pueden tener lugaren cascada.

2) Basarse en la composicin de objetos: Consiste en definir un objeto que searesponsable de conocer la clase de objetos producto y hacer que sea un parmetrodel sistema; patrones Abstract Factory, Prototype y Builder. Los tres implican crearun nuevo objeto fbrica cuya responsabilidad es crear objetos producto. El objetofbrica del Abstract Factory produce objetos de varias clases, mientras que en elcaso de Builder construye un producto complejo incrementalmente usando unprotocolo de complejidad similar. El Prototype hace que su objeto fbrica construyaun producto copiando un objeto prototpico (el objeto fbrica y el prototipo son elmismo objeto, ya que el prototipo es el responsable de devolver el producto).

Que patrn es mejor depende de muchos factores.Los diseos que usan los patrones Abstract Factory, Prototype o Builder son todava msflexibles que aquellos que usan el Factory Method, pero tambin son ms complejos. Muchasveces los diseadores empiezan usando el Factory Method y luego evolucionan hacia losotros patrones de creacin a medida que descubren donde es necesaria mas flexibilidad.


18/64


18 de 64

Patrones Estructurales


19/64


19 de 64

Patrn Adapter


Categora de Problema:Adaptacin

Problema

Adaptar para facilitar implementacin.

Propsito

Convierte la interfaz de una clase en otra interfaz que es la que esperan los clientes. Permiteque cooperen clases que de otra forma no podran por tener interfaces incompatibles.

Aplicabilidad

Debera usarse cuando:3) Quiere usar una clase existente y su interfaz no concuerda con la clase que necesita.4) Quiere crear una clase reutilizable que coopere con clases no relacionadas o que no han

sido previstas (que no tienen porque tener interfaces compatibles)5) Solamente en el caso de un adaptador de objetos, cuando es necesario usar varias

subclases existentes, pero no resulta practico adaptar su interfaz heredando de cada unade ellas. Un adaptador de objetos puede adaptar la interfaz de su clase padre.

Estructura

Un adaptador de CLASES usa herencia mltiple para adaptar una interfaz a otra:

Un adaptador de OBJETOS se basa en la composicin de objetos


20/64


20 de 64

Participantes

2) Objetivo: Define la interfaz especifica del dominio que usa el Cliente.3) Cliente: Colabora con objetos que se ajustan a la interfaz Objetivo.4) Adaptable: Define una interfaz existente que necesita ser adaptada.

5) Adaptador: Adapta la interfaz de Adaptable a la interfaz Objetivo.

Colaboraciones

Los clientes llaman a operaciones de una instancia de Adaptador. A su vez, el adaptadorllama a operaciones de Adaptable, que son las que satisfacen la peticin.

Consecuencias

Adaptadores de clases y de objetos, ventajas e inconvenientes:Un adaptador de clases:1) Permita que el Adaptador redefina parte del comportamiento de Adaptable, por ser

Adaptador una subclase de Adaptable. (Ventaja)2) Adapta una clase Adaptable a Objetivo, pero se refiere a una clase Adaptable concreta

(no nos servir cuando queramos adaptar una clase y todas sus subclases). (Desventaja)

Un adaptador de objetos1) Permite que un mismo Adaptador funcione con el Adaptable y todas sus subclases. El

Adaptador tambin puede aadir funcionalidad a todos los adaptables a la vez. (Ventaja)2) Hace que sea ms difcil redefinir el comportamiento de Adaptable. Se necesitar crear

una subclase de Adaptable y hacer que el Adaptador se refiera a la subclase en vez de ala clase Adaptable en s. (Desventaja)

Cuestiones a tener en cuenta

1) Cuanta adaptacin hace el Adaptador: Difieren en la cantidad de trabajo necesaria paraadaptar Adaptable a la interfaz Objetivo (desde la simple conversin de interfaces hastapermitir un conjunto completamente nuevo de operaciones). Esto depende de lo parecidaque sea la interfaz de Objetivo a la de Adaptable.

2) Adaptadores conectables: Una clase es mas reutilizable cuando minimizamos lasasunciones que deben hacer otras clases para usarla.

3) Adaptadores Bidireccionales: Los adaptadores no son transparentes a todos los clientes.Un objeto adaptado ya no se ajusta a la interfaz Adaptable, por lo que no puede usarsetal cual en donde pudiera ir un objeto Adaptable. Los adaptadores bidireccionales puedenproporcionar esa transparencia. Resultan tiles cuando dos clientes distintos necesitanver un objeto de distinta forma.


1) El patrn Bridge tiene una estructura similar a un adaptador de objetos, pero con unpropsito diferente: est pensado para separar una interfaz de su implementacin,de manera que ambos puedan cambiar fcilmente y de forma independiente uno delotro, mientras que un adaptador esta pensado para cambiar la interfaz de un objetoexistente.


21/64


21 de 64

2) El patrn Decorator decora otro objeto sin cambiar su interfaz. Un decorator es portanto mas transparente a la aplicacin que un adaptador. Como resultado, el patrnDecorator permite la composicin recursiva, lo que no es posible con adaptadorespuros.

3) El patrn Proxy define un representante o sustituto de otro objeto sin cambiar suinterfaz.


22/64


22 de 64

Patrn Bridge


Categora de Problema:Variacin de Servicios

Propsito

Desacopla una abstraccin de su implementacin, de modo que ambas puedan variar deforma independiente.

Motivacin

Cuando una abstraccin puede tener varias implementaciones posibles, la forma mshabitual de darles cabida es mediante la herencia. Una clase abstracta define la interfaz de laabstraccin, y las subclases concretas la implementan de distintas formas. Pero este enfoqueno siempre es lo bastante flexible. La herencia liga una implementacin a la abstraccin de

forma permanente, lo que dificulta modificar, extender y reutilizar abstracciones eimplementaciones de forma independiente.

Aplicabilidad

Use el patrn Bridge cuando:1) Quiera evitar un enlace permanente entre una abstraccin y su implementacin (Ej. :

cambiar la implementacin en tiempo de ejecucin).2) Tanto las abstracciones como las implementaciones deberan ser extensibles

mediante subclases (permite combinar las diferentes abstracciones y susimplementaciones, extendindolas independientemente).

3) Quiera compartir una implementacin entre varios objetos (tal vez usando uncontador de referencias) y este hecho deba permanecer oculto al cliente.

Estructura

Participantes

1) Abstraccin: Define la interfaz de la abstraccin. Mantiene una referencia a unobjeto de tipo Implementador.

2) AbstraccionRefinada:Extiende la interfaz definida por Abstraccin.


23/64


23 de 64

3) Implementador:Define la interfaz de las clases de implementacin que no tiene porqu corresponderse exactamente con la de Abstraccin; de hecho pueden ser muydistintas. Normalmente la interfaz Implementador solo proporciona operacionesprimitivas y Abstraccin define operaciones de mas alto nivel basadas en dichasprimitivas.

Colaboraciones

Abstraccin redirige las peticiones del cliente a su objeto Implementador.

Consecuencias

1) Desacopla la interfaz y la implementacin: No une permanentemente unaimplementacin a una interfaz, sino que la implementacin puede configurarse y cambiaren tiempo de ejecucin. Desacoplar Abstraccin e Implementador tambin elimina de laimplementacin dependencias de tiempo de compilacin. Cambiar una clase ya norequiere recompilar la clase Abstraccin y sus clientes (Ventaja)

2) Mejora la extensibilidad: Podemos extender las jerarquas de Abstraccin y de

Implementador de forma independiente (Ventaja).3) Oculta detalles de implementacin a los clientes: Podemos aislar a los clientes de losdetalles de implementacin, como el comportamiento de objetos implementadotes(Ventaja).


1) El patrn Abstract Factory puede crear y configurar un Bridge.2) El patrn Adapter esta orientado a conseguir que trabajen juntas clases que no estn

relacionadas. El patrn Bridge, por otro lado, se usa al comenzar un diseo para permitirque abstracciones e implementaciones varen independientemente unas de otras.


24/64


24 de 64

Patrn Composite


Categora de Problema:Descomposicin Estructural

Propsito

Que el cliente vea a las partes y al todo como una misma cosa. Compone objetos enestructuras de rbol para representar jerarquas de parte-todo. Permite que los clientes tratende manera uniforme a los objetos individuales y a los compuestos.

Contexto

Donde necesitamos componer objetos que representan una jerarqua como suma de partes

Aplicabilidad

Use el patrn Composite cuando:1) Quiera representar jerarquas de objetos parte-todo.2) Quiera que los clientes sean capaces de obviar las diferencias entre composiciones

de objetos y los objetos individuales. Los clientes tratarn a todos los objetos de laestructura compuesta de manera uniforme.

Estructura

Una estructura de objetos compuestos tpica puede parecerse a:


25/64


25 de 64

Participantes

1) Componente: Declara la interfaz de los objetos de la composicin. Implementa elcomportamiento predeterminado de la interfaz que es comn a todas las clases.Declara una interfaz para acceder a sus componentes hijos y gestionarlos.Opcionalmente, define una interfaz para acceder al padre de un componente en laestructura recursiva y, si es necesario, la implementa.

2) Hoja:Representa objetos hoja en la composicin. Una hoja no tiene hijos. Define elcomportamiento de los objetos primitivos de la composicin.

3) Compuesto: Define el comportamiento de los componentes que tienen hijos.Almacena componentes hijos. Implementa las operaciones de la interfazComponente relacionadas con los hijos.

4) Cliente: Manipula objetos en la composicin a travs de la interfaz Componente.

Colaboraciones

Los Clientes usan la interfaz de la clase Componente para interactuar con los objetos de laestructura compuesta. Si el recipiente es una Hoja, la peticin se trata correctamente. Si esun Compuesto, normalmente redirige las peticiones a sus componentes hijos, posiblementerealizando operaciones adicionales antes o despus.

Consecuencias

1) Define jerarquas de clases formadas por objetos primitivos y compuestos: Losobjetos primitivos pueden componerse en otros objetos mas complejos, que a su vezpueden ser compuestos, y as de manera recurrente. All donde el cdigo espere unobjeto primitivo, tambin podr recibir un objeto compuesto (Ventaja)

2) Simplifica el cdigo del cliente: Los clientes pueden tratar uniformemente lasestructuras compuestas y a los objetos individuales. Normalmente no conocen siestn usando una hoja o un componente compuesto. Esto simplifica el cliente, evitatener que escribir funciones con instrucciones if anidadas en las clases que definenla composicin (Ventaja).

3) Facilita aadir nuevos tipos de componentes: Si se definen nuevas subclasesCompuesto u Hoja, funcionarn automticamente con las estructuras y el cdigo

cliente existentes. No hay que cambiar los clientes para nuevas clases Componente(Ventaja).

4) Puede hacer que un diseo sea demasiado general: Hace difcil restringir loscomponentes de un compuesto. A veces queremos que un compuesto solo tengaciertos componentes. No podemos confiar en el sistema de tipos para que hagacumplir estas restricciones por nosotros, tendremos que usar comprobaciones entiempo de ejecucin.


26/64


26 de 64


1) Muchas veces se usa el enlace al componente para implementar el patrn Chainof Responsability.

2) El patrn Decorator suele usarse junto con el Composite. Normalmente ambostendrn una clase padre comn. Por tanto, los decoradores tendrn que admitirla interfaz Componente con operaciones como Aadir, Eliminar y ObtenerHijo.

3) El patrn Flyweight permite compartir componentes, si bien en ese caso estos yano pueden referirse a sus padres.

4) Se puede usar el patrn Iterator para recorrer las estructuras definidas por elpatrn Composite.

5) El patrn Visitor, localiza operaciones y comportamiento que de otro modoestara distribuido en varias clases Compuesto y Hoja.


27/64


27 de 64

Patrn Decorator


Categora de Problema:Extensin de servicios

Propsito

Asigna responsabilidades adicionales a un objeto dinmicamente, proporcionando unaalternativa flexible a la herencia para extender la funcionalidad.

Motivacin

A veces queremos aadir responsabilidades a objetos individuales en vez de a toda unaclase.Un modo de hacerlo es a travs de la herencia, pero esto es inflexible ya que se haceestticamente, un cliente no puede controlar cmo ni cundo decorar el componente.

Un enfoque ms flexible es encerrar el componente en otro objeto, el decorador, que seajusta a la interfaz del componente que decora de manera que su presencia es transparentea sus clientes (el decorador reenva las peticiones al componente, pudiendo realizar accionesadicionales antes o despus del reenvo). Dicha transparencia permite anidar decoradoresrecursivamente, permitiendo as un numero ilimitado de responsabilidades aadidas.

Aplicabilidad

Usar Decorator:1) Para aadir objetos individuales de forma dinmica y transparente, sin afectar a otros

objetos.2) Para responsabilidades que pueden ser retiradas.

3) Cuando la extensin mediante la herencia no es posible.

Estructura


28/64


28 de 64

Participantes

1) Componente: Define la interfaz para los objetos a los que se pueden aadirresponsabilidades dinmicamente.

2) ComponenteConcreto: Define un objeto al que se pueden aadir responsabilidadesadicionales.

3) Decorador: Mantiene una referencia a un objeto Componente y define una interfaz

que se ajusta a la interfaz del Componente.4) DecoradorConcreto: Aade responsabilidades al componente

Consecuencias

1) Mas flexibilidad que la herencia esttica: La herencia requiere crear una nueva clasepara cada responsabilidad adicional que se quiere agregar, dando lugar a muchasclases diferentes, incrementando la complejidad de un sistema. Por el contrario, conel patrn Decorador se puede aadir y quitar responsabilidades en tiempo deejecucin simplemente ponindolas y quitndolas. Proporcionar diferentes clasesDecorador para una determinada clase componente permite mezclar

responsabilidades (Ventaja).2) Evita clases cargadas de funciones en la parte de arriba de la jerarqua:En vez detratar de permitir todas las funcionalidades inimaginables en una clase compleja yadaptable, podemos definir primero una clase simple y aadir luego funcionalidadincrementalmente con objetos Decorador. La funcionalidad puede obtenersecomponiendo partes simples ( una aplicacin no necesita pagar por caractersticasque no usa) (Ventaja).

3) Un decorador y su componente no son idnticos:Un decorador se comporta comoun revestimiento transparente, pero desde el punto de vista de la identidad de unobjeto, un componente decorado no es idntico al componente en s. No deberamosapoyarnos en la identidad de objetos (casteo?) cuando estamos usando decoradores(Desventaja)

4) Muchos objetos pequeos:Un diseo que usa el patrn Decorador suele dar comoresultado sistemas formados por muchos objetos pequeos muy parecidos que son

fciles de adaptar por quienes los comprenden bien, pero pueden ser difciles deaprender y depurar (Desventaja).

Implementacin

Tener en cuenta estas 3 cuestiones1) Concordancia de interfaces: La interfaz de un objeto decorador debe ajustarse a la

interfaz del componente que decora (las clases DecoradorConcreto deben por lotanto heredar de una clase comn.

2) Omisin de la clase abstracta Decorador: No hay necesidad de definir una claseabstracta Decorador cuando solo necesitamos aadir una responsabilidad.

3) Mantener ligereas las clases Componente:Para garantizar una interfaz compatible,los componentes y los decoradores deben descender de una clase Componente

comn, quien debera centrarse en definir una interfaz, no en guardar datos. Ladefinicin de cmo se representan los datos debera delegarse en las subclases; deno ser as, la complejidad de la clase Componente puede hacer que los decoradoressean demasiados pesados como para usar un gran numero de ellos. Poner muchafuncionalidad en el Componente tambin incrementa la probabilidad de que lassubclases concretas estn pagando por caractersticas que no necesitan.


29/64


29 de 64

Similitudes con el patrn Strategy

Se dice que el patrn Decorator le cambia la PIEL a un objeto ya que se lo puede pensarcomo un revestimiento de un objeto que cambia su comportamiento.En cambio se dice que el Strategy le cambia las TRIPASa un objeto, ya que cambia lasinterioridades del mismo.El patrn Strategy (quien delega parte de la funcionalidad del Componente en un objeto

Estrategia aparte, permitiendo alterar o extender la funcionalidad del Componente cambiandoel objeto Estrategia), es una mejor eleccin en los casos en que la clase Componente seamuy pesada, lo que hace que el patrn Decorator sea demasiado costoso de aplicar.Puesto que el patrn Decorator solo cambia la parte exterior de un objeto, el Componente notiene que saber nada de sus decoradores (son transparentes).

Con estrategias, el Componente conoce sus posibles extensiones, por lo tanto tiene quereferenciar y mantener las estrategias correspondientes.

El enfoque basado en estrategias puede requerir modificar el componente para permitirnuevas extensiones. Por otro lado, una estrategia puede tener su propia interfaz

especializada, mientras que la interfaz de un decorador debe ajustarse a la del componente.

Cdigo de Ejemplo

Suponemos que hay una clase Componente llamada ComponenteVisual:

class ComponenteVisual {

public:

ComponenteVisual();

virtual void Dibujar();

virtual void CambiarTamao();

// ...

};

Una subclase de ComponenteVisual llamada Decorador, de la cual heredaremos paraobtener diferentes decoraciones:

class Decorador : public ComponenteVisual {

public:

Decorador (ComponenteVisual *);



30/64


30 de 64

virtual void CambiarTamao();

// ...

private:

ComponenteVisual * _componente;

};

void Decorador :: Dibujar () {

_componente -> Dibujar();

}

void Decorador :: CambiarTamao () {

_componente -> CambiarTamao ();

}

Las subclases de Decorator definen decoraciones concretas (ej: DecoradorBorde aade unborde a su componente):

class DecoradorBorde : public Decorator {

public:

DecoradorBorde (ComponenteVisual*, int anchoBorde);


private:

void DibujarBorde(int);

private:

int _ancho;};

void DecoradorBorde :: Dibujar () {

Decorador::Dibujar();

DibujarBorde(_ancho);

}


1) Adapter:Un decorador se diferencia de un adaptador en que el decorador solo cambialas responsabilidades de un objeto, no su interfaz, mientras que el adaptador le da a unobjeto una interfaz completamente nueva.

2) Composite:Podemos ver a un decorador como un compuesto degenerado que solo tieneun componente. No obstante, un decorador aade responsabilidades adicionales (noesta pensado para la agregacin de objetos).

3) Strategy: Permite cambiar el servicio, las tripas de un objeto. El decorador permitecambiar el exterior, la piel, extendiendo su funcionalidad. Son 2 formas alternativas demodificar un objeto.


31/64


31 de 64

Patrn Facade


Categora de Problema:Control de acceso

Propsito

Proporcionar una interfaz unificada para un conjunto de interfaces de un subsistema. Defineuna interfaz de alto nivel que hace que el subsistema sea ms fcil de usar.

Problema

Ordenar acceso a recursos (se empez a usar cuando gran parte del cdigo C fuereemplazado por C++, Ej. : MFC, API que ordenan el acceso a recursos vinculados con elsistema operativo. No agregan funcionalidad, son un punto de entrada, de control, delegan.Parecido a Mediator, solo que en este el conocimiento era de ida y vuelta ya que conoce alas clases y estas lo conocen a l. En cambio en el Facade las clases del subsistema no

conocen a este.

Motivacin

Estructurar un sistema en subsistemas ayuda a reducir la complejidad. Un tpico objetivo dediseo es minimizar la comunicacin y dependencias entre subsistemas. Un modo de lograresto es introduciendo un objeto fachada que proporcione una interfaz nica y simplificadapara los servicios ms generales del subsistema.

Aplicabilidad

Use el patrn Facade cuando:1) Quiera proporcionar una interfaz simple para un subsistema complejo. Los

subsistemas suelen volverse mas complicados a medida que van evolucionando.Una fachada puede proporcionar una vista simple del subsistema que resultaadecuada para la mayora de los clientes y solo aquellos clientes que necesitan maspersonalizacin necesitarn ir mas all de la fachada.

2) Haya muchas dependencias entre los clientes y las clases que implementan unaabstraccin. Se introduce una fachada para desacoplar el subsistema de sus clientesy de otros subsistemas, promoviendo as la independencia entre subsistemas yportabilidad.

3) Queramos dividir en capas nuestros subsistemas. Se usa una fachada para definirun punto de entrada en cada nivel del subsistema. Si estos son dependientes, sepueden simplificar las dependencias para entre ellos haciendo que se comuniquenentre s nicamente a travs de sus fachadas.

Estructura


32/64


32 de 64

Participantes

1) Fachada: Sabe que clases del subsistema son las responsables ante una peticin.Delega las peticiones de los clientes en los objetos apropiados del subsistema.

2) Clases del subsistema: Implementan la funcionalidad del subsistema. Realizan laslabores encomendadas por el objeto Facade. No conocen a la fachada, es decir, notienen referencias a ella.

Colaboraciones

Los clientes se comunican con el subsistema enviando peticiones al objeto Fachada, el cuallas reenva a los objetos apropiados del subsistema. Aunque son los objetos del subsistemalos que realizan el trabajo real, la fachada puede tener que hacer algo de trabajo para pasarde su interfaz a la del subsistema.Los clientes que usan la fachada no tienen que acceder directamente a los objetos delsubsistema (pero podran hacerlo si lo desean, si quieren una mayor personalizacin).

Consecuencias

Ventajas1) Oculta a los clientes los componentes del subsistema, reduciendo as el nmero

de objetos con los que tratan los clientes y haciendo que el subsistema sea msfcil de usar.

2) Promueve un dbil acoplamiento entre el subsistema y sus clientes (nos permitemodificar los componentes de un subsistema sin que sus clientes se veanafectados). Las fachadas ayudan a estructurar en capas un sistema y lasdependencias entre los objetos. Pueden eliminar dependencias complejas ocirculares (consecuencia importante cuando el cliente y el subsistema seimplementan por separado).

Implementacin

Reduccin del acoplamiento cliente-subsistema: El acoplamiento entre clientes y elsubsistema puede verse reducido todava mas haciendo que Facade sea una clase abstractacon subclases concretas para las diferentes implementaciones de un subsistema. De esamanera los clientes pueden comunicarse con el subsistema a travs de la interfaz de una


33/64


33 de 64

clase abstracta Facade. Este acoplamiento abstracto evita que los clientes tengan que saberque implementacin de un subsistema estn usando.Una alternativa a la herencia es configurar un objeto Facade con diferentes objetos delsubsistema. Para personalizar la fachada basta con reemplazar uno o varios de tales objetos.


1) El patrn Abstract Factory puede usarse para proporcionar una interfaz para crear elsubsistema de objetos de forma independiente a otros subsistemas. Tambin puedeser una alternativa a las fachadas para ocultar clases especficas de la plataforma.

2) El patrn Mediator es parecido al Facade en el sentido de que abstrae funcionalidada partir de unas clases existentes. Sin embargo, el propsito del Mediatos esabstraer cualquier comunicacin entre objetos similares, a menudo centralizando lafuncionalidad que no pertenece a ninguno de ellos. Los colegas de un mediator solose preocupan de comunicarse con el y no entre ellos directamente. Por el contrario,una fachada simplemente abstrae una interfaz para los objetos del subsistema,hacindolos ms fcil de usar; no define nueva funcionalidad y las clases delsubsistema no saben de su existencia.

3) Normalmente solo necesita un objeto Facade, por lo que suelen implementarse comoSingletons.


34/64


34 de 64

Patrn Proxy


Categora de Problema:Control de acceso

Propsito

Proporciona un representante o sustituto de otro objeto para controlar el acceso a este.

Motivacin

Una razn para controlar el acceso a un objeto es retrasar todo el coste de su creacin einicializacin hasta que sea realmente necesario usarlo.

Aplicabilidad

Este patrn es aplicable cada vez que hay necesidad de una referencia a un objeto massofisticada que un simple puntero:

1) Proxy Remoto: Proporciona un representante local de un objeto situado en otroespacio de direcciones.

2) Proxy Virtual: Crea objetos costosos por encargo (es decir, solo cuando se van ausar, no al principio de la aplicacin).

3) Proxy de Proteccin: Controla el acceso al objeto original. Son tiles cuando losobjetos debieran tener diferentes permisos de acceso.

4) Referencia Inteligente: Es un sustituto de un simple puntero que lleva a cabooperaciones adicionales cuando se accede a un objeto, Ej:a) Contar el numero de referencias al objeto real.b) Cargar un objeto persistente cuando es referenciado por primera vez.c) Comprobar que se bloquea el objeto real antes de acceder a l para garantizar

que no pueda ser modificado por ningn otro objeto.

Estructura

Este es un posible diagrama de objetos de una estructura de proxies en tiempo de ejecucin.

Participantes


35/64


35 de 64

1) Proxy:Mantiene una referencia que le permite acceder al objeto real. Proporcionauna interfaz idntica a la del Sujeto, de manera que pueda ser sustituido por elSujetoReal. Controla el acceso al SujetoReal y puede ser responsable de sucreacin y borrado. Otras responsabilidades dependen del tipo de proxy:a) Los Proxies Remotos son responsables de codificar una peticin y sus

argumentos para enviar al SujetoReal que se encuentra en un espacio dedirecciones diferente.

b) Los Proxies Virtuales pueden guardar informacin adicional sobre elSujetoReal, por lo que pueden retardar el acceso al mismo.c) Los Proxies de Proteccincomprueban que el llamador tenga los permisos de

acceso necesarios para realizar una peticin.2) Sujeto:Define la interfaz comn para el SujetoReal y el Proxy, de modo que pueda

usarse un Proxy en cualquier sitio en el que se espere un SujetoReal.3) SujetoReal: Define el objeto real representado.

Colaboraciones

El Proxy redirige peticiones al SujetoReal cuando sea necesario, dependiendo del tipo deProxy.

Consecuencias

El patrn Proxy introduce un nivel de indireccin al acceder a un objeto que tiene muchosusos y ventajas dependiendo del tipo de Proxy:

1) Un Proxy Remoto puede ocultar el hecho de que un objeto reside en un espacio dedirecciones diferente.

2) Un Proxy Virtual puede llevar a cabo optimizaciones tales como crear un objeto porencargo.

3) Tanto los Proxies de Proteccin como las Referencias Inteligentes permiten realizartareas de mantenimiento adicionales cuando se accede a un objeto.

Los proxies no siempre tienen que conocer el tipo de SujetoReal. Si una clase Proxy puedetratar con su Sujeto slo a travs de una interfaz abstracta, entonces no hay necesidad dehacer una clase Proxy para cada clase de SujetoReal (el Proxy puede tratar de manerauniforme a todas las clases SujetoReal). Pero si los objetos Proxy van a crear instancias deSujetoReal (como los proxies virtuales) entonces tienen que conocer la clase concreta.


1) El patrn Adapter proporciona una interfaz diferente para el objeto que adapta. Por elcontrario, un Proxy tiene la misma interfaz que su sujeto. No obstante, un Proxyutilizado para proteccin de acceso podra rechazar una operacin que el sujeto sirealiza, de modo que su interfaz puede ser realmente un subconjunto de la delsujeto.

2) El patrn Decorator, si bien puede tener una implementacin parecida a los proxies,

tienen un propsito diferente. Un Decorator aade una o ms responsabilidades a unobjeto, mientras que un proxy controla el acceso a un objeto.


36/64


36 de 64

Conclusin

Existen similitudes entre los patrones estructurales, especialmente en sus participantes ycolaboradores. Esto es debido a que se basan en un mismo pequeo conjunto demecanismos del lenguaje para estructurar el cdigo y los objetos: herencia simple y herencia

mltiple para los patrones basados en clases, y composicin de objetos para los patrones deobjetos. Pero estas similitudes ocultan los diferentes propsitos de estos patrones.

Adapter vs. Bridge

Los patrones Adapter y Bridge tienen algunos atributos comunes. Ambos promueven laflexibilidad al proporcionar un nivel de indireccin a otro objeto. Ambos implican reenviarpeticiones a este objeto desde una interfaz distinta de la suya propia.La diferencia fundamental entre estos patrones radica en su propsito. Adapter se centra enresolver incompatibilidades entre dos interfaces existentes. No presta atencin a como seimplementan dichas interfaces, ni tiene en cuenta como podran evolucionar de formaindependiente. Es un modo de lograr que dos clases diseadas independientemente trabajenjuntas sin tener que volver a implementar una u otra. Por otro lado, Bridge une una

implementacin con sus implementaciones (que pueden ser numerosas). Proporciona unainterfaz estable a los clientes permitiendo, no obstante, que cambien las clases que laimplementan. Tambin permite incorporar nuevas implementaciones a medida queevoluciona el sistema.Como resultado de estas diferencias, los patrones Adapter y Bridge suelen usarse endiferentes puntos del ciclo de vida del software. Un adaptador suele hacerse necesariocuando se descubre que deberan trabajar juntas dos clases incompatibles, generalmentepara evitar duplicar cdigo, y este acoplamiento no haba sido previsto. Por el contrario, elusuario de un puente sabe de antemano que una abstraccin debe tener variasimplementaciones y que unas y otras pueden variar independientemente. El patrn Adapterhace que las cosas funcionen despus de que han sido diseadas; el Bridge lo hace antes.Cada uno resuelve un problema distinto.Podemos ver un Facade como un adaptador para un conjunto de objetos. Pero estaimplementacin obvia el hecho de que una fachada define una nueva interfaz, mientras que

un adaptador reutiliza una interfaz existente (hace que trabajen juntas dos interfacesexistentes en vez de tener que definir una completamente nueva).

Composite vs. Decorator vs. Proxy

Los patrones Composite y Decorator tienen diagramas de estructura parecidos, ambos sebasan en la composicin recursiva para organizar un numero indeterminado de objetos, perose usan para propsitos diferentes.El patrn Decorator esta diseado para permitir responsabilidades a objetos sin crearsubclases, evita la explosin de subclases a la que puede dar lugar al intentar cubrir cadacombinacin de responsabilidades estticamente. El patrn Composite tiene un propsitodiferente, consiste en estructurar subclases para que se puedan tratar de manera uniformemuchos objetos relacionados y que mltiples objetos puedan ser tratados como uno solo, esdecir, no se centra en la decoracin sino en la representacin.Estos propsitos son distintos pero complementarios, por lo tanto, suelen usarseconjuntamente.Otro patrn con una estructura similar al Decorator es el Proxy. Ambos describen comoproporcionar un nivel de indireccin a un objeto y las implementaciones mantienen unareferencia a otro objeto, al cual reenvan las peticiones. Pero estn pensados para propsitosdiferentes.


37/64


37 de 64

Al igual que el Decorator, el patrn Proxy compone un objeto y proporciona una interfazidntica a los clientes. A diferencia del Decorator, el patrn Proxy no tiene que ver conasignar o quitar propiedades dinmicamente y tampoco esta diseado para la composicinrecursiva. Su propsito es proporcionar un sustituto para un sujeto cuando no es convenienteo deseable acceder directamente a l, debido a, por ejemplo, residir en una mquina remota,tener acceso restringido o ser persistente.En el patrn Proxy, el sujeto define la principal funcionalidad y el proxy proporciona (o

rechaza) el acceso al mismo. En el Decorator, el componente proporciona solo parte defuncionalidad y uno o ms decoradores hacen el resto. El patrn Decorator se encarga deaquellas situaciones en las que no se puede determinar toda la funcionalidad de un objeto entiempo de compilacin, o al menos no resulta conveniente hacerlo. Ese no es el caso delProxy, ya que este se centra en una relacin (entre el proxy y su sujeto) que puedeexpresarse estticamente. Pero esto no significa que estos patrones no puedan combinarse.


38/64


38 de 64

Patrones de Comportamiento


39/64


39 de 64

Patrn Chain of Responsibility


Categora de Problema:Organizacin del trabajo

Propsito

Evita acoplar el emisor de una peticin a su receptor, dando a mas de un objeto la posibilidadde responder a la peticin. Encadena los objetos receptores y pasa la peticin a travs de lacadena hasta que es procesada por algn objeto.

Motivacin

La idea de este patrn es desacoplar a los emisores y a los receptores dndole a variosobjetos la posibilidad de tratar una peticin, que se pasa a travs de una cadena de objetoshasta que es procesada por alguno de ellos.

Para reenviar la peticin a lo largo de la cadena, garantizando que los receptorespermanezcan implcitos, cada objeto de la cadena comparte una interfaz comn paraprocesar peticiones y para acceder a su sucesor en la cadena.

Aplicabilidad

Usar Chain of Responsability cuando:6) Hay mas de un objeto que puede manejar una peticin y el manejador no se conoce a

priori, sino que debera determinarse automticamente.7) Se quiere enviar una peticin a un objeto entre varios sin especificar explcitamente el

receptor.8) El conjunto de objetos que pueden tratar una peticin debera ser especificado

dinmicamente.

Estructura

Una estructura de objetos tpica podra parecerse a sta:

Participantes


40/64


40 de 64

6) Manejador: Define una interfaz para tratar las peticiones. Opcionalmente, implementa elenlace al sucesor.

7) ManejadorConcreto: Trata las peticiones de las que es responsable. Puede acceder asu sucesor. Si el ManejadorConcreto puede manejar la peticin, lo hace; en casocontrario la reenva a su sucesor.

8) Cliente: Inicializa la peticin a un objeto ManejadorConcreto de la cadena.

Colaboraciones

Cuando un cliente enva una peticin, sta se propaga a travs de la cadena hasta que unobjeto ManejadorConcreto se hace responsable de procesarla.

Consecuencias

4) Reduce el acoplamiento:Libera a un objeto de tener que saber que otro objeto manejauna peticin. Ni el emisor ni el receptor se conocen y tampoco tienen que conocer laestructura de la cadena. Simplifica las interconexiones entre objetos. En vez de que losobjetos mantengan referencias a todos los posibles receptores, solo tienen una nicareferencia a su sucesor (Ventaja).

5) Aade flexibilidad para asignar responsabilidades a objetos:Se pueden aadir o cambiarresponsabilidades para tratar una peticin modificando la cadena en tiempo de ejecucin(Ventaja).

6) No se garantiza la recepcin:Dado que las peticiones no tienen un receptor explcito, nohay garanta de que sean manejadas (la peticin puede alcanzar el final de la cadena sinhaber sido procesada). Una peticin tambin puede quedar sin tratar cuando la cadenano est configurada correctamente (Desventaja).


3) Este patrn se suele aplicar conjuntamente con el patrn Composite, en el que lospadres de los componentes pueden actuar como sucesores.


41/64


41 de 64

Patrn Command



Propsito

Encapsula una peticin en un objeto, permitiendo as parametrizar a los clientes condiferentes peticiones, hacer cola o llevar un registro de las peticiones y poder deshacer lasoperaciones.

Contexto

Quiero ver como se comunican las instancias de un conjunto de clases

ProblemaDesacoplar las instancias de los objetos que hacen request de los que prestan el servicio(response)

Motivacin

A veces es necesario enviar peticiones a objetos sin saber nada acerca de la operacinsolicitada o de quien es el receptor de la peticin.

Aplicabilidad

Usar Command cuando se quiera:

1) Parametrizar objetos con una accin a realizar. En un lenguaje procedural se puedeexpresar dicha parametrizacin con una funcin callback (registrada en algn sitiopara que sea llamada mas tarde). Los objetos Orden son un sustituto orientado aobjetos para las funciones callback.

2) Especificar, poner en cola y ejecutar peticiones en diferentes instantes de tiempo. Unobjeto Orden puede tener un tiempo de vida independiente de la peticin original.

3) Permitir deshacer. La operacin Ejecutar de Orden puede guardar un estado y laoperacin en una lista historial. Debe aadirse una operacin Deshacer que anulelos efectos de una llamada anterior a Ejecutar. Se pueden lograr niveles ilimitadosrecorriendo el historial, llamando respectivamente a Deshacer y Ejecutar.

4) Permitir registrar los cambios de manera que se puedan volver a aplicar en caso deuna cada del sistema. Aumentando la interfaz de Orden con operaciones paracargar y guardar se puede mantener un registro persistente de los cambios.

5) Ofrecer un modo de modelar transacciones (encapsular un conjunto de cambios

sobre unos datos). Las rdenes tienen una interfaz comn, permitiendo as invocar atodas las transacciones del mismo modo.

Estructura


42/64


42 de 64

Participantes

1) Orden: Declara una interfaz para ejecutar una operacin.2) OrdenConcreta: Define un enlace entre un objeto Receptor y una accin.

Implementa Ejecutar invocando la correspondiente operacin u operaciones delReceptor.

3) Cliente: Crea un objeto OrdenConcreta y establece su receptor.

4) Invocador: Le pide a la orden que ejecute la peticin.5) Receptor: Sabe como llevar a cabo las operaciones asociadas a una peticin.

Cualquier clase puede actuar como Receptor.

Colaboraciones

1) El cliente crea un objeto OrdenConcreta y especifica su receptor.2) Un objeto Invocador almacena el objeto OrdenConcreta.3) El Invocador enva una peticin llamando a Ejecutar sobre la orden. Cuando las ordenes

se pueden deshacer, OrdenConcreta guarda el estado para deshacer la orden antes dellamar a Ejecutar.

4) El objeto OrdenConcreta invoca operaciones de su receptor para llevar a cabo lapeticin.

El siguiente diagrama muestra las interacciones entre los objetos.


43/64


43 de 64

Consecuencias

Ventajas1) Orden desacopla el objeto que invoca la operacin de aquel que sabe como

realizarla.2) Las ordenes son objetos de primera clase, pueden ser manipulados y extendidos.3) Se pueden ensamblar ordenes en una orden compuesta (generalmente se usa el

patrn Composite).4) Es fcil aadir nuevas ordenes ya que no hay que cambiar las clases existentes.


1) El patrn Composite se puede usar para ordenes compuestas.2) El patrn Memento puede mantener el estado que necesitan las ordenes para

anular sus efectos.3) El patrn Prototype puede usarse si una orden debe ser copiada antes de ser

guardada en el historial.


44/64


44 de 64

Patrn Iterator


Categora de Problema:Control de Acceso

Propsito

Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregadosin exponer su representacin interna (una especie de cursor).

Motivacin

Un objeto lista debera darnos una forma de acceder a sus elementos sin exponer suestructura interna, queremos recorrerla de diferentes formas, pero no plagarla conoperaciones para diferentes recorridos. Por otro lado, tambin puede necesitarse hacer masde un recorrido simultneamente sobre la lista.El patrn Iterator nos permite hacer todo esto. La idea clave es tomar la responsabilidad de

acceder y recorrer el objeto lista y poner dicha responsabilidad en un objeto Iterador quedefine una interfaz para acceder a los elementos de la lista y es responsable de saber cuales el elemento actual; es decir, sabe que elementos ya han sido recorridos.

Aplicabilidad

Usar Iterator:1) Para acceder al contenido de un objeto agregado sin exponer su representacin

interna.2) Para permitir varios recorridos sobre objetos agregados.3) Para proporcionar una interfaz uniforme para recorrer diferentes estructuras

agregadas (es decir, para permitir la iteracin polimrfica).

Estructura

Participantes

1) Iterador: Define una interfaz para recorrer los elementos y acceder a ellos.


45/64


45 de 64

2) IteradorConcreto: Implementa la interfaz de Iterador. Mantiene la posicin actual enel recorrido del agregado.

3) Agregado: Define una interfaz para crear un objeto Iterador.4) AgregadoConcreto: Implementa la interfaz de creacin de Iterador para devolver

una instancia del IteratorConcreto apropiado.

Colaboraciones

Un IteratorConcreto sabe cual es el objeto actual del agregado y puede calcular el objetosiguiente en el recorrido.

ConsecuenciasVentajas5) Permite variaciones en el recorrido de un agregado: Los agregados complejos pueden

recorrerse de muchas formas (ej.: recorrer rboles en en-orden o pre-orden). Lositeradores facilitan cambiar el algoritmo de recorrido, basta con sustituir la instancia deiterador por otra diferente. Tambin se pueden definir subclases de Iterador para permitirnuevos recorridos.

6) Los iteradores simplifican la interfaz Agregado: La interfaz de recorrido de Iterador

elimina la necesidad de una interfaz parecida en Agregado, simplificando as la interfazdel agregado.7) Se puede hacer mas de un recorrido a la vez sobre un agregado: Un iterador mantiene

su propio estado del recorrido. Por tanto es posible estar realzando mas de un recorridoal mismo tiempo.


a. El patrn Composite suele usar iteradores para las estructuras recursivas comolos compuestos.

b. El patrn Factory Method es usado por los iteradores polimrficos para crearinstancias de las subclases apropiadas de Iterator.

c. El patrn Memento suele usarse conjuntamente con el patrn Iterator, quien usaun Memento para representar el estado de una iteracin. El iterador almacena el

memento internamente.


46/64


46 de 64

Patrn Mediator



Propsito

Define un objeto que encapsula como interactan una serie de objetos. Promueve un bajoacoplamiento al evitar que los objetos se refieran unos a otros explcitamente y permite variarla interaccin entre ellos de forma independiente.

Motivacin

Los diseadores orientados a objetos promueven la distribucin de comportamiento entreobjetos. Esto puede dar a lugar una estructura de objetos con muchas conexiones entreellos; en el peor de los casos, cada objeto acaba por conocer a todos los dems.Aunque dividir un sistema en muchos objetos suele mejorar la reutilizacin, la proliferacin de

interconexiones tiende a reducir esta de nuevo. Tener muchas interconexiones hace que seamenos probable que un objeto pueda funcionar sin la ayuda de otros. Mas an, puede serdifcil cambiar el comportamiento del sistema de manera significativa, ya que el mismo seencuentra distribuido en muchos objetos. Como resultado, podemos vernos forzados a definirmuchas subclases para personalizar el comportamiento del sistema.Estos problemas pueden ser evitados encapsulando el comportamiento colectivo en unobjeto aparte llamado Mediador, responsable de controlar y coordinar las interacciones entreun grupo de objetos, evitando que los mismos se refieran unos a otros explcitamente. Losobjetos solo conocen al Mediador, reduciendo as el numero de interconexiones.

Aplicabilidad

Usar Mediator cuando:

1) Un conjunto de objetos se comunican de forma bien definida, pero compleja. Lasinterdependencias resultantes no estn estructuradas y son difciles de comprender.2) Es difcil reutilizar un objeto, ya que este se refiere a otros muchos objetos con los

que se comunica.3) Un comportamiento que esta distribuido entre varias clases debera poder ser

adaptado sin necesidad de una gran cantidad de subclases.

Estructura

Una estructura de objetos tpica


47/64


47 de 64

Participantes

1) Mediador: Define una interfaz para comunicarse con sus objetos Colega.2) MediadorConcreto: Implementa el comportamiento cooperativo coordinando objetos

Colega. Conoce a sus colegas.3) Clases Colega: Cada clase conoce a su objeto Mediador y se comunica a este cada

vez que, de no existir el Mediador, se hubiera comunicado con otro Colega.

Colaboraciones

Los Colegas envan y reciben peticiones a travs de un Mediador. Este implementa elcomportamiento cooperativo encaminando estas peticiones a los Colegas apropiados.

Consecuencias

1) Reduce la herencia: Un Mediador localiza el comportamiento que de otra maneraestara distribuido en varios objetos. Para cambiarlo solo es necesario crear unasubclase del Mediador; las clases Colega pueden ser reutilizadas tal cual (Ventaja).

2) Desacopla a los Colegas: Un Mediador promueve un bajo acoplamiento entreColegas. Las clases Colega pueden usarse y modificarse de forma independiente

(Ventaja).3) Simplifica los protocolos de los objetos:Un Mediador sustituye interacciones muchos-

a-muchos por interacciones uno-a-muchos entre el objeto mediador y sus Colegas,que son ms fciles de comprender, mantener y extender (Ventaja).

4) Abstrae como cooperan los objetos: Hacer de la mediacin un conceptoindependiente y encapsularla en un objeto permite centrarse en como interactan losobjetos en vez de en su comportamiento individual, ayudando a clarificar comointeractan los objetos de un sistema (Ventaja).

5) Centraliza el control: El patrn Mediator cambia complejidad de interaccin porcomplejidad en el mediador, pudiendo hacerse ms complejo que cualquier Colegaindividual, difcil de mantener (Desventaja).

Implementacin

1) Omitir la clase abstracta Mediador: No es necesario definirla cuando los colegas solotrabajan con un Mediador.

2) Comunicacin Colega-Mediador: Los Colegas tienen que comunicarse con sumediador cuando tiene lugar un evento de inters. Un enfoque es implementar elMediador usando el patrn Observer. Las clases Colega envan notificaciones almediador cada vez que cambia su estado y este responde propagando los efectosdel cambio a otros Colegas


48/64


48 de 64


1) El patrn Facade difiere del Mediator en que abstrae un subsistema de objetos paraproporcionar una interfaz ms conveniente. Su protocolo es unidireccional (losobjetos Facade hacen peticiones al subsistema pero no a la inversa). Por elcontrario, Mediator permite un comportamiento cooperativo que no es proporcionadopor los objetos Colegas y el protocolo es multidireccional.

2) El patrn Observer se usa para que los Colegas se comuniquen con el Mediadorpuede usarse si una orden debe ser copiada antes de ser guardada en el historial.


49/64


49 de 64

Patrn Observer

Propsito

Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto

cambie de estado se notifique y se actualicen automticamente todos los objetos quedependen de el.

Motivacin

Un efecto lateral habitual de dividir un sistema en una coleccin de clases cooperantes es lanecesidad de mantener una consistencia entre objetos relacionados, pero sin hacer a lasclases fuertemente acopladas ya que eso reducira su reutilizacin.El patrn Observer describe como establecer estas relaciones. Los principales objetos deeste patrn son el sujeto y el observador. Un sujeto puede tener cualquier numero deobservadores dependientes de l. Cada vez que el sujeto cambia su estado se notifica atodos sus observadores. En respuesta, cada observador consultara al sujeto para sincronizarsu estado con el estado de este.Este tipo de interaccin tambin se conoce como publicar-suscribir. El sujeto es quien publica

las notificaciones. Enva estas sin tener que conocer quienes son sus observadores. Puedensuscribirse un numero indeterminado de observadores para recibir notificaciones.

Aplicabilidad

Usar Observer cuando:1) Una abstraccin tiene dos aspectos y uno depende del otro. Encapsular estos

aspectos en objetos separados permite modificarlos y reutilizarlos de formaindependiente.

2) Cuando un cambio en un objeto requiere cambiar otros y no sabemos cuantosobjetos necesitan cambiarse.

3) Cuando un objeto debera ser capaz de notificar a otros sin hacer suposiciones sobrequienes son dichos objetos (no queremos que estos objetos estn fuertemente

acoplados).

Estructura


50/64


50 de 64

Participantes

1) Sujeto: Conoce a sus observadores. Un sujeto puede ser observado por cualquiernumero de objetos Observador. Proporciona una interfaz para asignar y quitarobjetos Observador.

2) Observador: Define una interfaz para actualizar los objetos que deben sernotificados ante cambios en un sujeto.

3) SujetoConcreto: Almacena el estado de inters para los objetosObservadorConcreto. Enva una notificacin a sus observadores cuando cambia suestado.

4) ObservadorConcreto: Mantiene una referencia a un SujetoConcreto. Guarda unestado que debera ser consistente con el del sujeto. Implementa la interfaz deactualizacin del Observador para mantener su estado consistente con el del sujeto.

Colaboraciones

1) SujetoConcreto notifica a sus observadores cada vez que se produce un cambio quepudiera hacer que el estado de estos fuera inconsistente con el suyo.

2) Despus de ser informado de un cambio en el SujetoConcreto, un objeto

ObservadorConcreto puede pedirle al sujeto ms informacin. ObservadorConcreto usaesta informacin para sincronizar su estado con el del sujeto.

El siguiente diagrama de interaccin muestra las colaboraciones:

El objeto Observador que inicializa la peticin de cambio pospone su actualizacin hasta que

obtiene una notificacin del sujeto. Notificar no siempre es llamado por el sujeto. Puede serllamado por el Observador o por un tipo de objeto completamente diferente.

Consecuencias

El patrn Observer permite modificar los sujetos y observadores de forma independiente. Esposible reutilizar objetos sin reutilizar sus observadores y viceversa, permitiendo aadirobservadores sin modificar el sujeto u otros observadores.


51/64


51 de 64

1) Acoplamiento abstracto entre Sujeto y Observador:Todo lo que un sujeto sabe esque tiene una lista de observadores que se ajusta a la interfaz simple de la claseabstracta Observador. El sujeto no conoce la clase concreta de ningn observador.Por lo tanto el acoplamiento entre sujetos y observadores es mnimo, puedenpertenecer a diferentes capas de abstraccin de un sistema (Ventaja).

2) Capacidad de comunicacin mediante difusin: A diferencia de una peticin

ordinaria, la notificacin enviada por un sujeto no necesita especificar su receptor, seenva automticamente a todos los objetos interesados que se hayan suscripto aella. Al sujeto no le importa cuantos objetos interesados haya; su nicaresponsabilidad es notificar a sus observadores (libertad de aadir y quitarobservadores en cualquier momento) (Ventaja).

3) Actualizaciones inesperadas:Dado que los observadores no saben de la presenciade los otros, pueden no saber el coste ltimo de cambiar el sujeto. Una operacinaparentemente inofensiva sobre el sujeto puede dar lugar a una serie deactualizaciones en cascada de los observadores y sus objetos dependientes(Desventaja).

Usos conocidos

El patrn Observer aparece en el Modelo Vista Controlador (MVC). La clase Modelo

desempea el papel del Sujeto, mientras que Vista es la clase de los Observadores.


52/64


52 de 64

Patrn State


Categora de Problema:Variacin de servicios

Propsito

Permite que un objeto modifique su comportamiento cada vez que cambie su estad interno.Parecer que cambia la clase del objeto.

Problema

Las instancias se comportan de distinta manera en funcin del estado.

Motivacin

La idea clave es introducir una clase abstracta Estado que representa todos los estadosdeclara una interfaz comn para todas las clases que representan diferentes estadosoperacionales. Las subclases implementan comportamiento especfico de cada estado.La clase Contexto mantiene una instancia de una subclase de Estado que representa elestado actual, y delega todas las peticiones dependientes del estado a este objeto de estado,es decir, usa esta instancia para realizar operaciones que dependen del estado delContexto.Cada vez que cambia el estado del contexto, cambia la instancia del objeto estado que esteusa.

Aplicabilidad

Usar cuando:1) El comportamiento de un objeto depende de su estado, y debe cambiar en tiempo de

ejecucin dependiendo de ese estado.2) Las operaciones tienen largas sentencias condicionales con mltiples ramas que

dependen del estado del objeto. Muchas veces son varias las operaciones quecontienen esta misma estructura condicional. El patrn State pone cada rama de lacondicin en una clase aparte. Permite tratar al estado del objeto como un objeto quepuede variar independientemente de otros objetos.

Estructura


53/64


53 de 64

Participantes

1) Contexto: Define la interfaz de inters para los clientes. Mantiene una instancia deuna subclase de EstadoConcreto que define el estado actual.

2) Estado: Define una interfaz para encapsular el comportamiento asociado con undeterminado estado del Contexto.

3) Subclases de EstadoConcreto:Cada una implementa un comportamiento asociado

con un estado del Contexto.

Colaboraciones

Contexto delega las peticiones que dependen del estado en el objeto EstadoConcreto actual.Un contexto puede pasarse a s mismo como parmetro para que el objeto Estado maneje lapeticin. Esto permite al objeto Estado acceder al contexto si fuera necesario.Contexto es la interfaz principal para los clientes. Los clientes pueden configurar un contextocon objetos Estado. Una vez que esta configurado el contexto, sus clientes ya no tienen quetratar con los objetos Estado directamente.Cualquiera de las subclases de Contexto o de EstadoConcreto pueden decidir que estadosigue a otro y bajo que circunstancias.

Consecuencias

3) Sita en un objeto todo el comportamiento asociado con un determinado estado. Comotodo el cdigo dependiente del estado reside en una subclase de Estado, puedenaadirse fcilmente nuevos estados y transiciones definiendo nuevas subclases.(Ventaja).

4) Evita el problema de tener sentencias condicionales repartidas por toda laimplementacin de Contexto, pero de esta manera incrementa el nmero de clases y esmenos compacto que una nica clase. Dicha distribucin es realmente buena si haymuchos estados, que de otro modo necesitaran grandes sentencias condicionales (hayque tratar de evitarlas, ya que tienden a hacer el cdigo menos explicito, difcil demodificar y extender) (Ventaja).

5) Ofrece un modo mejor de estructurar el cdigo dependiente del estado. La lgica quedetermina las transiciones entre estados se reparte entre las subclases de Estado. Alencapsular cada transicin y accin en una clase estamos elevando la idea de un estadode ejecucin a objetos de estado en toda regla (Ventaja).

6) En caso de que los objetos Estado no tengan variables, entonces varios contextospueden compartir un mismo objeto Estado (Ventaja)


54/64


54 de 64

Implementacin

4) Quin define las transiciones entre estados? El patrn no lo especifica. Si estoscriterios son fijos, pueden implementarse enteramente en el Contexto, pero esgeneralmente ms flexible y conveniente que sean las propias subclases de Estadoquienes especifiquen su estado sucesor y cuando llevar a cabo la transicin(requiere agregar una interfaz al Contexto que permita a los objetos Estado asignar

el estado actual del Contexto). Descentralizar de esta forma la lgica facilita modificaro extender dicha lgica definiendo nuevas subclases de Estado, la desventaja es queuna subclase de Estado conocer al menos a otra, lo que introduce dependencias deimplementacin entre subclases.

5) Alternativa basada en tablas: Por cada estado, una tabla hace corresponder cadaposible entrada con un estado sucesor. Este enfoque convierte cdigo en una tablade bsqueda. El patrn modela el comportamiento especfico del estado, mientrasque el enfoque basado en una tabla se centra en definir las transiciones de estado.

Ventaja: Se pueden cambiar los criterios de transicin modificando datos en vez delcdigo del programa.

Desventajasa. Una tabla de bsqueda es normalmente menos eficiente que una llamada a

una funcin.b. Situar la lgica de transicin en un formato tabular uniforme hace que los

criterios de transicin sean ms difciles de comprender.c. Suele dificultar aadir acciones que acompaen a las transiciones de estado.

Similitudes con otros patrones

Si bien estructuralmente son casi idnticos el patrn State con el patrn Strategy, los finespara los que fueron creados no lo son y ah radica su diferencia.El Strategy define familias de algoritmos para cambiar el comportamiento dinmicamente dela clase que los utiliza, pero es esta clase o el cliente el que especifica que algoritmo usar.Adems, por lo general, los algoritmos persiguen el mismo fin, y la diferencia entre ellos

radicara en la forma en que se implementan para obtener un resultado diferente. Ejemplo,para un contexto que se dedica a ordenar, podra tener una estrategia que lo haga con elalgoritmo de Seleccin, otra que lo haga con el de Burbujeo y otra que lo haga por el deInsercin.El State modifica dinmicamente el comportamiento de una clase, en funcin de un ciertoestado (de acuerdo al estado que tenga vara la tarea que voy a realizar). Adems, la lgicade transicin de estados reside generalmente en las subclases concretas de Estado, por loque es transparente para el cliente la utilizacin de los mismos.

Ejemplos

Se puede usar el patrn State para una clase que modele la conexin TCP de una red,donde los distintos estados podran ser: Establecida, Escuchando, Cerrada, etc.

Patrones Relacionados

Los objetos estados muchas veces son Singletons


55/64


55 de 64

Patrn Strategy


Categora de Problema:Variacin de servicios

Propsito

Define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables.Permite que un algoritmo vare independientemente de los clientes que lo usan.

Problema

Posibilidad de cambiar el comportamiento en forma dinmica.

Motivacin

Si existen muchos algoritmos, codificarlos en las clases que los usan no resulta una buenaprctica por:1) Los clientes se vuelven ms complejos, ms grandes y ms difciles de mantener si

incluyen dicho cdigo.2) Los distintos algoritmos sern apropiados en distintos momentos, no hay que permitir

mltiples algoritmos si no los vamos a usar todos.

Aplicabilidad

Usar cuando:1) Muchas clases relacionadas difieren solo en su comportamiento (permiten configurar

Patrones de Diseño Resumen

Documents

Transcript of Patrones de Diseño Resumen