PATRONES DE DISEO Son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo

de interaccin o interfaces. Un patrn de diseo es una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias. PATRONES ESTRUCTURALES BRIDGE (PUENTE) El patrn Bridge, tambin conocido como Handle/Body (Manejador/Cuerpo), es una tcnica usada en programacin para desacoplar una abstraccin de su implementacin, de manera que ambas puedan ser modificadas independientemente sin necesidad de alterar por ello la otra. Esto es, se desacopla una abstraccin de su implementacin para que puedan variar independientemente. Aplicabilidad Se usa el patrn Bridge cuando:
y

y y y

Se desea evitar un enlace permanente entre la abstraccin y su implementacin. Esto puede ser debido a que la implementacin debe ser seleccionada o cambiada en tiempo de ejecucin. Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases. En este caso, el patrn Bridge permite combinar abstracciones e implementaciones diferentes y extenderlas independientemente. Cambios en la implementacin de una abstraccin no deben impactar en los clientes, es decir, su cdigo no debe tener que ser recompilado. (En C++) Se desea esconder la implementacin de una abstraccin completamente a los clientes. En C++, la representacin de una clase es visible en la interface de la clase. Se desea compartir una implementacin entre mltiples objetos (quiz usando contadores), y este hecho debe ser escondido a los clientes.

Participantes y y y Abstraction. Define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor. RefinedAbstraction. Extiende la interface definida por Abstraction Implementor. Define la interface para la implementacin de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente. Tpicamente la interface Implementor provee slo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas. ConcreteImplementor. Implementa la interface de Implementor y define su implementacin concreta.

Colaboraciones y Abstraction. Emite los pedidos de los clientes a su objeto Implementor.

Consecuencias Desacopla interface e implementacin: una implementacin no es limitada permanentemente a una interface. La implementacin de una abstraccin puede ser configurada en tiempo de ejecucin. Adems le es posible a un objeto cambiar su implementacin en tiempo de ejecucin. Desacoplando Abstraction e Implementor tambin elimina las dependencias sobre la implementacin en tiempo de compilacin. Cambiar una clase de implementacin no require recompilar la clase Abstraction ni sus clientes. Esta propiedad es esencial cuando te debes asegurar la compatibilidad binaria entre diferentes versiones de una biblioteca de clases. Es ms, este desacoplamiento fomenta las capas, que pueden conducir a un sistema mejor estructurado. La parte de alto nivel de un sistema slo tiene que conocer Abstraction e Implementor. Mejora la extensibilidad: se puede extender las jerarquas de Abstraction e Implementor independientemente. Esconde los detalles de la implementacin a los clientes. Implementacin Consideremos las siguientes cuestiones de implementacin cuando se aplica este patrn: Slo un Implementor: En situaciones donde existe slo una implementacin, crear una clase Implementor abstracta no es necesario. Esto es un caso especial del patrn; hay una relacin uno-auno entre Abstraction e Implementor. Sin embargo, esta separacin es an muy til cuando un cambio en la implementacin de una clase no debe afectar a sus clientes existente, es decir, ellos no deben ser recompilados, slo relinkeados. En C++, la interface de la clase Implementor puede ser definida en un archivo header privado el cual no es provedo a los clientes. Esto permite esconder una implementacin de una clase completamente de sus clientes. Creando el objeto Implementor adecuado: Cmo, cundo y dnde que clase Implementor instanciar cuando hay ms de una?Si Abstraction conoce todas las clases ConcreteImplementor puede instanciar una de ellas en su constructor; puede decidir cul instanciar dependiendo de los parmetros del constructor. Otra aproximacin es elegir una implementacin inicial por defecto y cambiarla despus acorde al uso. Tambin es posible delegar la decisin a otro objeto en conjunto. Compartiendo implementadores: El estilo Handle/Body en C++ puede ser usado para compartir implementaciones de muchos objetos. Body almacena una cuenta de referencia que la clase Handle incrementa y decrementa. Usando herencia mltiple. Se puede usar herencia mltiple en C++ para asociar una interfaz con su implementacin.

