Proxy Pattern

Propósitos

 Proporcionar un representante o sustituto de otro objeto para controlar el
acceso a éste.
 Utilizar una capa extra para ayudar con el acceso inteligente, controlado y
distribuido de un objeto. Ya sea por razones de seguridad, o porque la creación
del objeto es costosa , o porque se está accediendo de una localización remota.

Problema

Se requiera instanciar un objeto que demanda muchos recursos, pero se necesita hacer una carga rápida o parcial de la representación de este objeto.

Se usa cuando

 Los objetos necesitan ser creados bajo demanda.
 Se requiere un control de acceso para el objeto original.
 Se requiere agregar funcionalidad cuando se accede al objeto.

Ejemplos en el JDK y JEE

java.lang.reflect.Proxy
java.rmi.*
javax.ejb.EJB
javax.inject.Inject
javax.persistence.PersistenceContext

Composite Pattern

Propósitos

 Facilitar la creación de jerarquías de objetos, donde cada objeto puede ser
tratado de forma independiente o como un conjunto de objetos anidados a
través de la misma interfaz.

 Composición recursiva.

Problema

La aplicación necesita manipular una colección jerárquica de objetos compuestos y primitivos. El procesamiento de un objeto primitivo es manejado de una manera, mientras que el procesamiento de un objeto compuesto se maneja de otra forma.

Se usa cuando

Se necesitan representaciones jerárquicas de objetos.

Ejemplos en el JDK

 java.awt.Container#add(Component)
 javax.faces.component.UIComponent#getChildren()

Facade Pattern

Propósitos

 Suplir una interfaz única a un conjunto de interfaces dentro de un sistema.
 Encapsular un subsistema complicado por medio de una interfaz simple.

Problema

Un segmento de clases del cliente requiere de una interfaz simplificada para
brindar una funcionalidad general de un subsistema complejo.

Se usa cuando

 Se requiere una interfaz simple para proveer acceso a un sistema complejo.
 Hay muchas dependencias entre los clientes y las implementaciones de
sistemas.
 Los sistemas y los subsistemas deben estar en capas.

Ejemplos en el JDK y JEE

javax.faces.context.FacesContext ,
internamente utiliza las siguientes clases
abstractas/interfaces LifeCycle , ViewHandler , NavigationHandler

javax.faces.context.ExternalContext ,
internamente
utiliza ServletContext , HttpSession , HttpServletRequest , HttpServletResponse .

Adapter Pattern

Propósitos

 Permite que clases con interfaces distintas trabajen juntas para crear un objeto común mediante en el cual se puedan comunicar e interactuar.
 Envolver una clase existente con una nueva interfaz.
 Unir un antiguo componente a un nuevo sistema.

Problema

Cuando un componente externo ofrece una funcionalidad que deseemos reutilizar, pero su “percepción del mundo” no es compatible con la filosofía y arquitectura del sistema que se ha iniciado a desarrollar.

Se usa cuando

 Una clase utilizada no cumple con los requerimientos de una interfaz.
 Condiciones complejas atan el comportamiento del objeto a su estado.
 Las transiciones entre los estados de los objetos necesitan ser explícitas.

Ejemplos en el JDK

 java.util.Arrays#asList()
 java.io.InputStreamReader(InputStream)
 java.io.OutputStreamWriter(OutputStream)
 javax.xml.bind.annotation.adapters.XmlAdapter#marshal()
y #unmarshal()

Decorator Pattern

Propósitos

 Agregar responsabilidades adicionales a un objeto dinámicamente. Los
Decorators proveen una alternativa flexible para extender funcionalidad por
medio de herencia.

 Fortalecimiento del objeto base por medio de wrappers que se llaman
recursivamente.

Problema

Agregar comportamiento o definir el estado de objetos individuales en tiempo de
ejecución. La herencia no es factible debido a que es estática y se aplica a toda una clase.

Se usa cuando

 El comportamiento y responsabilidades de un objeto deben ser dinámicamente
modificables.
 Las implementaciones concretas deben responsabilidades y comportamiento.
ser desacopladas de las responsabilidades y comportamiento.
 El uso de herencia no es práctico.
 La funcionalidad específica no debe residir en la alta jerarquía de objetos.
 Existen muchas variantes alrededor de una implementación concreta.

Iterator Pattern

Propósitos

 Proveer una manera de acceder a los elementos de un objeto agregado
secuencialmente sin exponer su representación principal.
 Proveer un recorrido “polimórfico”.

Problema

Necesidad de un recorrido “abstracto” de estructuras de datos ampliamente
distintas, con la finalidad de que los algoritmos pueden interactuar con ellas de
forma transparente.

