Patrón de Diseño: Composite

INTRODUCCION

Los patrones estructurales están relacionados con cómo las clases y los objetos se combinan para dar lugar a estructuras más complejas. Puede hacerse la distinción de patrones estructurales asociados a clases y asociados a objetos, los primeros utilizarán la herencia, los segundos la composición.
Los patrones estructurales asociados con objetos describen formas de componer los objetos para conseguir nueva funcionalidad. La flexibilidad de la composición de objetos viene de la posibilidad de cambiar la composición en tiempo de ejecución, lo que es imposible con la composición estática de clases. En el presente documento se da a conocer uno de los patrones de diseño asociado a objetos llamado COMPOSITE.

I. PATRÓN DE DISEÑO: COMPOSITE

A continuación se encuentra la plantilla del patrón objeto de estudio:

1. Nombre del patrón: Composite.

2. Clasificación del patrón: Estructural.

3. Intención: Permitir la construcción de objetos complejos componiendo de forma recursiva objetos similares en una estructura de árbol.
Permitir la manipulación de 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.

4. También conocido como: Compuesto.

5. Motivación:

•Hay que distinguir entre los diferentes objetos.
•Algunos elementos gráficos se componen de alguna primitiva y ese mismo elemento gráfico.

El patrón Composite:

•Propone una solución basada en composición recursiva.
•Además, describe cómo usar correctamente esta recursividad.
•Permite manipular los objetos de forma uniforme gracias a una interfaz común.
6. Aplicabilidad:

Este patrón se usa cuando:

•Se quiera representar jerarquías de objetos todo-parte.
•Se desee que los clientes puedan ignorar la diferencia entre los objetos compuestos y los objetos individuales, es decir, que los clientes puedan tratar todos los objetos de la estructura de forma uniforme.
•Tienes un objeto complejo que quieres descomponer en una jerarquía de objetos.
•Se quiere minimizar la complejidad del conjunto de la jerarquía minimizando el número de tipos diferentes de objetos hijo en el árbol que los objetos compuestos necesitan para formarse.

7. Estructura:


8. Participantes:

Componente: Clase abstracta de la que heredan todas las demás
•Declara la interfaz de todos los objetos de la composición.
•Declara una interfaz de acceso y manipulación de los componentes hijo.
•Opcionalmente, define una interfaz para acceder al padre de cada componente.

Hoja: Nodo hoja del árbol de objetos obtenido a partir de la estructura de clases.
•No tiene hijos.
•Define el comportamiento de los objetos primitivos del compuesto.

Cliente: Maneja los objetos que forman parte del Compuesto como Componentes.

Compuesto: Superclase que define los métodos necesarios para manejar los objetos que agrupa un nodo compuesto
•Define el comportamiento de los componentes compuestos.
•Almacena a los hijos.
•Implementa las operaciones de manejo de los componentes hijos.
•Los objetos compuestos normalmente tratan a los objetos que contienen como instancias de Componente.

9. Colaboraciones:
•Operación implementa el código en la hoja como en el componente.
•Los clientes usan la interfaz Componente para acceder a los objetos dentro de la composición. Si se trabaja contra un objeto simple, la petición se maneja directamente. Si se trabaja contra un objeto de composición, entonces, por lo general, la petición es dirigida a todos los hijos, en algunos casos, realizando algunas tareas previas y posteriores a la operación.


10. Consecuencias:

•Se define una jerarquía de objetos hoja y objetos compuestos que se van componiendo de forma recursiva.
•El cliente se simplifica, ya que trata los objetos hoja y los compuestos de la misma forma.
•La inclusión de nuevas clases hoja o clases compuestas no modifica la estructura anterior ni el código del cliente.
•La desventaja de poder añadir nuevos componentes surge si se desea restringir el tipo de objetos que forman parte de un compuesto.
•Se dificulta el control de los tipos de composiciones válidas. Deben hacerse chequeos en tiempo de ejecución.
•Hay que tener más cuidado con las restricciones en las operaciones. Nos puede llevar a tener errores en tiempo de ejecución.

11. Implementación:

•Definir las operaciones que debe incluir componente.
•Definir dónde se declaran las operaciones de los hijo
•Si se definen en el Componente se obtiene trasparencia pero se pierde seguridad.
•Si se definen en el Compuesto se consigue seguridad pero se pierde trasparencia.
•Definir cual es la mejor estructura de datos para almacenamiento de componentes

12. Código de ejemplo:
public interface Componente {
public abstract Compuesto obtenerCompuesto();
}
public class Hoja implements Componente {
public Compuesto obtenerCompuesto(){
return null;
}
}
public class Compuesto implements Componente {
private Nombre nombre;
private Vector lista;
public Compuesto (String nombre){
nombre = new Nombre(nombre);
lista = new Vector();
}
public void add (Componente componente){
lista.addElement(componente);
}
public boolean remove (Componente componente){
return lista.removeElement(componente);
}
public Componente obtenerHijo (int hijo){
return (Componente)lista.elementAt(hijo);
}
public Compuesto obtenerCompuesto(){
return this;
}
}

13. Usos Conocidos:
•El paquete java.awt.swing contiene un buen ejemplo del patrón Composite. Su clase Component cubre el papel del ComponenteAbstracto. Su clase Container cubre el papel del CompositeAbstracto Tiene un número de clases en el papel ComponenteConcreto, incluyendo Label, TextField, y Button. Entre las clases en el papel CompositeConcreto se incluyen Panel, Frame, y Dialog.

14. Patrones relacionados:

•Decorator Generalmente se usan juntos.
•Flyweight Para compartir componentes, cuando no haya referencias a los padres.
•Iterator Para recorrer los hijos en un composite.
•Visitor Se puede utilizar el patrón Visitor para encapsular operaciones en una clase simple, que de lo contrario podría propagarse a tráves de muchas clases y agregar comportamiento a las clases del patrón Composite.
•Chain of Responsibility El patrón Chain of Resposibility puede ser combinado con el patrón Composite para añadir links del hijo al padre (para propagar responsabilidades hacia arriba), de tal forma que, los hijos puedan conseguir información sobre un progenitor sin tener que conocer que progenitor proporciona la información.


REFERENCIAS
[1] García Pérez Baltasar. Desarrollo rápido de aplicaciones. Version PDF.
[2] Orjuela Luz Marina. Modelos de Programación: Patrones GOF 07. Universidad Distrital Francisco José de Caldas. 2006.
[3] Cuesta Carlos E. Patrones de Diseño. Ingeniería de software I. Universidad Rey Juan Carlos. Versión PDF.
[4] Romero Tapia Esteban. Ayudantía N° 6. Versión PDF.
[5] Herrera Mauricio, Navia Andrés. Bridge, Builder & Interpreter. Versión PDF.
[6] http://www.info-ab.uclm.es/asignaturas/42579/cap4/Estructural.htm
[7] http://www.cs.clemson.edu/~malloy/courses/patterns/bridge.html
[8] http://sourcemaking.com/design_patterns/bridge
[9] http://en.wikipedia.org/wiki/Bridge_pattern