Creamos una clase Abstraccin padre que sea abstracta, adems de abstracciones concretas mediante clases que heredan de ella. Por otro lado se tienen las clases que implementan la funcionalidad con una estructura similar: una clase ImplementacinAbstracta padre, y todas las clases hijas necesarias que implementan la funcionalidad de todas las maneras necesarias. La relacin se da entre la clase abstracta Abstraccin y la clase abstracta Implementacin, delegando la primera la implementacin en la segunda, que a su vez la delega en las implementaciones concretas. DECORATOR El patrn Decorator responde a la necesidad de aadir dinmicamente funcionalidad a un Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera. Problema que soluciona Supongamos que tenemos una clase existente Ventana y queremos aadirle funcionalidad para que muestre un borde alrededor. Podemos crear una subclase VentanaConBorde que herede de Ventana. Hasta aqu todo bien, pero supongamos que surge la necesidad de crear una ventana que muestre un pequeo botn de ayuda con un signo de interrogacin (?) en su parte superior. Entonces tenemos las siguientes opciones:
y y y

Crear otra subclase de Ventana: VentanaConBotnDeAyuda. Problema: No cubre la necesidad de tener ventanas con bordes y botn de ayuda a la vez. Crear una subclase de VentanaConBorde: VentanaConBordeYBotonDeAyuda. Problema: No tenemos una ventana con botn de ayuda y sin borde. Crear clases para todas las combinaciones posibles de funcionalidades. Problema: Con este ejemplo tendramos cuatro clases: Ventana, VentanaConBorde, VentanaConBotonDeAyuda y VentanaConBordeYBotonDeAyuda; con tres funcionalidades tendramos ocho clases y con cuatro, diecisis!

Aplicabilidad
y y y y y

Aadir objetos individuales de forma dinmica y transparente Responsabilidades de un objeto pueden ser retiradas Cuando la extensin mediante la herencia no es viable Hay una necesidad de extender la funcionalidad de una clase, pero no hay razones para extenderlo a travs de la herencia. Hay la necesidad de extender dinmicamente la funcionalidad de un objeto y quizs quitar la funcionalidad extendida.

Implementacin El patrn Decorator soluciona este problema de una manera mucho ms sencilla y extensible. Se crea a partir de Ventana la subclase abstracta VentanaDecorator y, heredando de ella, BordeDecorator y BotonDeAyudaDecorator.VentanaDecorator encapsula el comportamiento de Ventana y utiliza composicin recursiva para que sea posible aadir tantas "capas" de Decorators como se desee. Podemos crear tantos Decorators como queramos heredando de VentanaDecorator.

FACADE Los patrones de diseo dan una solucin probada y documentada a problemas de desarrollo de software que aparecen en un contexto similar. El patrn de diseo Fachada (Facade) es un tipo de patrn estructural. Propsito El patrn fachada se utiliza para proporcionar una interfaz unificada de alto nivel para un conjunto de clases en un subsistema, hacindolo ms fcil de usar. Simplifica el acceso a dicho conjunto de clases, ya que el cliente slo se comunica con ellas a travs de una nica interfaz. Motivacin El patrn fachada viene motivado por la necesidad de estructurar un entorno de programacin y reducir su complejidad con la divisin en subsistemas, minimizando las comunicaciones y dependencias entre stos. Consideraciones Para Su Aplicacin Se aplicar el patrn fachada cuando se necesite proporcionar una interfaz simple para un subsistema complejo, o cuando se quiera estructurar varios subsistemas en capas, ya que las fachadas seran el punto de entrada a cada nivel. Otro escenario proclive para su aplicacin surge de la necesidad de desacoplar un sistema de sus clientes y de otros subsistemas, hacindolo ms independiente, portable y reutilizable (esto es, reduciendo dependencias entre los subsistemas y los clientes). Participantes Fachada (Facade): conoce qu clases del subsistema son responsables de una determinada peticin, y delega esas peticiones de los clientes a los objetos apropiados del subsistema. Subclases (ModuleA, ModuleB, ModuleC...): implementan la funcionalidad del subsistema. Realizan el trabajo solicitado por la fachada. No conocen la existencia de la fachada. [editar]Colaboraciones Los clientes se comunican con el subsistema a travs de la fachada, la cual reenva las peticiones a los objetos apropiados. Por lo tanto, los clientes que usan esa interfaz no tienen por qu acceder directamente a las subclases del sistema, aunque pueden hacerlo. [editar]Consecuencias Las consecuencias ms importantes que resultan de la aplicacin de este patrn son la reduccin del acoplamiento entre clientes y subsistemas (consiguiendo que los cambios de las clases del sistema sean transparentes a los clientes) y el aislamiento de cambios en la implementacin. Tambin oculta a los clientes la complejidad del subsistema, facilitando su uso sin impedir el acceso a las clases del subsistema en caso necesario. Adems, facilita la divisin en capas y reduce dependencias de compilacin. [editar]Ventajas e inconvenientes La principal ventaja del patrn fachada consiste en que para modificar las clases de los subsistemas, slo hay que realizar cambios en la interfaz/fachada, y los clientes pueden permanecer ajenos a ello.

