Composite

Nombre del patrón
Composite

Clasificación del patrón
Estructural

Intención
Consiste en crear objetos a partir de otros más pequeños, también puede contener objetos que tienen otros objetos, dando el aspecto de un árbol eneario. Composite permite a los clientes tratar cada uno de los objetos y composiciones de objetos de manera uniforme.

Motivación
A veces es necesario trabajar tanto con elementos simples como con colecciones, donde las colecciones son formadas por múltiples elementos simples o por otras colecciones.
Un sencillo ejemplo de esto son las aplicaciones de dibujo, donde se tiene la posibilidad de crear elementos de dibujo simples (líneas, rectángulos, textos, etc.) y luego agrupar con el objetivo de operar con todo el conjunto, o composición, como si fuera una unidad. A su vez, las composiciones se pueden volver a agrupar con más elementos simples o con otras composiciones.
De esta manera se obtienen estructuras de árbol con las cuales se puede operar.

Aplicabilidad
Usamos el patrón Composite cuando:

• Se desea representar jerarquías parte-todo de los objetos.


• Para que los clientes puedan ignorar la diferencia entre los objetos compuestos y los objetos individuales, es decir, los clientes tratan todos los objetos de la estructura de forma uniforme.

Estructura
Participantes

• Component Declara la interfaz para los objetos de la composición.
  Interfaz de acceso y manipulación de los componentes hijo.
  Implementa algunos comportamientos por defecto.
• Leaf Representa los objetos simples. No poseen hijos.
  Define el comportamiento explícito de cada objeto simple.
• Composite Define el comportamiento de los objetos que tienen hijos.
  Almacena los objetos hijos.
  Implementa las operaciones referentes a los hijos.
• Client Maneja los objetos en la composición mediante la interfaz Component.

Colaboraciones
Los clientes usan la interfaz Component 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.

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 (Necesidad de comprobaciones dinámicas).

Implementación
A la hora de implementar una estructura Composite debemos tener en cuenta:

• Referencias explícitas a los padres.
• Compartir componentes.
• Maximizar la interface Component.
• Declarar las operaciones de manejo de hijos.
• Implementaría Component una lista de componentes?.
• Orden de los hijos.
• “Caching” para mejorar el rendimiento.
• Quién borraría componentes?.
• Cuál es la mejor estructura de datos para almacenar componentes?.

Usos Conocidos
En .NET, los controles son un ejemplo clásico de un Composite. Un control puede ser simple (no acepta hijos) o compuesto (acepta controles simples o compuestos).
Todos los controles heredan su funcionalidad de la clase Control. Esta clase contiene una propiedad (Controls) que retorna una colección (ControlCollection) con toda la funcionalidad necesaria para manejar hijos.
Según lo anterior, todas las clases que deriven su funcionalidad de la clase Control estarían implementando objetos compuestos.
La variante utilizada se centra en crear una colección vacía (EmptyControlCollection). La colección vacía hereda su funcionalidad de ControlCollection y redefine todas las operaciones para el tratamiento de hijos con implementaciones que elevan una excepción.
De esta forma, los objetos simples redefinen el método CreateControlCollection de la clase Control retornando una colección vacía.

Patrones relacionados
Chain of Responsibility Usualmente usado en el vínculo componente-padre.
Decorator Cuando son usados en conjunto, tendrán una clase padre en común. Por lo tanto Decorator tendrá que soportar la interfaz de un componente (Add, Remove y GetChild).
Flyweight permite compartir componentes, pero ya no pueden tener una referencia al padre.
Iterator puede ser usado para recorrer las composiciones.
Visitor localiza operaciones y comportamiento que, de otra manera, serian distribuidos a través de las clases Composite y Leaf.

Referencias Bibliográficas
http://www.speit.org/files/composite_2x1.pdf
http://www.universala.net/blog/archive/2008/08/19/patron-composite.aspx
http://kybele.escet.urjc.es/documentos/SI/Patrones/07_Composite.pdf
dc.exa.unrc.edu.ar/nuevodc/materias/sistemas/2007/Patrones/1181572570/Composite1.ppt