Se usa cuando

 Se requiere acceder a elementos de un objeto sin necesidad de acceder a su
representación total.
 Se requieren múltiples o recorridos simultáneos de objetos.
 Se requiere de una interfaz uniforme para el recorrido.
 Existen diferencias sutiles entre los detalles de las implementaciones de varios
iteradores.

Ejemplos en el JDK


 Todas las implementaciones de java.util.Iterator
 Todas las implementaciones de java.util.Enumeration

State Pattern

Propósitos

 Permitir alterar el comportamiento de un objeto en función del cambio de su
estado interno.
 Proveer una máquina de estados orientada a objetos.

Problema

Cuando el comportamiento de un objeto monolítico se encuentra en función de su estado y debe cambiar su comportamiento en tiempo de ejecución en dependencia
del estado. Otro escenario se da cuando una aplicación está caracterizada por
largas y numerosas sentencias condicionales que forman parte de un flujo de
control que a su vez se encuentra basado en los estados de la aplicación.

Se usa cuando

 El comportamiento de un objeto está influenciado por sus estados.
 Condiciones complejas atan el comportamiento del objeto a sus estados.
 Las transiciones de los estados de un objeto necesitan ser explícitas.

Ejemplos

 Aplicaciones de reproductores de música.
 Envío de emails.
 Personaje de video juegos.
 Servlet.

Template Method Pattern

Propósito

Definir la estructura (o pasos) de un algoritmo, postergando la definición de
algunos métodos en las subclases. Por lo tanto, las implementaciones de algunos
métodos varían en las subclases, pero la definición de la estructura principal del
algoritmo (en la clase base) persiste.

Problema

Cuando dos componentes distintos tienen similitudes significativas y ambos no
implementan una interfaz común. Por lo tanto, cuando se da la necesidad de un
cambio, existe una duplicidad de esfuerzo innecesaria.

Se usa cuando

 Se requiere de una única implementación de un algoritmo en una clase
abstracta.
 El comportamiento común entre las subclases debe estar localizado en una clase común.
 La clase base debe ser capaz de invocar de manera uniforme el comportamiento de sus subclases.
 La mayoría o todas las subclases necesitan implementar el comportamiento.

Ejemplos

 Empaquetamientos de aplicaciones javas: jar, war y ear.
 Itinerarios de viajes de paquetes turísticos.

Strategy Pattern

Propósito

 Definir una familia de algoritmos, encapsulándolos a cada uno y haciéndolos
intercambiables.

 Ofrecer la posibilidad de variar el algoritmo independientemente del cliente que lo utiliza.

 Capturar la abstracción en una interfaz, ocultando los detalles de la
implementación en clases derivadas.

 Implementar varios comportamientos por medio de composición.

Problema

Implementar una de las estrategias dominantes del diseño Orientado a Objetos:

Principio Open Closed.

Una forma rutinaria de intentar cumplir con el principio mencionado
anteriormente es mediante la creación de una clase base (o interfaz), ocultando los detalles de la implementación clases derivadas. Pero como desarrolladores no medimos el impacto que este tipo de soluciones implica: el incremento del número de clases derivadas o el cambio de la implementación de ellas.

Se usa cuando

 La única diferencia entre varias clases relacionadas es únicamente el
comportamiento.
 Se requiere de múltiples versiones o variaciones de un algoritmo.
 El comportamiento de una clase debe ser definido en tiempo de ejecución.

Command Pattern

Propósito

Encapsular las peticiones para que sean tratadas como un objeto. Esto permite que las peticiones sean manejadas como colas y llamadas de retornos (callbacks).

Problema

Tareas de monitoreo para diseños monolíticos.

Se usa cuando

 Existe necesidad de implementar callbacks.
 Las solicitudes necesitan ser manejadas varias ocasiones o en distintos órdenes.
 Se requiere de un flujo de solicitudes.
 Se requiere desacoplar el Invoker solicitado. (objeto solicitante) respecto objeto

Ejemplo

En las colas de trabajos (Jobs) este enfoque es ampliamente utilizados para el
procesamiento asíncrono de algoritmos.

Ejemplos en el JDK

Todas las implementaciones de java.lang.Runnable
Todas las implementaciones de javax.swing.Action

Observer Pattern

Propósitos

 Definir una dependencia del tipo uno-a-muchos entre objetos. Cuando cambia
el estado de un objeto, todos los demás objetos dependientes son notificados.

 Encapsular en una abstracción Subject los componentes comunes o