Adems, y como se mencion anteriormente, los clientes no necesitan conocer las clases que hay tras dicha interfaz. Como inconveniente, si se considera el caso de que varios clientes necesiten acceder a subconjuntos diferentes de la funcionalidad que provee el sistema, podran acabar usando slo una pequea parte de la fachada, por lo que sera conveniente utilizar varias fachadas ms especficas en lugar de una nica global. [editar]Patrones relacionados Uno de los patrones relacionados ms directamente es el singleton, dado que en determinadas ocasiones las fachadas pueden ser instancias nicas. Otros patrones que guardan una cierta relacin con el patrn fachada son los GRASP (General Responsibility Assignment Software Patterns), los cuales no son patrones de diseo, sino buenas prcticas que guan al desarrollador para encontrar los patrones de diseo, que son ms concretos. Uno de los patrones GRASP es un controlador que acta como punto de entrada en la capa lgica, lo que se puede comparar perfectamente con el uso del patrn fachada. [editar]Usos conocidos (Problemas/Soluciones) Problema: Un cliente necesita acceder a parte de la funcionalidad de un sistema ms complejo.


Definir una interfaz que permita acceder solamente a esa funcionalidad.

Problema: Existen grupos de tareas muy frecuentes para las que se puede crear cdigo ms sencillo y legible.


Definir funcionalidad que agrupe estas tareas en funciones o mtodos sencillos y claros. Problema: Una biblioteca es difcilmente legible.

Crear un intermediario ms legible. Problema: Dependencia entre el cdigo del cliente y la parte interna de una biblioteca.

Crear un intermediario y realizar llamadas a la biblioteca slo o, sobre todo, a travs de l. Problema: Necesidad de acceder a un conjunto de APIs que pueden adems tener un diseo no muy bueno.

Crear una API intermedia, bien diseada, que permita acceder a la funcionalidad de las dems. Problema: Muchas clases cliente quieren usar varias clases servidoras, y deben saber cul es exactamente la que le proporciona cada servicio. El sistema se volvera muy complejo, porque habra que relacionar todas las clases cliente con todas y cada una de las clases servidoras.

Crear una o varias clases Facade, que implementen todos los servicios, de modo que o todos los clientes utilicen esa nica clase, o que cada grupo de clientes use la fachada que mejor se ajuste a sus necesidades.

PROXY

El patrn Proxy es un patrn estructural que tiene como propsito proporcionar un subrrogado o intermediario de un objeto para controlar su acceso. Motivacin Para explicar la motivacin del uso de este patrn veamos un escenario dnde su aplicacin sera la solucin ms adecuada al problema planteado. Consideremos un editor que puede incluir objetos grficos dentro de un documento. Se requiere que la apertura de un documento sea rpida, mientras que la creacin de algunos objetos (imgenes de gran tamao) es cara. En este caso no es necesario crear todos los objetos con imgenes nada ms abrir el documento porque no todos los objetos son visibles. Interesa por tanto retrasar el coste de crear e inicializar un objeto hasta que es realmente necesario (por ejemplo, no abrir las imgenes de un documento hasta que no son visibles). Lasolucin que se plantea para ello es la de cargar las imgenes bajo demanda. Pero, cmo cargar las imgenes bajo demanda sin complicar el resto del editor? La respuesta es utilizar un objeto proxy. Dicho objeto se comporta como una imagen normal y es el responsable de cargar la imagen bajo demanda. Aplicabilidad El patrn proxy se usa cuando se necesita una referencia a un objeto ms flexible o sofisticada que un puntero. Dependiendo de la funcin que se desea realizar con dicha referencia podemos distinguir diferentes tipos de proxies: proxy remoto: representante local de un objeto remoto. proxy virtual: crea objetos costosos bajo demanda (como la claseImagenProxy en el ejemplo de motivacin).  proxy de proteccin: controla el acceso al objeto original (ejemplo de proxy de proteccin: [1])  proxy de referencia inteligente: sustituto de un puntero que lleva a cabo operaciones adicionales cuando se accede a un objeto (ej. contar nmero de referencias al objeto real, cargar un objeto persistente bajo demanda en memoria, control de concurrencia de acceso tal como bloquear el objeto para impedir acceso concurrente, ). Participantes
 

