UML

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.

Visitor

Nombre del patrón
Visitor

Clasificación del patrón
De comportamiento

Intención
Permite incluir nuevos métodos a una clase sin tener que modificarla.

Aplicabilidad
Recomendado para:

• Estructuras jerárquicas (arboles).
• Muchas clases poco relacionadas entre sí.
• Estructura de objetos con diferentes interfaces y posibilidad de ampliación.
• Estructura con altas probabilidades de incluir de nuevos métodos.
• Compiladores, intérpretes.

No recomendado para:

• Sistemas con cambios constantes en estructura global.
• Estructuras poco jerárquicas.

Estructura

Participantes
Visitor. Declara una operación visitar para cada clase de operación ConcreteElement de la estructura de objetos.
ConcreteVisitor. Implementa cada operación declarada por Visitor.
Element. Define una operación que le permite aceptar la visita de un Visitor.
ConcreteElement. Implementa la operación Aceptar que se limita a invocar su correspondiente método del Visitor.
ObjectStructure. Puede enumerar sus elementos y puede proporcionar una interfaz de alto nivel para permitir al Visitor visitar sus elementos.

Colaboraciones

Implementación

Al implementar el patron Visitor debemos tenr en cuenta:

• El cliente crea una instancia de un ConcreteVisitor y lo utiliza para recorrer su estructura.
• Las clases visitadas por un mismo Visitor pueden no estar relacionadas entre sí a través de la herencia.
• El Visitor facilita añadir nuevas operaciones.
• Agrupa operaciones relacionas y separa las que no lo están.
• Añadir nuevas clases a la estructura resulta muy costoso.

Patrones relacionados
Composite.
Interpreter.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/23_Visitor.ppt
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/visitor.pdf

Template Method

Nombre del patrón
Template Method (Metodo Plantilla)

Clasificación del patrón
De comportamiento

Intención
Define en una clase abstracta el esqueleto o los pasos de un algoritmo y cada subclase implementa la estructura concreta de cada uno de los pasos.

Motivación
Supongamos que tenemos una aplicación definida por dos clases, la clase “Application” y la clase “Document”. La clase “Application” se ocupa de abrir documentos almacenados en un formato externo (un fichero). Un objeto de la clase “Document”, representa la información en un documento, una vez que se ha leído del fichero.
La operación OpenDocument() permite abrir y leer un documento.
Se trata de un template method. Define su estructura mediante operaciones abstractas, las cuales serán implementadas por las clases hijas para determinar el comportamiento específico de cada una de ellas.

Aplicabilidad
Se usa para implementar partes invariantes de un algoritmo, y dejar a las subclases implementar el comportamiento que puede variar.
Cuando tenemos un comportamiento común en diferentes clases, puede ser refactorizado para evitar la duplicación de código. Para ello se identifican las partes diferentes del código, se separan mediante nuevas operaciones y se reemplazan con un método que hace uso de ellas.
Para controlar la redefinición de operaciones en las subclases, es posible definir un método Template que llama a una operación “Hook” dentro de la operación que queremos evitar su redefinición, permitiendo únicamente la extensión de la operación “Hook”.
Una subclase puede heredar el comportamiento de una clase padre redefiniendo la operación y llamando a la operación del padre explícitamente:

Estructura

Participantes
AbstractClass. Implementa un método plantilla que define el esqueleto de un algoritmo y define métodos abstractos que implementan las subclases concretas.
ConcreteClass. Implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.

Colaboraciones
Las clases concretas confían en que la clase abstracta implemente la parte fija del algoritmo

Consecuencias
Ventajas y desventajas:

• Favorece la reutilización del código. Muy útiles para construir bibliotecas, pues ayuda a factorizar el comportamiento común de las clases.
• Lleva a una estructura de control invertido (Principio de Hollywood): la superclase base invoca los métodos de las subclases.

Implementación

• En C++. Las operaciones primitivas pueden definirse como protegidas, permitiendo a las clases hijas su implementación. Tendrán que usarse únicamente dentro del método Template, el cual no debería ser redefinido, por lo que nunca se declarará como virtual. Las operaciones primitivas que obligatoriamente hay que definir, se declaran como virtuales puras.
• Minimizar las operaciones primitivas. Es importante que el número de operaciones primitivas sea pequeño, cuantas más operaciones haya que definir, mas tedioso será el trabajo que conlleva crear nuevas clases.
• Convenios de nombres. Se debe poder diferenciar las operaciones que podrían ser redefinidas con las que tienen que ser definidas, por ejemplo añadiendo un prefijo a sus nombres.

Usos Conocidos
Se suelen encontrar en casi todas las clases abstractas

Patrones relacionados
Strategy. El Strategy usa la composición para cambiar todo el algoritmo, los métodos plantilla usan la herencia para cambiar parte de un algoritmo.
Factory Method. Los métodos fábrica suelen llamarse desde métodos plantilla

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.lsi.us.es/docencia/get.php?id=1310
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/IteratorTemM.pdf
http://kybele.escet.urjc.es/docencia/SI/2006-2007/Material/Patrones/22_TemplateMethod.ppt

Strategy

Nombre del patrón
Strategy

Clasificación del patrón
De comportamiento.

Intención
Estructurar una familia de algoritmos de modo que sus clientes puedan intercambiarlos en tiempo de ejecución

También conocido como
Policy

Aplicabilidad
Usar este patrón cuando:

• Muchas clases relacionadas difieren sólo en su comportamiento.


• Se necesitan distintas variantes del mismo algoritmo.


• Una clase define muchos comportamientos.

Estructura

Consecuencias
El uso del patrón Strategy tiene las siguientes ventajas y desventajas:

• Factoriza aspectos comunes de una familia de algoritmos y utilizarlos en las clases base de la jerarquía.
• Aumenta cohesión del cliente.
• Sistematiza el uso de implementaciones alternativas.
• El cliente es el responsable de crear estrategias, por tanto debe comprender las posibilidades que ofrecen, esto es, debe ser relevante para el contexto del cliente.
• Menor eficiencia. Aumenta el número de objetos creados.

Implementación

• Conviene analizar si es posible encapsular comportamiento común a todas las estrategias en una superclase.
• El cliente puede pasar la información necesaria al algoritmo o bien pasarse asimismo.
• El cliente puede evitar la creación innecesaria de objetos cuando la estrategia solicitada es idéntica a la última

Patrones relacionados
TemplateMethod. Una intención similar pero haciendo uso de la herencia en lugar de delegación

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.lsi.us.es/docencia/get.php?id=1378

State

Nombre del patrón
State

Clasificación del patrón
De comportamiento.

También conocido como
Objetcs for States.

Motivación
Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Parecerá que cambia la clase del objeto.

Aplicabilidad
· Aplicaciones cuyos componentes cambian de estado de forma dinámica durante su ejecución.
· Aplicaciones con grandes condicionales dependientes del estado de un objeto.

Estructura

Participantes
Context
Define interfaz y mantiene una instancia con el estado actual
State
Define interfaz para el comportamiento asociado a un determinado estado del Contexto.
Subclases Concrete State
Cada subclase implementa el comportamiento asociado con un estado del contexto.

