Proxy es un sustituto de otro objeto, para controlar el acceso a él, Proxy actúa en lugar del verdadero objeto y ofrece la misma interfaz, y las solicita en el objeto cuando es necesario.

Características generales de este patrón:

Nombre:

Proxy.

También conocido como:

Surrogate.

Propósito:

Es un sustituto de otro objeto, para controlar el acceso a él.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Es necesario una referencia a un objeto más sofisticada que el simple puntero o referencia a objeto.

· Proxy remoto: Cuando usted necesita un representante local de un objeto en otro espacio de direcciones (JVM). 

· Proxy virtual: Para postergar la creación de objetos caros hasta el momento en que se necesitan.

· Proxy de protección: Para controlar el acceso al objeto original.

Estructura:

Etiquetas: Patrones Estructurales, Proxy, Structural patterns

Flyweight define el mecanismo por el cual se puede evitar crear un gran número de estados de objeto para representar a un sistema. Ya que permite compartir estados para soportar un gran número de objetos pequeños aumentando la eficiencia en espacio.

Para conseguir esto se utilizan objetos que almacenan los estados compartidos y que pueden ser usados por varios objetos simultáneamente.

Características generales de este patrón:

Nombre:

Flyweight.

Propósito:

Uso compartido de apoyo a un gran número de objetos de grano fino de manera eficiente.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Se utiliza un gran número de objetos.

· El coste de almacenamiento es alto debido a la cantidad de objetos.

· La mayoría de los estados de los objetos pueden ser creados como comunes.

· Muchos objetos pueden ser reemplazados por unos pocos una vez que han sido borrados los estados no comunes.

· La aplicación no depende de la identidad de los objetos.

Estructura:

Participantes:

· FlyweightFactory: Esta fábrica es responsable de crear y administrar los Flyweights. Facilitar el acceso a la creacion de flyweight a través de la fábrica garantizando una compartición apropiada. La fábrica puede crear todos los flyweights en el inicio de la aplicación, o esperar hasta que sea necesario.

· Flyweight: La interfaz define los métodos que los clientes pueden utilizar para transmitir en el exterior del estado de los objetos flyweight.

· ConcreteFlyweight: Esta interfaz implementa flyweight, e implementa la capacidad de almacenar datos internos. Los datos internos tienen que ser representativos de todos los casos cuando se necesita flyweight.

· UnsharedConcreteFlyweight: No todas las subclases flyweight necesitan ser compartidas. La interfaz flyweight permite compartirla, pero no imponerla. Es común que los objetos UnsharedConcreteFlyweight tengan objetos ConcreteFlyweight como los hijos en algun nivel en la estructura de objetos de flyweight.

· Cliente: El cliente es responsable de crear y proporcionar el contexto para los flyweights. La única manera de obtener una referencia a un flyweight es a través de FlyweightFactory.

Consecuencias:

· Genera ahorro en el almacenamiento.

· Reduce el número total de objetos.

· Consume más tiempo para realizar las búsquedas.

Patrones relacionados:

· Abstract Factory.

· Composite.

· State.

· Strategy.

Etiquetas: Flyweight, Patrones Estructurales, Structural patterns

Facade proporciona una interfaz unificada a un conjunto de interfaces de un sistema, define una interfaz de alto nivel que hace al sistema más fácil de usar.

Así se simplifica el acceso a un conjunto de objetos proporcionando uno que todos los clientes pueden usar para comunicarse con el conjunto, su objetivo es minimizar las comunicaciones y dependencias entre subsistemas.

Características generales de este patrón:

Nombre:

Facade.

También conocido como:

Façade.

Propósito:

Facade proporciona una interfaz unificada a un conjunto de interfaces de un sistema, define una interfaz de alto nivel que hace al sistema más fácil de usar.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Desea proporcionar una interfaz simple a un subsistema complejo.

· Hay muchas dependencias entre los clientes y la implementación de una abstracción de clases. Introducir una fachada para desacoplar el subsistema de los clientes y otros subsistemas, promoviendo así la independencia y portabilidad al subsistema.

· Desee que su capa subsistemas, use una fachada para definir un punto de entrada a nivel de cada subsistema. Si los subsistemas son dependientes, entonces se puede simplificar las dependencias entre ellos por lo que se comunican entre sí únicamente a través de sus fachadas.