La clase Proxy : mantiene una referencia al objeto real (en el siguiente ejemplo se le denomina _sujetoReal) y proporciona una interfaz idntica al sujeto (la claseSujeto). Adems controla el acceso a dicho objeto real y puede ser el responsable de su creacin y borrado. Tambin tiene otras responsabilidades que dependen del tipo de proxy:
  

proxy remoto: responsable de codificar una peticin y sus argumentos, y de enviarla al objeto remoto. proxy virtual: puede hacer cach de informacin del objeto real para diferir en lo posible el acceso a este. proxy de proteccin: comprueba que el cliente tiene los permisos necesarios para realizar la peticin.

La clase Sujeto: define una interfaz comn para el proxy (Proxy) y el objeto real (de la clase SujetoReal), de tal modo que se puedan usar de manera indistinta. La clase SujetoReal: clase del objeto real que el proxy representa. [editar]Colaboraciones. Dependiendo de la clase de proxy, el objeto proxy redirige las peticiones al objeto real que representa. Ejemplos de funcionamiento:

Diagrama de clases para un ejemplo del patrn proxy.[2] Diagrama de secuencia para un ejemplo en el que no se utiliza el patrn proxy. [3] Diagrama de secuencia para un ejemplo en el que se utiliza el patrn proxy.[4] [editar]Consecuencias.
  

El uso de un proxy introduce un nivel de indireccin adicional con diferentes usos:

  

Un proxy remoto oculta el hecho de que un objeto reside en otro espacio de direcciones. Un proxy virtual puede realizar optimizaciones, como la creacin de objetos bajo demanda. El proxy de proteccin y las referencias inteligentes permiten realizar diversas tareas de mantenimiento adicionales al acceder a un objeto.

Adems, su uso tambin permite realizar una optimizacin COW (copy-on-write) , puesto que copiar un objeto grande puede ser costoso, y si la copia no se modifica, no es necesario incurrir en dicho gasto. Adems el sujeto mantiene un nmero de referencias, y slo cuando se realiza una operacin que modifica el objeto, ste se copia. Es til por tanto para retrasar la replicacin de un objeto hasta que cambia. CHAIN OF RESPONSABILITY El patrn de diseo Chain of Responsibility permite establecer una cadena de objetos receptores a travs de los cuales se pasa una peticin formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la peticin en funcin de un criterio establecido. Motivacin Se utiliza, por ejemplo, cuando en funcin del estado del sistema las peticiones emitidas por un objeto deben ser atendidas por distintos objetos receptores. Implementacin Todos los objetos receptores implementarn la misma interfaz o extendern la misma clase abstracta. En ambos casos se proveer de un mtodo que permita obtener el sucesor y as el paso de la peticin por la cadena ser lo ms flexible y transparente posible. COMMAD Intencin Este patrn permite solicitar una operacin a un objeto sin conocer realmente el contenido de esta operacin, ni el receptor real de la misma. Para ello se encapsula la peticin como un objeto, con lo que adems se facilita la parametrizacin de los mtodos. Propsito Encapsula un mensaje como un objeto, con lo que permite gestionar colas o registro de mensaje y deshacer operaciones.  Soportar restaurar el estado a partir de un momento dado.  Ofrecer una interfaz comn que permita invocar las acciones de forma uniforme y extender el sistema con nuevas acciones de forma ms sencilla. Motivo


El concepto de "orden" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: intrpretes de rdenes del sistema operativo, lenguajes de macros de paquetes ofimticos, gestores de bases de datos, protocolos de servidores de Internet, etc.  Este patrn presenta una forma sencilla y verstil de implementar un sistema basado en comandos facilitndose su uso y ampliacin. Aplicaciones