Consecuencias
Localiza el comportamiento dependiente del estado y divide dicho comportamiento en diferentes estados. Las transiciones entre estados no residen en sentencias if o swtich monolíticas, sino que se reparte entre las subclases.
Hace explícitas las transiciones entre estados. Introducir objetos separados para los diferentes estados hace que las transiciones sean más explícitas.
Los objetos Estado pueden compartirse.

Implementación
Al momento de implementar el patrón State debemos tener en cuenta:

• No queda claro quien define las transiciones entre estados.
• Una alternativa basada en tablas.
• Crear y destruir objetos estados.
• Usar herencia dinámica (sólo permitido en algunos lenguajes de programación (self) )

Usos Conocidos

Conexión TCP. Clase abstracta “Estado TCP” y derivan los diferentes estados de la conexión.
Herramientas de dibujo. Clase abstracta “herramienta” y derivan los diferentes tipos de herramientas.

Patrones relacionados
Flyweight
Singleton

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/Bridge-State.pdf
http://kybele.escet.urjc.es/documentos/SI/Patrones/20_State.ppt
http://www.ldc.usb.ve/~mgoncalves/IS2/sd07/grupo3.pdf

Observer

Nombre del patrón
Observer

Clasificación del patrón
De comportamiento

Intención
Definir una dependencia de uno-a-muchos entre objetos, de manera que cuando un objeto cambia de estado todos los que dependan de él sean notificados y actualizados automáticamente.

También conocido como
Dependents, Publish-Subscribe

Motivación
Un efecto secundario común en un sistema particionado en una colección de clases que cooperan es la necesidad de mantener la coherencia entre los objetos relacionados. No se desea lograr la coherencia, haciendo clases estrechamente unidas ya que esto reduce la reutilización.
El patrón Observer describe como estableces las relaciones entre las clases. Los objetos claves en este patrón son el sujeto y el observador. Un sujeto puede tener cualquier número de observadores dependientes. Todos los observadores son notificados cuando el sujeto se somete a un cambio de estado. Como respuesta, cada observador consulta el sujeto pata sincronizar este estado con los estados de los demás sujetos.

Aplicabilidad
Aplicamos el patrón Observer cuando se tenemos alguna de estas situaciones:

• Cuando una abstracción tiene dos aspectos, uno depende del otro. Encapsular estos aspectos en objetos separados permitirá variarlos y reutilizarlos de forma independiente.
• Cuando un cambio en un objeto requiere cambiar otros, y no se conoce cuantos objetos necesitan ese cambio.
• Cuando un objeto debe ser capaz de notificar a otros objetos sin suponer acerca de que son esos objetos. En otras palabras, no se quiere que los objetos estén perfectamente acoplados.

Estructura

Participantes

Subject

• Conoce a sus observadores. Cualquier número de objetos Observer pueden observar un subject.
• Provee una interfaz para conectar y desconectar objetos Observer.

Observer

Define una interfaz actualizada para objetos que deben ser notificados de los cambios en un sujeto (subject)

ConcreteSubject

• Almacena el estado de los objetos ConcreteObserver interesados.
• Envía una notificación a sus observadores cuando su estado cambia.

ConcreteObserver

• Mantiene una referencia a un objeto ConcreteSubject.
• Almacena el estado que debe mantener consistencia con el sujeto.
• Implementa la interfaz actualizada de Observer para mantener su estando en concordancia con el del sujeto.

Colaboraciones

• El objeto observado notifica a sus observadores cada vez que ocurre un cambio, con la finalidad de que el estado de ambos sea consistente.
• Después de ser informado de un cambio en el objeto observado, cada observador concreto puede pedirle la información que necesita para reconciliar su estado con el de aquél.

Consecuencias
EL patrón Observer permite variar los sujetos y los observadores independientemente. Se puede rehusar sujetos sin el rehúso de observadores y viceversa. Permite agregar observadores sin modificar el sujeto o los observadores.
Algunas ventajas y desventajas del patrón Observer son:

1. Acoplamiento abstracto entre Subject y Observer. Todo lo que un objeto sabe de sus observadores es que tiene una lista de objetos que satisfacen la interfaz Observer. Con lo que podrían incluso pertenecer a dos capas distintas de la arquitectura de la aplicación.
2. No se especifica el receptor de una actualización. Se envía a todos los objetos interesados
3. Actualizaciones inesperadas. Se podrían producir actualizaciones en cascada muy ineficientes.

Implementación
Varias cuestiones relacionadas con los mecanismos de dependencias son discutidas a la hora de implementar el patrón Observer:

1. Correspondencia entre objetos observados y observadores. En vez de mantener una colección con referencias explícitas a los observadores en el objeto observado, sería posible hacerlo con una tabla hash que relacionase ambos. Útil cuando hay muchos objetos a observar y pocos observadores, para reducir los costes de Almacenamiento.
2. Observar más de un objeto. Cuando un observador dependa de más de un objeto, es necesario ampliar la información de la operación update. Por ejemplo, incluyéndose el objeto observado a sí mismo como parámetro, para que el observador pueda discriminar.
3. ¿Quién lanza la actualización? Es decir, ¿quién se encarga de llamar a notify? El objeto observado, cada vez que cambia su estado, puede dar lugar a actualizaciones ineficientes, Los clientes puede eliminar actualizaciones intermedias innecesarias, más propenso a errores: los clientes pueden olvidarse de llamar a notify.
4. Evitar protocolos de actualización específicos de los observadores. Modelo push: El objeto observado envía información detallada a sus observadores sobre el cambio producido, (La necesiten o no). Modelo pull: Tan sólo avisa de que cambió, Los observadores le solicitan la información que necesiten.
5. Especificar explícitamente el aspecto que varía. Podemos extender la interfaz de registro de observadores para que éstos indiquen los eventos que les interesan. Cuando se produzca un evento, el objeto observado informará sólo a los observadores interesados en ese evento.

Usos Conocidos

• Uno de los primeros usos conocidos del patrón Observer aparece en Smalltalk Model/View/Controller.
• Delegación de eventos en Java.

Patrones relacionados
Mediator. Para encapsular actualizaciones semánticas complejas, el ChangeManager actúa como mediador entre sujetos y observadores.
Singleton. El ChangeManager puede usar el patrón Singleton para que sea único y accesible a nivel global.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/16_Observer.ppt
http://sophia.javeriana.edu.co/~lcdiaz/ingSw2006-3/ptnObserver_dAli.ppt
http://www.cesaracebal.com/docencia/asignaturas/aaswiki/_media/patrones/observer-mvc.pdf?id=patrones%3Amvc&cache=cache

Memento

Nombre del patrón
Memento

Clasificación del patrón
De comportamiento

Intención
Memento guarda parte o todo el estado interno de un objeto, para que este objeto pueda ser restaurado más tarde al estado guardado por Memento. Esta operación debe ocurrir sin romper el principio del encapsulamiento.

También conocido como
Token

Motivación
Muchas veces es necesario guardar el estado interno de un objeto. Esto debido a que tiempo después, se necesita restaurar el estado del objeto, al que previamente se ha guardado.
Para facilitar el hacer y deshacer de determinadas operaciones, para lo que habrá que guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental).

Aplicabilidad
El patrón Memento es aplicable cuando:

• Todo o parte del estado de un objeto debe ser guardado para ser restaurado más tarde.
• Cuando una interfaz directa para obtener el estado de un objeto exponga detalles de su implementación.

Estructura

Participantes
Memento.

• Almacena el estado interno de un objeto Originator. El Memento puede almacenar mucho o parte del estado interno de Originator.
• Tiene dos interfaces. Una para Caretaker, que le permite manipular el Memento únicamente para pasarlo a otros objetos. La otra interfaz sirve para que Originator pueda almacenar/restaurar su estado interno, sólo Originator puede acceder a esta interfaz, al menos en teoría.

Originator.

• Crea un objeto Memento conteniendo una fotografía (un instante) de su estado interno.
• Usa a Memento para restaurar su estado interno.

Caretaker

• Es responsable por mantener a salvo a Memento.
• No opera o examina el contenido de Memento.

Colaboraciones

• Un Carataker solicita un memento a un creador, lo almacena durante un tiempo y se lo devuelve a su creador, tal y como muestra el diagrama.
• A veces el Carataker no devolverá el memento a su creador, ya que el creador podría no necesitar nunca volver a un estado anterior.
• Los mementos son pasivos. Sólo el creador que creó el memento asignará o recuperará su estado.
  

Consecuencias
El patrón Memento tiene las siguientes consecuencias:

1. Preserva la encapsulación. Originator crea un Memento y el mismo almacena su estado interno, de esta manera no es necesario exponer el estado interno como atributos de acceso público, preservando así la encapsulación.
2. Simplificar Originator. Memento podría incurrir en gastos considerables si Originator tiene que almacenar y mantener a salvo una o muchas copias de su estado interno, sus responsabilidades crecerían y serían más complejas, se desviaría de su propósito disminuyendo la coherencia. Usar Mementos hace que Originator sea mucho más sencillo y coherente.
3. Uso frecuente de Mementos para almacenar estados internos de gran tamaño, podría resultar costoso y perjudicar el rendimiento del sistema.
4. Definiendo interfaces. Esto puede ser difícil en algunos lenguajes ya que sólo originator puede acceder al estado de memento.
5. Altos costos en mantener momentos. Caretaker al no conocer detalles del estado interno de Originator, no tiene idea de cuánto espacio y tiempo se necesita para almacenar el estado interno de Originator en un Memento y restaurar su estado interno a partir de un Memento. Por lo que no puede hacer predicciones de tiempo ni de espacio.

Implementación
Hay dos cuestione que debemos tener en cuenta al implementar el patrón Memento:

1. Soporte del lenguaje. Para implementar este patrón, debemos considerar que el Memento debe proporcionar una interfaz accesible sólo por Originator, en la mayoría de los lenguajes de programación, esta figura no es posible, sin embargo en C++ se puede hacer que Originator sea una clase amiga de Memento.
2. Almacenando cambio incrementales. Cuando mementos son creados y pasan a través del origen (originator) con una secuencia predecible, el Memento puede guardar los cambios incrementalmente en el estado interno del origen.

Usos Conocidos
El Patrón de Diseño Memento se utiliza para situaciones donde se requiera una operación de restauración “UNDO”, como en los graficadores y procesadores de texto.

Patrones relacionados
Command: Puede usar “Mementos” para guardar el estado de operaciones restaurables.
Iterator: “Mementos” puede ser usado con Iterator para buscar colecciones para estados específicos.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.ldc.usb.ve/~mgoncalves/IS2/sd07/grupo3.pdf
http://kybele.escet.urjc.es/documentos/SI/Patrones/15_MEMENTO.ppt
http://www.freewebz.com/amanecer/personal/papers/paper.memento.pdf

Mediator

Nombre del patrón
Mediator

Clasificación del patrón
De Comportamiento

Intención
Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.

Motivación
Cuando muchos objetos interactúan 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 demás objetos. Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.
Los objetos envían y reciben peticiones a través del mediador, este patrón implementa el comportamiento cooperativo encaminando esas peticiones a los objetos apropiados.

Aplicabilidad
Utilizaremos el patrón Mediator cuando:

• Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja.
• Dificultad para reutilizar objetos ya que nos referimos a varios objetos para comunicarnos.
• El comportamiento de muchos objetos que esta distribuido entre varias clases, puede resumirse en una o varias por subclasificación.

Estructura

Participantes
Mediator: define una interface para comunicarse con los objetos colegas.
ConcreteMediator: Implementa el comportamiento cooperativo entre los colegas (como se comunican entre ellos). Además los conoce y mantiene.
Colleagues classes: Cada colega conoce su mediador, y usa a este para comunicarse con otros colegas.

Colaboraciones
Los objetos (Colegas) envían y reciben requerimientos (requests) de un objeto mediador. El mediador implementa como se comunican los objetos.

Consecuencias
Ventajas e inconvenientes del patrón Mediator:

• Reduce herencia. Con una subclase llamada Mediador cambiamos el comportamiento, que de otra manera estaría distribuido en varios objetos.
• Desacopla a los objetos. El patrón Mediator promueve bajar el acoplamiento entre objetos. Se puede variar y rehusar objetos y mediadores independientemente.
• Simplifica la comunicación 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 más elegante. Además esta forma de comunicación es más fácil de entender.
  Abstrae como los objetos cooperan. Haciendo a la mediación un concepto independiente y encapsulándolo en un objeto permite enfocar como los objetos interactúan. 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 objetos, este puede ser muy complejo, difícil de entender y modificar.

Implementación
Es importante tener en cuenta en la implementación de este patrón:

• Omitir la clase abstracta Mediator. No es necesario crear una clase abstracta Mediador cuando los objetos solo trabajan con un mediador. El acoplamiento abstracto de dicha clase permite que los objetos trabajen con diferentes subclases Mediator y viceversa.
• Comunicación Objeto y Mediador. Los objetos se comunican su mediador cuanto tiene lugar un evento. Las clases de objetos cada vez que cambian su estado envían notificaciones al mediador. El mediador responde propagando los efectos de dichos eventos a los otros objetos.
  Otra forma define al Mediador una interfaz de notificación especializada que permite a los objetos ser más directos en su comunicación.

Usos Conocidos
El Mediator es comúnmente usado en el desarrollo de aplicaciones que poseen varios componentes dentro de las interfaces gráficas que poseen.
También aparece otra aplicación en el framework de dibujo Unidraw

Patrones relacionados
Un patrón muy parecido a éste es el Facade que se diferencia en que abstrae un sistema de objetos proporcionado una interfaz más conveniente, utilizando un protocolo unidireccional (Fachada realiza solo peticiones a las clases del subsistema pero no a la inversa), mientras que el Mediator usa un protocolo multidireccional.
Con el patrón Observer los objetos pueden comunicarse con el mediador.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://dc.exa.unrc.edu.ar/nuevodc/materias/sistemas/2007/Patrones/1181918751/MediatorRes2.pdf
http://kybele.escet.urjc.es/documentos/SI/Patrones/14_Mediator.ppt

Iterator

Nombre del patrón
Iterator

Clasificación del patrón
De Comportamiento

Intención
Proveer una forma de tener acceso secuencial a los elementos de un objeto agregado sin tener que exponer su representación interna.

También conocido como
Cursor