principales, y los componentes variables en una jerarquía Observer.

 Promover el bajo acoplamiento, es decir, que los objetos puedan interactuar
entre sí, pero ellos deben conocen muy poco de uno con respecto a los otros.

Problema

Tareas de monitoreo para diseños monolíticos.

Se usa cuando

 Cuando el estado de uno o varios objetos cambia se requiere disparar ese
comportamiento en el resto de los objetos.

 Se necesita la capacidad de realizar Broadcast.

Ejemplos

 Los Listeners de los controles UI.
 Sistemas de notificaciones.
 Subastas.

Ejemplos en el JDK

Todas las implementaciones de java.util.EventListener (Swing)

Builder

Propósito

Separar la construcción de un objeto complejo a partir de una variedad de partes que contribuyen individualmente a la creación y ensamblaje del objeto
mencionado.

Centraliza el proceso de creación en un único punto, de tal forma que el mismo
proceso de construcción pueda crear representaciones diferentes

Ejemplo del JDK

 (unsynchronized) java.lang.StringBuffer#append() (synchronized) java.nio.ByteBuffer#put() (también en CharBuffer , ShortBuffer , IntBuffer , LongBuffer , FloatBuffer y DoubleBuffer) java.lang.StringBuilder#append()

 javax.swing.GroupLayout.Group#addComponent()

 Todas las implementaciones de java.lang.Appendable

Problema

Existencia de muchas representaciones para la creación de un mismo objeto.

Factory Method Pattern

Propósito

Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos. También conocido como Virtual Constructor (Constructor Virtual).

Ejemplo

Las librerías para crear interfaces gráficas suelen utilizar este patrón y cada familia sería un sistema operativo distinto. Así pues, el usuario declara un Botón, pero de forma interna lo que está creando es un BotónWindows o un BotónLinux.

Ejemplos en el JDK

java.util.Calendar#getInstance()
java.util.ResourceBundle#getBundle()
java.text.NumberFormat#getInstance()
java.nio.charset.Charset#forName()
java.net.URLStreamHandlerFactory#createURLStreamHandler(String)

Problema

Un framework necesita estandarizar la arquitectura del modelo de clases para un conjunto determinado de aplicaciones, pero a su vez debe permitir que cada una de las aplicaciones definan su propio dominio de objetos.

Abstract Factory Pattern

Propósito

Proveer de una interfaz para crear un conjunto o familias de objetos relacionados que dependen mutuamente sin especificar cuál es el objeto concreto.

Brindar una jerarquía de clases cuyo objetivo es la encapsulación de la creación de objetos concretos.

Ejemplo

 Un típico enfoque donde se utiliza este patrón, es cuando utilizamos objetos de
acceso a datos, mejor conocidos como DAO (Data Access Object), donde
tendremos una clase de fábrica de DAO, FactoryDao, el método recibe el tipo
de Dao o adaptador a crear, de ésta forma podríamos tener un DAO para
MSSQL, MySQL, Oracle, etc. Es decir, un DAO concreto para cada motor de base de datos.

 Look And Feel.

Ejemplos en el JDK

javax.xml.parsers.DocumentBuilderFactory#newInstance()
javax.xml.transform.TransformerFactory#newInstance()
javax.xml.xpath.XPathFactory#newInstance()

Problema

Centralizar la creación de una familia de objetos que comparten caract

Singleton Pattern

Propósito

La intención de este patrón es controlar la creación de objetos de una clase, de
forma de que solo exista una única instancia de dicha clase en todo momento.
Adicionalmente provee un mecanismo que permite el acceso fácil y único a esta
única instancia. En resumen, el patrón Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ésta instancia.

La clave para crear un Singleton es prevenir a los programas clientes (de nuestra solución/funcionalidad/etc) tener acceso a la creación de un objeto exceptuando la forma que nosotros proveemos.

Ejemplos

 Aunque puede haber muchas impresoras en el sistema, sólo puede haber una
cola de impresión de la impresora.
 En un sistema operativo sólo debe haber un sistema de archivos y un gestor de
ventanas.
 Un DataSource maneja un número bien definido de conexiones, pero debe
haber una solo DataSource en el sistema.

Ejemplos en el JDK

java.lang.Runtime#getRuntime()
java.awt.Desktop#getDesktop()
java.lang.System#getSecurityManager()

Problema

La aplicación necesita una única instancia de un objeto. Además, la inicialización se da cuando se necesita y el acceso se requiere que sea global a nivel de la aplicación.

Aplicabilidad

Debe haber exactamente una instancia de una clase, y debe ser accesible a los
clientes desde un punto de acceso bien conocido.