Facilitar la parametrizacin de las acciones a realizar. Independizar el momento de peticin del de ejecucin. Implementar CallBacks, especificando que rdenes queremos que se ejecuten en ciertas situaciones de otras rdenes. Es decir, un parmetro de una orden puede ser otra orden a ejecutar.  Soportar el "deshacer".  Desarrollar sistemas utilizando rdenes de alto nivel que se construyen con operaciones sencillas (primitivas). Terminologa
  

La terminologa usada para describir la implementacin del patrn rden (command pattern) no es consistente y puede por tanto ser confusa. Esto resulta de la ambigedad, el uso de sinnimos e implementaciones que puede oscurecer el patrn original por ir ms alla de l. 1. Ambigedad. 1. El trmino rden es ambiguo. Por ejemplo: mover arriba; mover arriba puede referirse a una orden simple (mover arriba) que debe ejecutarse por dos veces, o puede referirse a dos rdenes, cada una de las cuales ocurre que hace lo mismo (mover arriba). Si la primera version de la rden es aadida por dos veces en una pila de retrotraccin (undo stack), ambos items en la pila se refieren a la misma instancia de la rden. Esto puede ser apropiado cuando un comando puede ser siempre retrotrado del mismo modo(p.ej: mover abajo). Tanto la Banda de los cuatro (Gang of Four) como el ejemplo Java de aqu abajo usan esta interpretacin del trmino rden. Por otro lado, si la interpretacin posterior es lo que se aade a la pila de retrotraccin, la pila se refiere a dos objetos separados. Esto puede ser apropiado cuando cada objeto en la pila debe contener informacin que permita al comando ser retrotraido (deshecho). Por ejemplo, para retrotraer una orden de borrar seleccin, la rden debe contener una copia del texto eliminado tal que pueda ser reinsertado si la orden de borrar seleccin debe ser retrotrada. Ntese que usar un objeto separado por cada invocacin de la rden es tambin un ejemplo del patrn cadena de responsabilidades. 2. El trmino ejecutar tambin es ambiguo. Se puede referir a la ejecucin del cdigo identificado por el mtodo ejecutar del objeto rden. Sin embargo en Windows Presentation Foundation de Microsoft una rden se considera ejecutada cuando el mtodo ejecutar de la rden ha sido invocado, pero no significa necesariamente que el cdigo de la aplicacin haya sido ejecutado. Eso ocurre slo tras algn procesado de eventos ms. 2. Sinnimos y homnimos. 1. Cliente(Client), Fuente(Source), Invocador (Invoker): el botn, el botn de barra de herramientas, o item de men clicado, el atajo de teclado presionado por el usuario. 2. Objeto Orden(Command Object), Objeto Orden Enrutada (Routed Command Object), Objeto Accin (Action Object): un objeto singleto(p.ej: Slo hay un objeto OrdenCopiar (CopyCommand)), el cual conoce acerca de teclas de atajo, imgenes de botn, texto de rden, etc. relacionados con la rden. Un objeto Fuente/Invocador llama al mtodo ejecutar/realizarAccin del objeto Orden/Accin. El objeto Orden/Accin notifica a los objetos Fuentes/Invocadores apropiados cuando la disponibilidad de una Orden/Accin ha cambiado. Esto permite a los botones e items de men inactivarse (en color gris) cuando una Orden/Accin no puede ser ejecutada/realizada.