Motivación
Un objeto agregado, tal como una lista, debería proveer un modo de brindar acceso a sus elementos sin exponer su estructura interna. Más aún, quizás se desea recorrer la lista en diferentes formas, dependiendo de lo que Ud. quiera realizar. Pero, probablemente, la idea no es aumentar la interfaz de la lista con operaciones para recorridos diferentes, aún anticipando los que se necesitarán. Tal vez, también se necesite tener más de un recorrido en la misma lista.
El patrón Iterator permite llenar todas estas expectativas. La idea principal en este patrón es tomar la responsabilidad del acceso y recorrido de la lista y colocarla dentro del objeto iterator. La clase Iterator define una interfaz para el acceso de los elementos de la lista. Un objeto iterador es responsable de mantener la pista del elemento actual; esto es, sabe cuáles elementos ya han sido recorridos.

Aplicabilidad
Usamos el patrón Iterator:

• Para tener acceso a los contenidos de un objeto agregado sin tener que exponer su estructura interna.
• Para soportar múltiples recorridos de objetos agregados.
• Para proveer una interfaz uniforme para recorridos en estructuras diferentes de agregados (esto es, para soportar iteración polimorfa).

Estructura

Participantes
Iterator: el cual define una interfaz para el acceso y recorrido de los elementos.
ConcreteIterator: el cual implementa la interfaz de Iterator y mantiene la pista de la posición actual en el recorrido del agregado.
Aggregate: el cual define una interfaz para la creación de un objeto Iterator.
ConcreteAggregate: el cual implementa la interfaz de creación de Iterator para retornar una instancia del ConcreteIterator adecuado.

Colaboraciones
Un ConcreteIterator mantiene la pista de cuál es el objeto actual en el agregado y puede calcular el objeto siguiente en el recorrido.

Consecuencias
Este patrón tiene tres consecuencias importantes:

1. Soporte a variaciones en el recorrido de un agregado, puesto que agregados complejos pueden requerir recorridos en muchas formas. Los iteradores hacen fácil cambiar el algoritmo de recorrido, con sólo reemplazar la instancia del iterador a una diferente.
2. Los iteradores simplifican la interfaz de los agregados, ya que la interfaz de los recorridos se encuentra en los iteradores y no en los agregados.
3. Más de un recorrido puede estar pendiente en un agregado, puesto que cada iterador mantiene la pista de su recorrido. Por lo tanto, se puede tener más de un recorrido en progreso al tiempo.

Implementación

Los iteradores tienen muchas variantes en la implementación y alternativas. Algunas de las más importantes son las siguientes. Las ventajas dependen de las estructuras de control que el lenguaje provea.

• ¿Quién controla la iteración?. Referido a iteración interna (controlada por el iterador), o iteración externa (controlada por el cliente).
• ¿Quién define el algoritmo de recorrido?. Referido a si lo define el agregado, con lo cual el iterador es utilizado sólo como cursor de la posición actual; o si lo define el iterador.
• ¿Cuán robusto es el iterador?. Referido a la manera en que se aseguran las iteraciones cuándo se ha realizado un cambio (inserción y/o eliminación) en el objeto agregado.
• Operaciones adicionales en el iterador. Referido a la adición de operaciones a las ya básicas (First, Next, IsDone y CurrentItem).
• Utilización de iteradores polimorfos en C++.
• Iteradores con acceso privilegiado. Referido a que un iterador puede ser visto como una extensión (friend) del agregado que lo creó.
• Iteradores para compuestos (Composite).
• Iteradores nulos. Referido a un iterador útil para el manejo de condiciones de frontera.

Usos Conocidos
Los Iteradores son comunes en sistemas orientados a objetos (Smalltalk, ET++, ObjectWindows, etc.), de hecho, la mayoría de librerías de clases ofrecen iteradores en una forma u otra.
En general, los iteradores se ofrecen junto con las estructuras de datos básicas: Listas, Colas, Pilas, etc.

Patrones relacionados

• Iteradores se aplican a menudo en estructuras recursivas como Composites.
• Iteradores poliformicos se basan en Factory Menthods para instanciar la subclase Iterator apropiada.
• Memento se utiliza a menudo en colaboración con el patrón Iterator. Un Iterator puede unas un Memento para capturar el estado de una iteración.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/13_Iterator.ppt
http://sistemas.unitecnologica.edu.co/ebooks/Programacion/Java/Documentos/Java%205%20Certifications/Programing/API/Iterator.pdf
http://agamenon.uniandes.edu.co/~pfiguero/soo/PatronesDiseno/Iterator/Iterator.html

Interpreter

Nombre del patrón
Interpreter

Clasificación del patrón
Comportamental

Intención
Dado un lenguaje, define una representación para esta gramática junto con un intérprete que utiliza la representación para interpretar sentencias en el lenguaje.

Motivación
A veces es conveniente representar un problema como palabras de algún lenguaje sencillo, como por ejemplo, evaluar expresiones booleanas. El patrón interpreter describe como definir una gramática, representar palabras del lenguaje y cómo interpretarlas, se utiliza una clase para representar cada regla de la gramática.

Aplicabilidad
El uso de este patrón es indicado cuando hay un lenguaje que interpretar y se pueden representar sus palabras como arboles sintácticos abstractos, funciona mejor si:

• La gramática es simple. Para gramáticas complejas la jerarquía de clases se vuelve inmanejable.
• La eficiencia no es importante. Los intérpretes más eficientes no se consiguen interpretando arboles; normalmente se hace con maquinas de estados.

Estructura

Participantes
AbstractExpression Declara una operación abstracta Interpret que es común a todos los nodos en el árbol de sintaxis abstracto.
TerminalExpresion

• Implementa una operación Interpret asociada con símbolos terminales en la gramática.
• Una instancia es requerida para todo símbolo terminal en una sentencia.

NonterminalExpression

• Una de estas clases es requerida para toda regla R::R1 R2…..Rn en la gramática.
• Mantiene instancias variables del tipo AbstractExpression para cada uno de los símbolos de R1 a Rn.

Context

• Contiene información que es global al intérprete.

Cliente

• Se basa (o se da) una sintaxis abstracta que representa un árbol en el idioma en que se define la gramática.
• Invoca la operación de Intérprete.

Colaboraciones

• El cliente construye las sentencias es un árbol de sintaxis abstracto de NonterminalExpression e instancias de TerminalExpression. Luego el cliente inicializa el contexto e invoca el intérprete de la operación.
• Cada nodo NonterminalExpression define un intérprete en términos de cada subexpresión. La operación del intérprete de cada TerminalExpression define el caso recursivamente.
• Las operaciones del intérprete para cada nodo usan el contexto para crear y acceder el estado del intérprete.

Consecuencias
El patrón Interpreter tienes los siguientes beneficios y desventajas:

1. Hace fácil el cambiar y extender la gramática. Porque el patrón usa clases que representan reglas gramaticales, podemos usar herencia para cambiar o extender la gramática.
2. Implementar la gramática también es fácil. La definición de clases en nodos del l árbol abstracto de sintaxis tienen implementaciones similares.
3. Gramáticas complejas son difíciles de mantener. El patrón Interpreter define al menos una clase para toda regla en la gramática. Por lo tanto gramáticas que tienen muchas reglas son difíciles de manejar y mantener.
4. Adicionar nuevas formas de interpretar expresiones. El patrón Intérprete hace fácil el evaluar una expresión de una forma nueva.