Estructura:

Participantes:

· Facade: La clase para que los clientes utilicen. Se sabe de los subsistemas que utiliza sus respectivas responsabilidades. Normalmente todas las solicitudes de cliente se delegará a los subsistemas.

· Subsistema: Se trata de un conjunto de clases, pueden ser utilizadas por los clientes directamente o a través del trabajo que les asigna la fachada; No tiene conocimiento de la fachada, para el subsistema, la fachada será igual a otro cliente.

Consecuencias:

· Oculta a los clientes los componentes del subsistema, reduce el número de objetos con los que tienen que tratar los clientes.

·   Disminuye el acoplamiento entre un subsistema y sus clientes:

v Un menor acoplamiento facilita el cambio de los componentes del subsistema

v sin afectar a sus clientes

v Las fachadas permiten estructurar el sistema en capas

v Reduce las dependencias de compilación

· No evita que las aplicaciones puedan usar las clases del subsistema si lo necesitan, se puede elegir entre facilidad de uso y generalidad.

Patrones relacionados:

· Abstract Factory.

· Mediator.

· Singleton.

Etiquetas: Facade, Patrones Estructurales, Structural patterns

Decorator amplía la funcionalidad al tiempo que mantiene la misma interfaz, contrariamente a un adaptador que modifica las interfaces sin agregar funcionalidad. Generalmente, un decorador no altera la funcionalidad existente, sólo añade más funciones, de modo que los objetos de la clase resultante se comporten exactamente como los originales, pero que también realicen algo adicional.

Características generales de este patrón:

Nombre:

Decorator.

También conocido como:

Wrapper.

Propósito:

Asignar nuevas responsabilidades a un objeto dinámicamente. Provee una alternativa a la creación de subclases por herencia.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Para asignar responsabilidades a objetos individuales de forma dinámica y transparente, sin afectar a otros objetos.

· Para responsabilidades que pueden ser suprimidas.

· Cuando no es práctico utilizar herencia de clases (porque se produciría una explosión del número de clases, o porque no se tiene la definición de la clase).

Estructura:

Etiquetas: Decorator, Patrones Estructurales, Structural patterns

Composite permite construir objetos complejos componiendo de forma recursiva objetos similares en una estructura de árbol; Permite manipular todos los objetos contenidos en el árbol de forma uniforme, ya que todos ellos poseen una interfaz común definida en la clase raíz.

Características generales de este patrón:

Nombre:

Composite.

Propósito:

Componer objetos en jerarquías todo-parte y permitir a los clientes tratar objetos simples y compuestos de manera uniforme.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Desee representar jerarquías parte-todo de los objetos (Hay un modelo de componentes, con una estructura rama-hoja o parte de todo el contenedor-contenido).

· Desee que los clientes ignoren la diferencia entre composiciones de objetos y cada uno de los objetos. Los clientes traten a todos los objetos de la estructura compuesta de manera uniforme.

· La estructura puede tener cualquier nivel de complejidad, y es dinámica.

Estructura:

Etiquetas: Composite, Patrones Estructurales, Structural patterns

El Patrón Estructural Bridge tiene como objetivo desacoplar una abstracción de su implementación, de manera que ambas puedan ser modificadas independientemente sin necesidad de alterar por ello la otra.

La herencia permite que una abstracción tenga varias implementaciones, esta relación se define en tiempo de compilación; Se desacopla una abstracción de su implementación para que puedan variar independientemente.

Características generales de este patrón:

Nombre:

Bridge.

También conocido como:

Handle/Body.

Propósito:

Desacopla una abstracción de su implementación de manera que las dos puedan evolucionar independientemente.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Para evitar una vinculación permanente entre una abstracción y su implementación (Permite cambiar la implementación en tiempo de ejecución).

· Cuando tanto las abstracciones como las implementaciones podrían ser susceptibles de extensión mediante subclases (El patrón Bridge permite combinar las abstracciones e implementaciones y extenderlas independientemente, permite además reducir la proliferación de clases).

· Para que cambios en la implementación de una abstracción no hagan recompilar el código de los clientes.

· Para compartir una implementación entre múltiples objetos, sin que lo noten los clientes.

Estructura:

Participantes:

· Abstraction: Define una interfase abstracta, mantiene una referencia a un objeto de tipo Implementor.

· RefinedAbstraction: Extiende la interfase definida por Abstraction.

· Implementor: Define la interfase para la implementación de clases, esta interface no se tiene que corresponder exactamente con la interfase de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente. Típicamente la interface Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.

· ConcreteImplementor: Implementa la interfase de Implementor y define su implementación concreta.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Se desea evitar un enlace permanente entre la abstracción y su implementación. Esto puede ser debido a que la implementación debe ser seleccionada o cambiada en tiempo de ejecución.

· Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases. En este caso, el patrón Bridge permite combinar abstracciones e implementaciones diferentes y extenderlas independientemente. Además que reduce la proliferación de clases.

· Cambios en la implementación de una abstracción no deben impactar en los clientes, es decir, su código no debe tener que ser recompilado.

· Se desea compartir una implementación entre múltiples objetos (quizá usando contadores), y este hecho debe ser escondido a los clientes.

Consecuencias:

· Se desacopla interfaz e implementación: La implementación no está vinculada permanentemente a la interfaz, y se puede determinar en tiempo de ejecución (incluso cambiar), se eliminan dependencias de compilación, se consigue una arquitectura más estructurada en niveles.

· Se mejora la extensibilidad: Las jerarquías de abstracción y de implementación pueden evolucionar independientemente.

· Se esconden detalles de implementación a los clientes.

Patrones relacionados:

· Abstract Factory.

· Adapter.

Etiquetas: Bridge, Patrones Estructurales, Structural patterns

Adapter es un patrón estructural que es utilizado para que dos interfaces no relacionadas puedan trabajar juntas, la conexión entre ambas es llamada un Adaptador. Básicamente el propósito del Adaptador es que convierte la interfaz de una clase en otra que es la que esperan los clientes. Es decir permite que trabajen juntas, clases que de otro modo no podrían hacerlo debido a que tengan interfaces incompatibles.

Características generales de este patrón:

Nombre:

Adapter.

También conocido como:

Wrapper.

Propósito:

Convertir la interfase de una clase en otra interfase que el cliente espera. 

El adapter permite que clases trabajen juntas, que de otra manera no podrian por las interfases incompatibles.

Aplicabilidad:

Este patrón se utiliza generalmente cuando:

· Se quiere usar una clase existente, y su interfase no concuerda con la que se necesita.

· Se quiere crear una clase reusable que coopere con clases no relacionadas o imprevistas, esto es,  clases que no tienen interfases compatibles necesariamente.

· Un objeto debe actuar como intermediario de un grupo de clases, y no es posible saber qué clase se utilizará hasta el tiempo de ejecución..

Estructura:

Participantes:

· Target: Define la interfaz especifica del dominio en el que se quiere hacer uso de la clase que se adapta.

· Client: Utiliza objetos que implementan la interfaz definida por el target.

· Adaptee: Presenta su interfaz original, que es la que se tiene que adaptar.

· Adapter: Adapta la interfaz del objeto adaptado a la definida por el target.

Colaboraciones:

El Cliente llama a las operaciones en la instancia del Adapter. Luego, el Adapter llama al Adaptee (el Adaptado) y lleva a cabo las operaciones pedidas.

Consecuencias:

· Adapter Adapta el Adaptee al Target informando a un class Adapter concreto. Como consecuencia, un class Adapter no funciona cuando queremos adaptar una clase y todas sus subclases (subclassing).

· El Adapter sobreescribe el comportamiento del Adaptee ya que el Adapter es una subclase del Adapteee.

· Introduce solamente un objeto y no hay un  puntero adicional para conseguir el Adaptee.

Patrones relacionados:

· Bridge.

· Decorator.

· Proxy.

Etiquetas: Adapter, Patrones Estructurales, Structural patterns

Los Patrones Estructurales describen como los objetos y las clases pueden ser combinados para formar estructuras mas grandes y proporcionar nuevas funcionalidades. Por otro lado los patrones estructurales describen como los objetos pueden ser asociados y combinados para formar estructuras más grandes y más complejas.

En las siguientes entradas mostraré las características de cada uno de los patrones que conforman este grupo estructural:

Etiquetas: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Patrones Estructurales, Proxy, Structural patterns