3. Receptor(Receiver), Objeto Destino(Target Object): el objeto que est a punto deser copiado, pegado movido, etc. El objeto Receptor posee el mtodo que es llamado en el mtodo ejecutar de la rden. El receptor es tpicamente el Objeto Destino. Por ejemplo, si el objeto Receptor es un cursor y el mtodo se llama moverArriba, se esperara que el cursor es el objeto de tal accin moverArriba. Por otro lado, si el cdigo est definido por el objeto Orden mismo, el objeto Destino ser otro objeto completamente diferente. 4. Objeto Orden (Command Object), Argumentos de Evento Enrutado (routed event args), Objeto Evento (event object): el objeto que es pasado de la Fuente al objeto Orden/Accin, al objeto Destino al cdigo que hace el trabajo. Cada click de botn o atajo de teclado resulta en un nuevo objeto Orden/Evento. Algunas implementaciones aaden ms informacin (p.ej: la Seccin de un documento) al objeto Orden/Evento cuando es pasado de un objeto (p.ej: OrdenCopiar) a otro. Otras implementacines ponen objetos Ordenes/Eventos en otros objetos Eventos (como pequeas cajas dentro de cajas mayores) segn se van moviendo por la lnea de ejecucin, para evitar conflictos de nombramientos. (Vease tambin patrn cadena de responsabilidades). 5. Manipulador(Handler), ManipuladorDeEventoEnrutadoEjecutado(ExecutedRoutedEventHandler), mtodo(method), funcin(function): el cdigo real que hace el copiado, pegado, movida, etc. En algunas implementaciones el cdigo del manipulador es parte del objeto Orden/Accin. En otras implementaciones es parte del objeto Receptor/Destino, y en aun otras implementaciones el cdigo del manipulador es guardado separado de otros objetos. 6. Gestor de Ordenes (Command Manager), Gestor de Retrotraccin (Undo Manager), Planificador (Scheduler), Cola (Queue), Resolutor(Dispatcher), Invocador(Invoker): un objeto que pone objetos Orden/Evento en una pila de retrotraccin o en otra pila de repeticin, o que mantiene objetos Orden/Evento hasta que otros objetos estn preparados para actuar con ellos, o que enruta objetos de Orden/Evento al objeto Receptor/Destino o cdigo manipudlador apropiado. 3. Implementaciones que exceden el patrn Orden original. 1. Windows Presentation Foundation (WPF) de Microsoft, presenta rdenes enrutadas, que combinan el patrn Orden con el procesado de eventos. Como resultado el objeto Orden ya no contiene una referencia al objeto Destino ni una referencia al cdigo de aplicacin. En cambio, invocar el mtodo ejecutar del objeto Orden resulta en algo llamado Evento Enrutado Ejecutado (Executed Routed Event) el cual durante el tunelado o enburbujamiento del evento puede encontrar un objeto unin(binding) que identifica el Destino u el cdigo de aplicacin, el cual se ejecutar entonces. Ejemplo Patron Comando en Wikibooks


Wikilibros alberga un libro o manual sobre Singleton.

Considrese un "simple" interruptor. en este ejemplo configuramos el interriptor con dos rdenes: encender la luz y apagar la luz. Un beneficio de esta implementacin en particular del patrn rden es que el interruptor puede ser usado en cualquier dispositivo, no solo con una luz - el interruptor en el siquiente ejemplo enciende y apaga la luz, pero el constructor del interruptor es capaz de aceptar cualquier subclase de Orden para sus dos parmetros. Por ejemplo, se podra configurar el interruptor para encender un motor.

Ntese: Una crtica de la aplicacin de ejemplo es que no modeliza verdaderamente un circuito electrico. Un interruptor elctrico es tonto.un verdadero interruptor binario slo conoce si est en una posicion u otra. No sabe nada o no tiene relacin directa con con las tareas que se le podran asignar en un circuito. El interruptor simplemente publica un evento de su estado actual( encendiro o apagado). el circuito debera entonces contener una Mquina de estados que gestione los estados en momentos dados (escuchando los eventos del interruptor) para acomodar apropiadamente complejos circuitos con tareas e interruptores. Cada tarea es condicional a un estado especfico del circuito ( no directamente a un interruptor). En conclusin, el interruptor no debera ser consciente de los detalles de la lmpara. Participantes


AbstractCommand.

Clase que ofrece una interfaz para la ejecucin de rdenes. Define los mtodos do y undo que se implementarn en cada clase concreta.


ConcreteCommand.

Clase que implementa una orden concreta y sus mtodos do y undo. Su constructor debe inicializar los parmetros de la orden.


Invoker.

Clase que instancia las rdenes, puede a su vez ejecutarlas inmediatamente (llamando a do) o dejar que el CommandManager lo haga.


CommandManager.

Responsable de gestionar una coleccin de objetos orden creadas por el Invoker. llamar a los mtodos do y unDo. Gestionar su secuenciacin y reordenacin (sobre la base de prioridades por ejemplo). Consecuencias Se independiza la parte de la aplicacin que invoca las rdenes de la implementacin de los mismos.  Al tratarse las rdenes como objetos, se puede realizar herencia de las mismas, composiciones de rdenes (mediante el patrn Composite).  Se facilita la ampliacin del conjunto de rdenes. Usos conocidos