Implementación
Los patrones Interpreter y Composite comparten muchos de los problemas en la implementación. Los siguientes problemas son específicos de Interpreter.

1. Creando el árbol de sintaxis abstracto. EL patrón Interpreter no explica cómo crear el árbol abstracto de sintaxis, no explica cómo hacer parsing.
2. Definiendo las operaciones de Interpreter. No hay que definir la operación Interpreter en cada clase de expresión. Si un lenguaje tiene varias interpretaciones, es mejor colocarlos en instancias del patrón Visitor.
3. Compartir símbolos terminales con el patrón Flyweight. Las gramáticas con un gran número de símbolos terminales pueden beneficiarse compartiendo una copia única de cada símbolo terminal con el patrón Flyweight.

Usos Conocidos
Este patrón se utiliza ampliamente en compiladores implementados con lenguajes orientados a objetos.

Patrones relacionados

• El árbol de sintaxis abstracto es una instancia del patrón Composite.
• Flyweight muestra como compartir símbolos terminales en el árbol.
• Se puede usar un Iterator para recorrer el árbol.
• Se puede implementar Visitor para mantener el comportamiento de cada nodo en una clase aparte.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.ldc.usb.ve/~mgoncalves/IS2/sd07/grupo6.pdf
http://kybele.escet.urjc.es/documentos/SI/Patrones/12_Interpreter.pdf

Command

Nombre del patrón
Command

Clasificación del patrón
Comportamental

Intención
Encapsula una petición como un objeto, lo que permite parametrizar los clientes con distintas peticiones, dejar en cola o registrar solicitudes, y soporta operaciones de deshacer.

También conocido como
Action, Transaction.

Motivación
Las herramientas del patrón Command permiten que objetos hagan peticiones de objetos con aplicaciones sin especificar, envolviendo la solicitud en un objeto. Este objeto puede ser almacenado y pasado al igual que otros objetos de alrededor. La clave de este patrón es una clase abstracta Command, que declara una interfaz para la ejecución de operaciones. En la forma más simple esta interfaz incluye un resumen de las operaciones ejecutadas.
El patrón Command lo que permite es desacoplar al objeto que invoca a la operación de aquél que tiene el conocimiento necesario para realizarla

Aplicabilidad
Utilizamos el patrón Command cuando queremos:

• Parametrizar objetos para llevar a cabo acciones, sobretodo objetos MenuItem.
• Especificar, encolar, y ejecutar llamadas en diferentes momentos. Un objeto Comando puede tener una línea de vida independiente de la llamada original. Si el receptor del llamado puede ser representado como una dirección de espacio independiente, luego se puede transferir el objeto Comando para el llamado a un proceso diferente y realizar el llamado ahí.
• Soporte deshacer. La operación ejecutarComando( ) puede almacenar estados para revertir efectos en el propio comando. La interfaz debe tener una operación adicional (unExecute) que reversa el efecto de una llamada previa a ejecutar. Los comandos ejecutados están almacenados en una lista de historial.
• Soportar cambios en registro en las que se pueden reaplicar en caso de que el sistema colapse. Para agregar operaciones de cargar y guardar en la interfaz comando, se debe mantener un registro permanente de cambios. Recuperarse de un colapso requiere recargar los comandos de registro del disco y reejecutarlos con la operación ejecutar.
• Estructurar un sistema alrededor de operaciones de alto nivel construidas sobre operaciones primitivas ya que una estructura es común en los sistemas de información que soportan transacciones.

Estructura

Participantes
Command. Declara una interfaz para ejecutar una operación
ConcreteCommand. Define una relación entre un objeto Receivor y una acción. Implementa Execute() para invocar la respectiva acción en Receivor.
Client. Crea los objetos ConcreteCommand y su Receiver.
Invoker. Pregunta el comando para llevar a cabo la solicitud.
Receiver. Es la encargada de realizar operaciones asociadas con las peticiones de Execute(). Cualquier clase puede ser Receiver.

Colaboraciones

• El cliente crea un objeto ConcreteCommand y especifica su receptor.
• Un objeto Invoker guarda el objeto ConcreteCommand.
• El Invoker llama a Execute() en Command el cual esta implementado en ConcreteCommand.
• El objeto ConcreteCommand llama a las acciones pertinentes sobre su Receiver.
  

Consecuencias

• Command desacopla el objeto que invoca la operación que sabe cómo resolver.
• Command es la primera clase de objetos. Puede ser manipulada o extendida como cualquier otro objeto.
• Se puede ensamblar Command en un Composite Command (comando Compuesto).
• Es fácil adicionar nuevos Commands, porque no se tienen que cambiar las clases existentes.

Implementación
A la hora de implementar el patrón Command se debe tener en cuenta:

• ¿Qué tan inteligente debe ser un comando? Un comando puede tener una amplia gama de habilidades. En un extremo este se limita a definir un compromiso que vincula un receptor y las acciones que llevan a cabo la petición.
• Soporte de deshacer y rehacer. Command puede soportar deshacer y rehacer, si se dispone de una opción para revertir su ejecución. Una clase ConcreteCommand puede que necesite construir un estado adicional para haces esto.
• Evitar la acumulación de errores en el proceso de deshacer. En la medida en que se hacen y deshacen operaciones es posible que el estado al que se llega diverga del estado original de los objetos. Es necesario que el ConcreteCommand contenga suficiente información para que sea capaz de hacer que los objetos vuelvan al estado original.
• En C++ se pueden usar plantillas para representar Commands que no requieren argumentos ni se pueden deshacer

Usos Conocidos
Las clases Button y MenuItem de Java:

• Facilitan la utilización de este patrón.
• Declaran los métodos getActionCommand y setActionCommand para dar nombres a las acciones realizadas por los objetos.
• Facilitan una correspondencia entre ambos.

Patrones relacionados

• Un Composite puede ser usado en la implementación de MacroCommands.
• Un Memento puede mantener el estado que requiere Command para deshaces sus efectos.
• Un Command que debe ser copiado antes de ser puesto en el historial de una lista actúa como un Prototype.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/06_Command.ppt
http://www.cesaracebal.com/docencia/asignaturas/aaswiki/_media/command.pdf?id=teoria&cache=cache
http://eisc.univalle.edu.co/materias/Material_Desarrollo_Software/ExpoCommDarTatXim.pdf
http://gaia.fdi.ucm.es/people/pedro/das03/19command.pdf
http://agamenon.uniandes.edu.co/~pfiguero/soo/PatronesDiseno/Command/Command.htm

Chain of Responsibility

Nombre del patrón
Chain of Responsibility (Cadena de Responsabilidades)

Clasificación del patrón
Comportamental.

Intención
Evita acoplar el emisor de una petición con el receptor, dando a más de un objeto la posibilidad de responder a la petición. Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto

Motivación
La idea del patrón es desacoplar a los emisores de los receptores, dándole a varios objetos la posibilidad de tratar una petición. La petición se pasa por una cadena de objetos hasta que uno de ellos la procesa.
EL primer objeto en la cadena recibe la solicitud y, o se ocupa de ella o la envía al siguiente candidato de la cadena, que hace lo mismo. El objeto que hace la solicitud no tiene conocimiento explicito de quien se hará cargo de esta, se dice que la petición tiene un receptor implícito.
Pretendemos dar un mayor detalle y especificación a las peticiones generadas. Las peticiones serán filtradas por todos los receptores a medida que se van generando los resultados esperados.

Aplicabilidad
Usamos Cadena de responsabilidades cuando:

• Hay más de un objeto que pueden manejar una petición y esa petición no se conoce a priori, sino que se debe de determinar automáticamente.
• Se quiere enviar una petición a un objeto entre varios sin especificar explícitamente el receptor.
• El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente.

Estructura

Participantes
Handler
- Define una interfaz para tratar las peticiones.
- Implementa el enlace al sucesor (opcional).
ConcreteHandler
- Trata las peticiones de las que es responsable
- Puede acceder a su sucesor
- Si el ConcreteHandler puede manejar la petición, lo hace, en caso contrario la reenvía a su sucesor.
Client
- Inicializa la petición a un objeto ConcreteHandler de la cadena

Colaboraciones
Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un objeto ConcreteHandler se hace responsable de procesarla.

Consecuencias
Cadena de Responsabilidades tienes los siguientes beneficios e inconvenientes:

1. Reduce el acoplamiento. Ni el receptor ni el emisor se conocen explícitamente. Un objeto sólo tiene que saber que una petición será manejada.
2. Adiciona flexibilidad en la asignación de responsabilidades a objetos. Las responsabilidades de los mensajes pueden cambiar mediante la organización del proceso de ejecución.
3. No se garantiza la recepción. Puesto que no existe un receptor específico para los mensajes, éstos pueden quedarse sin procesar.

Implementación
Debemos tener en cuenta al implementar este patrón:

1. Implementar el sucesor en la cadena. Existen dos posibilidades: Definir un nuevo sucesor, usar un sucesor existente.
2. Conexión de los sucesores. Los propios ConcreteHandler serán los que se encargarán de reenviar la petición de forma incondicional. Las referencias deberán estar definidas.
3. Representación de las peticiones. Uso de paso de parámetros o variables mediante una función manejadora, o hacer uso de clases.

Usos Conocidos

• Varias bibliotecas de clases usan este patrón para manejar los eventos de usuario. Aunque usan nombres distintos, la idea es siempre la misma: cuando el usuario hace clic con el ratón o pulsa una tecla, se genera un evento y se pasa a lo largo de la cadena.
• El framework de editores gráficos Unidraw define objetos que encapsulan peticiones a los objetos Component y ComponentView. Estos objetos se estructuran jerárquicamente, así pueden reenviar interpretaciones de órdenes a su padre, quien a su vez puede reenviarlas, formando una cadena de responsabilidad.
• ET++ usa una cadena de responsabilidad para tratar la actualización de gráficos. Un objeto gráfico llama a una operación cada vez que quiere actualizarse, pero el objeto no sabe lo suficiente sobre su contexto, por lo tanto la operación debe reenviar la petición.

Patrones relacionados
El patrón Cadena de Responsabilidad se suele aplicar junto con el patrón Composite. En él, los padres de los componentes pueden actuar como sucesores.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/05_Chain.ppt
http://dmi.uib.es/~yuhua/APOO07-08/Presentation/ChRespons.pdf

PATRONES COMPORTAMENTALES

Los patrones de comportamiento están relacionados con los algoritmos y la asignación de responsabilidades entre los objetos. Los patrones de comportamiento no sólo describen patrones de objetos o de clases, sino también patrones de comunicación entre ellos. Estos patrones se caracterizan por controlar el flujo (de comunicación), que es difícil de seguir en tiempo de ejecución. El centrar la atención en el control del flujo permite concentrarse sólo en la forma en que los objetos están interconectados.

Proxy

Nombre del patrón
Proxy

Clasificación del patrón
Estructural

Intención
Proporcionar un sustituto o marcador de posición de otro objeto pata controlar el acceso a éste.

También conocido como:
Surrogate (sustituto)
Virtual Proxy

Motivación
Una de las razones para controlar el acceso a un objeto es aplazar el costo total de su creación e inicializarlo hasta que realmente se necesita para usarlo. La solución es usar otro objeto, una imagen proxy, que actúa como un sustituto de la imagen real. El proxy actúa como la imagen y se encarga de instanciarla cuando esta es requerida.
Aplicabilidad
Proxy es aplicable cuando existe la necesidad de hacer una referencia más versátil y sofisticada a un objeto que con u simple puntero. Aquí hay varias situaciones en donde el patrón Proxy es aplicable:
1. Un proxy remoto proporciona un representante local de un objeto en un espacio de diferentes direcciones.
2. Un Proxy virtual posterga la creación de objetos costosos hasta el momento en que se necesitan.
3. Un Proxy de protección que controla el acceso al objeto original, son útiles cuando los objetos tienen diferentes permisos de acceso.
4. Referencias inteligentes, remplazan a una referencia o puntero para realizar alguna acción adicional:

- Contar el número de referencias a un objeto para liberarlo cuando nadie lo usa
- Cargar un objeto persistente en memoria cuando se referencia por primera vez
- Sincronizar el acceso a un objeto con un cerrojo

Estructura

Participantes
Proxy

• Mantiene una referencia que permite al proxy acceder al sujeto real. Proxy puede hacer referencia a Subject si la interfaz de RealSubject y Subject es la misma.
• Proporciona una interfaz idéntica a los Subject`s que el proxy puede sustituir por sujetos reales.
• Controla el acceso al sujeto real y puede ser responsable de crear y borrar el mismo.
  Otras funciones dependen del tipo de proxy
• Proxy remotos son responsables de la codificación de un requerimiento y sus argumentos y la codificación para la solicitud del sujeto real en un espacio de diferentes direcciones.
• Proxy virtuales pueden almacenar en cache información adicional acerca de los sujetos reales de modo que puede acceder a posponer estos.
• Proxy de protección verifica que la persona que llama tenga los permisos de acceso necesarios para realizar una solicitud.

Subject
Define la interfaz común para RealSubject y Proxy, para que un proxy pueda ser usado en cualquier RealSubject que espere.
RealSubject
Define el objeto real que el proxy representa.

Colaboraciones
El proxy envía solicitudes a RealSubject cuando sea apropiado.

Consecuencias
El patrón proxy introduce un nivel de indirección (redirección) al acceder a un objeto. El adicionar inderección tiene muchos usos, dependiendo el tipo de proxy.
1. Un proxy remoto puede ocultar el hecho que un objeto se encuentra en un espacio diferente de direcciones.
2. Un proxy virtual puede realizar optimizaciones como la creación de un objeto por solicitud.
3. Proxy de protección y referencias elegantes permiten el acceso más limpio a un objeto.

Implementación
Un Proxy no tiene que conocer el tipo de un sujeto real.

• Puede acceder a él a través de la interfaz abstracta

Se pueden utilizar facilidades de los lenguajes para implementarlo:

• En C++ se puede sobrecargar el operador de acceso a un miembro (->). Así cuando se accede a un miembro se pueden hacer acciones adicionales » Esto es válido sólo cuando no es necesario distinguir el tipo de operación que se accede en el objeto

Usos Conocidos
Ocultar y codificar direccionamiento
Proteger objetos verificando permisos de acceso

Patrones relacionados
El patrón Proxy se puede ver como un caso particular de Bridge:

• Un Proxy sólo tiene una implementación, y un Bridge puede tener más de una.
• Un Proxy se suele usar para controlar el acceso a su implementación, el Bridge permite cambiar una implementación dinámicamente

El Adaptader proporciona una interfaz diferente al objeto que adapta, pero el proxy tiene la misma interfaz. Aunque el proxy puede rehusar realizar una operación (así su interfaz puede verse como un subconjunto)
El Decorator se puede implementar de manera similar al Proxy pero el propósito es diferente: el decorador añade responsabilidades a un objeto, el proxy sólo controla su acceso

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/18_Proxy.ppt
http://grasia.fdi.ucm.es/jpavon/patrones/patronesestructurales.pdf

Flyweight

Nombre del patrón
Flyweight o Peso ligero

Clasificación del patrón
Estructural

Intención
Permite gestionar eficientemente un gran número de objetos pequeños compartiendo objetos más generales. Comparte el apoyo a un gran número de objetos de grano fino de manera eficiente.

Motivación
El patrón flyweight describe como almacenar un gran número de objetos sin un gran coste.
Para conseguir esto se utilizan objetos que almacenan los estados compartidos y que pueden ser usados por varios objetos simultáneamente.
Un flyweight es un objeto compartido que se puede utilizar en varios contextos al mismo tiempo. El flyweight actúa como un objeto independiente en cada contexto. Es indistinguible para una instancia del objeto que no es compartida. Flyweight no puede hacer suposiciones sobre el contexto en el que lo operan. El concepto clave aquí es distinguen entre estado intrínseco y extrínseco. El estado intrínseco es almacenado en flyweight; y consiste en información que es independiente del contexto de flyweight, haciendo esto compartible. El estado extrínseco depende y varía con el contexto de flyweight, y por tanto no puede ser compartido. Los objetos del cliente son responsables del paso a estado extrínseco de flyweight cuando este lo necesita.

Aplicabilidad
La eficacia del patrón Flyweight depende en gran medida de cómo y dónde se utiliza. Aplicamos el patrón Flyweight cuando:

• Una aplicación usa un gran número de objetos
• Los costos de almacenamiento son altos debido al gran número de objetos
• La mayoría de objetos pueden hacerse en estado extrínseco.
• Muchos grupos de objetos se pueden sustituir por un número reducido de objetos compartidos, una vez que se elimina el estado extrínseco.
• La aplicación no depende de la identidad de los objetos.

Estructura Participantes

Flyweight. Declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados no compartidos.
ConcreteFlyweight. Implementa la interfaz Flyweight y almacena los estados compartidos, si los hay. Un objeto ConcreteFlyweight debe ser compartible. Cualquier estado que almacene debe ser intrínseco; es decir, debe ser independiente de su contexto.
UnsharedConcreteFlyweight. No todas las subclases de Flyweight tienen por qué ser compartidas. La interfaz Flyweight permite que se comparta; no lo fuerza. Es común que los objetos de esta clase tengan hijos de la clase ConcreteFlyweight en algún nivel de su estructura.

FlyweightFactory

• Crea y gestiona los objetos flyweight.
• Garantiza que los objetos flyweight se comparten de forma apropiada. Cuando un cliente solicita un flyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente, o crea una.

Client

• Contiene referencias a los flyweights.
• Calcula o almacena los estados no compartidos de los flyweights.

Colaboraciones

• Un objeto flyweight debe ser clasificado como compartido o no compartido. Los compartidos se almacenan en el objeto ConcreteFlyweight; los no compartidos se almacenan o se calculan en el objeto Cliente. Los clientes pasan este estado al objeto flyweight cuando invocan sus operaciones.
• Los clientes no deberían instanciar objetos de la clase ConcreteFlyweight directamente. Deben obtenerlos exclusivamente del objeto FlyweightFactory para garantizar que son compartidos apropiadamente.

Consecuencias
Flyweights puede introducir costrón en tiempo de ejecución asociados con transferencia, búsqueda y/o estados extrínsecos del computador, en especial si se almacenan anteriormente como estados intrínsecos. Sin embargo, estos costos se compensan con el ahorro de espacio, que aumenta a medida que se comparten más flyweights
El ahorro de almacenamiento está en función de varios factores:

• La reducción en el número total de instancias.
• La cantidad de estados intrínsecos por objeto.
• Si el estado extrínseco es computado o almacenado.

Cuanto más se comparte flyweights, mayor es el ahorro de almacenamiento. Los ahorros aumentan con la cantidad de estados compartidos.
El patrón flyweight es combinado con el patrón Composite.

Implementación
Consideremos las siguientes cuestiones al aplicar el patrón flyweight:

• Removiendo estado extrínsecos. La aplicabilidad del patrón determina en gran medida por lo fácil que es identificar y eliminar estados extrínsecos de objetos compartidos.
• Manejando objetos compartidos. Porque los objetos son compartidos, los clientes no deben instanciar directamente. FlyweightFactory permite a los clientes localizar un flyweight particular.

Usos Conocidos
EL concepto de objetos flyweight fue descrito por primera vez y explorado como una técnica de diseño en InterViews 3.0.

Patrones relacionados
EL patrón flyweight es a menudo combinado con Composite para aplicar una modelo de estructura jerárquica, en términos de un grafo aciclico dirigido compartiendo los nodos hoja.
A menudo es mejor implementar State y Strategy con objetos flyweight.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://kybele.escet.urjc.es/documentos/SI/Patrones/11_FlyWeight.ppt
http://www.ayc.unavarra.es/miguel.pagola/PesoLigero.pdf
http://gaia.fdi.ucm.es/people/pedro/das02/23flyweight.pdf

Facade

Nombre del patrón
Facade o Fachada

Clasificación del patrón
Estructural

Intención
Proporciona una interfaz unificada a un conjunto de interfaces en un subsistema. Define una interfaz de alto nivel que hace al subsistema más fácil de usar.

Motivación
Estructurar un sistema en subsistemas ayuda a reducir la complejidad. Un objetivo común en el diseño es minimizar la comunicación y dependencias entre los subsistemas. Una forma de lograr este objetivo es introducir un objeto fachada que proporciona una interfaz única y simplificada.

Aplicabilidad
Usamos el patrón Facade cuando:

• Se quiere proveer una interfaz simple a un subsistema complejo.
• Hay muchas dependencias entre los clientes y las clases del subsistema.
• Se quiere crear una capa sobre el subsistema que defina un punto de entrada para cada nivel de subsistema.

Estructura

Participantes
Facade

• Sabe que clases del subsistema son responsables de un requerimiento u solicitud.
• Delega los requerimientos del cliente a los objetos apropiados del subsistema.

Subsystem clases

• Implementa funcionalidades del subsistema.
• Maneja el trabajo asignado por el objeto Facade.
• No tiene conocimiento de la fachada, no mantiene las referencias a esta.

Colaboraciones

• Los clientes se comunican con el subsistema mediante en envió de peticiones a la fachada, que las reenvía al subsistema apropiado. A pesar que los objetos del subsistema realizan en realidad el trabajo, la fachada tiene que hace su propio trabajo de traducir su interfaz a las interfaces del subsistema.
• Los clientes que usan la fachada no tiene acceso a los objetos del subsistema directamente.

Consecuencias
El patrón Facade ofrece los siguientes beneficios:

• Aísla a los clientes de los componentes del subsistema, lo cual reduce el número de componentes que el cliente utiliza.
• Promueve un acoplamiento débil entre el subsistema y los clientes.
• No impide que las aplicaciones utilicen las clases del subsistema.

Implementación
Consideramos los siguientes aspectos en la aplicación de Facade.

• La reducción de acoplamiento cliente-subsistema. El acoplamiento entre los clientes y el subsistema puede reducirse aun mas al hacer una clase abstracta Fachada con subclases concretas para las distintas aplicaciones de un subsistema.
• Subsistemas de clases públicos o privados. Un subsistema es análogo a una clase en la que ambos tiene interfaces y ambos encapsulan algo, una clase encapsula el estado las operaciones, mientras que in subsistema encapsula clases. Y del mismo modo que es útil pensar en partes públicas y privadas en la interfaz de una clase, podemos pensar en los elementos públicos y privados de la interfaz de un subsistema.
  La interfaz publica de un subsistemas se compone de las clases que todos los clientes pueden acceder, la interfaz privada es sólo para extender subsistemas.

Usos Conocidos
El patrón Facade es común en numerosas librerías de software, tanto comerciales como libres y su utilización está más o menos bastante generalizada en gran parte de las librerías software.
Algunos ejemplos concretos son las clases Font y Graphics de las librerías estándar de Java que proporcionan la funcionalidad básica para manipulación de fuentes y gráficos aislando al usuario, en las operaciones más comunes, de la complejidad subyacente. Otros ejemplos incluyen determinados interfaces de librerías GIS o librerías matemáticas.

Patrones relacionados

• Abstract Factory puede ser usado con Facade para proporcionar una interfaz para crear objetos del subsistema en una forma de subsistema independiente.
• Mediator Es similar a Facade, ambos abstraen la funcionalidad de las clases, Mediator abstrae arbitrariamente la comunicación entre los objetos colegas, los objetos colegas están enterados de esto y se comunican con el Mediator y no directamente entre ellos. El patrón Facade solamente abstrae la interfaz a los objetos del subsistema para facilitar su uso, los objetos del subsistema no saben de la existencia del patrón Facade, además este no define nuevas funcionalidades.
• Por lo general sólo un objeto fachada es obligatoria. Así los objetos Facade son Singleton.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF.
http://www.slideshare.net/jlrvpuma/facade-design-pattern-gof?src=related_normal&rel=1380529
http://www.stackframe.net/es/content/11-2008/patrones-de-diseno-facade-pattern

Decorator

Nombre del patrón
Decorator

Clasificación del patrón
Estructural

Intención
Fijar responsabilidades adicionales a un objeto dinámicamente. Decorator ofrece una alternativa flexible de herencia para extender funcionalidades.

También conocido como:
Wrapper o envolvente.

Motivación
A veces queremos añadir responsabilidades a objetos individuales y no a toda la clase. Una interfaz grafica de usuario toolkit, por ejemplo, en donde se le permite añadir características como los bordes o comportamientos como el desplazamiento de cualquier componente de la interfaz del usuario.
Una forma de añadir responsabilidades es con herencia. Heredar un borde a otra clase pone un borde alrededor de cada subclase instanciada. Esto es inflexible, porque la elección del borde se hace estáticamente. Un cliente no puede controlar cómo y cuando se decora un componente del borde.
Un enfoque más flexible es incluir el componente en otro objeto que se adiciona al borde. El objeto adjuntado se llama decorador, El decorados se ajusta a la interfaz del componente que decora de modo que su presencia es transparente para el cliente de los componentes.

Aplicabilidad
Usamos decorador para:

• Adicionar responsabilidades a objetos individuales dinámicamente sin afectar otros objetos.
• Agregar responsabilidades que pueden ser retiradas.
• Cuando no es práctico adicionar responsabilidades por medio de la herencia.

Estructura

Participantes

• Component define la interfaz para los objetos que pueden tener las responsabilidades que se les añade dinámicamente.
• ConcreteComponent define un objeto al que se le pueden añadir responsabilidades.
• Decorator almacena una referencia a un objeto Component y define una interfaz que se ajusta a la de Component.
• ConcreteDecorator añade responsabilidades al componente.

Colaboraciones
Decorator envía las solicitudes al objeto Component. Opcionalmente puede realizar operaciones adicionales antes y después del envió de la solicitud.

Consecuencias

1. Más flexibilidad que la herencia estática. El patrón Decorator proporciona una forma más flexible para añadir responsabilidades a los objetos que puede hacerse con herencia estática (múltiple). Con decoradores, las responsabilidades se pueden añadir y quitar en tiempo de ejecución simplemente conectando y desconectando estos.
2. Evita sobrecargar las partes altas de una jerarquía de clases con funcionalidades potencialmente innecesarias.
3. En decorador y sus componentes no son idénticos. Un decorador actúa como una caja transparente, no debería confiarse de la identidad del objeto cuando se utiliza decoradores.
4. Grupos de pequeños objetos. Un uso extensivo del patrón Decorator produce código más difícil de entender y depurar, al crear sistemas compuestos de grupos de pequeños objetos.

Implementación
Para aplicar el patrón Decorator debemos tener en cuenta:

1. Conformación de interfaces. Un decorador de objetos de la interfaz deben ajustarse a la interfaz del componente que decora.
2. Omitiendo la clase abstracta Decorator. No hay necesidad de definir una clase abstracta Decorator cuando solo se tenga que añadir una responsabilidad.
3. Mantener clases Componen ligeras. Para garantizar un ajuste de interfaz, componentes y decoradores deben descender de una clase común de componentes.
4. Cambiando la máscara de un objeto vs a cambiar su interior. Podemos pensar en un decorador como una máscara de un objeto, más que en algo que cambie su comportamiento. EL patrón Strategy es un buen ejemplo para cambiar el interior.

Usos Conocidos
Muchas de las interfaces de usuarios orientadas toolkits (herramientas) usan decoradores para añadir adornos gráficos a sus widgets (pequeñas aplicaciones)

Patrones relacionados
Adapter: Un decorador es diferente que un adaptador, un decorador solo cambia las responsabilidades de un objeto y no su interfaz; un adaptador dará a un objeto una interfaz completamente nueva.
Composite: Un decorador puede ser visto como una forma degenerada de Composite con un solo componente. Sin embargo un decorador añade nuevas responsabilidades que no estaban destinadas al objeto por agregación.
Strategy: Un decorador cambia la mascara (apariencia) de un objeto, en Strategy se cambia su interior.

Referencias Bibliográficas
Design Patterns Elements of Reusable Object-Oriented Software, GoF. http://www.lsi.us.es/docencia/get.php?id=1379
http://www.ayc.unavarra.es/miguel.pagola/Decorador.pdf