Las clases Button y MenuItem de Java facilitan la utilizacin de este patrn, declaran los mtodos getActionCommand y setActionCommand para dar nombres a las acciones realizadas por los objetos, facilitndose una correspondencia entre ambos. Patrones relacionados


Factory Method

Ofrece una forma alternativa de llamar a los rdenes adems del uso del command manager.


Intrprete

Se puede implementar un pequeo Intrprete mediante clases Command.



Template Method

Puede servir para implementar la lgica de Deshacer de forma un tanto automtica o a alto nivel.


Composite

Permite realizar agrupaciones de rdenes de forma similar a una macro.



Prototype

Hay quien lo utiliza para implementar la copia de la orden al histrico de rdenes.



Memento

Puede mantener el estado que requiere el comando para deshacer su efecto. MEDIATOR Un Mediator es un patrn de diseo que coordina las relaciones entre sus asociados. Permite la interaccin de varios objetos, sin generaracoples fuertes en esas relaciones. Intencin Definir un objeto que encapsule cmo interacta un conjunto de objetos. [editar]Motivacin Cuando muchos objetos interactan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los dems objetos. Para evitar esto el patrn Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto. [editar]Aplicabilidad Usar el patrn Mediator cuando: Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja. Reutilizar un objeto se hace difcil por que se relaciona con muchos objetos. El comportamiento de muchos objetos que esta distribuido entre varias clases, puede resumirse en una o varias por subclasificacin. [editar]
  

Participantes
  

Mediator (mediador): define una interfaz para comunicarse con los objetos colegas. ConcreteMediator ("mediador concreto"): Implementa el comportamiento cooperativo entre los colegas (como se comunican entre ellos). Adems los conoce y mantiene. Colleagues ("colegas"): Cada colega conoce su mediador, y usa a este para comunicarse con otros colegas.

Ejemplo explicativo: El mediator es el que tiene la tarifa plana y se encarga de llamar a todos los colegas. Los colegas llaman al mediador para ahorrase unos duros en la factura [editar]Colaboraciones Los colegas envan y reciben requerimientos (requests) de un objeto mediador. El mediador implementa como se comunican los colegas. [editar]Consecuencias El patrn Mediator tiene los siguientes beneficios y desventajas:

Desacopla a los colegas: el patrn Mediator promueve bajar el acoplamiento entre colegas. Se puede variar y rehusar colegas y mediadores independientemente  Simplifica la comunicacin entre objetos: Los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y ms elegante. Adems esta forma de comunicacin es ms fcil de entender.  Abstrae como los objetos cooperan: Haciendo a la mediacin un concepto independiente y encapsulandolo en un objeto permite enfocar como los objetos interactan. Esto ayuda a clarificar como los objetos se relacionan en un sistema.  Centraliza el control: El mediador es el que se encarga de comunicar a los colegas, este puede ser muy complejo, difcil de entender y modificar OBSERVER


El patrn Observador (en ingls: Observer) tambin conocido como "spider" define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el observador se encarga de notificar este cambio a todos los otros dependientes. El objetivo de este patrn es desacoplar la clase de los objetos clientes del objeto, aumentando la modularidad del lenguaje, as como evitar bucles de actualizacin (espera activa o polling). Este patrn tambin se conoce como el patrn de publicacin-inscripcin o modelo-patrn. Estos nombres sugieren las ideas bsicas del patrn, que son bien sencillas: el objeto de datos, llammoslo "Sujeto" a partir de ahora, contiene atributos mediante los cuales cualquier objeto observador o vista se puede suscribir a l pasndole una referencia a s mismo. El Sujeto mantiene as una lista de las referencias a sus observadores. Los observadores a su vez estn obligados a implementar unos mtodos determinados mediante los cuales el Sujeto es capaz de notificar a sus observadores "suscritos" los cambios que sufre para que todos ellos tengan la oportunidad de refrescar el contenido representado. De manera que cuando se produce un cambio en el Sujeto, ejecutado, por ejemplo, por alguno de los observadores, el objeto de datos puede recorrer la lista de observadores avisando a cada uno. Este patrn suele observarse en los frameworks de interfaces grficas orientados a objetos, en los que la forma de capturar los eventos es suscribir 'listeners' a los objetos que pueden disparar eventos. En Java se puede heredar la funcionalidad del patrn Observer de la clase Observable y los observadores pueden implementar la interfaz Observer y por lo tanto redefinir el mtodo update().