Composite

Revisión del 16:37 20 jun 2019 de Javiermartin jc (discusión | contribuciones) (Texto reemplazado: «<div align="justify">» por «»)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Composite
Información sobre la plantilla
Concepto:Este patrón consiste en crear objetos a partir de otros mas pequeños.

Composite. Patrón de diseño muy poderoso en sí mismo, consiste en crear objetos a partir de otros mas pequeños. Permite combinar objetos en estructuras de árbol para representar jerarquías. Permite además, agrupar varios objetos como si fueran uno solo.

Tipo

Es un patrón estructural a nivel de objetos.


Propósito

Permitir a los clientes tratar uniformemente a los objetos simples y compuestos de una estructura jerárquica recursiva.



Intención

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


Cuando usarlo

  • Cuando se pretende representar una jerarquía recursiva de objetos.
  • Cuando se pretende que los clientes no reparen en las diferencias entre objetos simples y compuestos.


Ventajas e Inconvenientes

Ventajas

  • Simplifica notablemente al cliente, al no tener éste que distinguir entre objetos simples y compuestos.
  • Favorece la extensibilidad, ya que es muy fácil añadir nuevos tipos de componentes, tanto simples como compuestos.


Inconvenientes

  • Puede hacer el diseño peligrosamente genérico, dificultando la imposición de restricciones sobre ciertos componentes de la jerarquía (por ejemplo, las comprobaciones de tipo no se pueden hacer con garantía más que en tiempo de ejecución). Esta es la otra cara de la facilidad para la extensibilidad.


Relacionado con

  • Es frecuente que la relación entre un componente y su padre se use para una Cadena de Responsabilidades.
  • Decorator es muy frecuentemente usado junto a Composición, como un hijo más del padre común de la jerarquía (“Componente”), por lo que debe adaptarse a su interfaz.
  • PesoMosca permite la compartición de componentes, pero presenta problemas a la hora de hacer referencia a los padres (ambigüedad por tener un componente varios padres).
  • Iterator se usa para recorrer jerarquías de composición recursiva.
  • Visitante localiza operaciones y comportamientos que de otro modo estarían dispersos entre las clases “Simple” y “Compuesto”.


Otros aspectos de interés

  • El cliente sólo trata con un componente genérico, no pudiendo, por tanto, distinguir si es simple o compuesto.
  • “Componente” puede tener algún mecanismo para acceder al padre en la jerarquía de cada objeto (necesario para Cadena deResponsabilidades).
  • Cuanto mayor sea la interfaz de “Componente” mayor será la uniformidad (transparencia) con la que el cliente trata a los distintos elementos, pero eso tiene el inconveniente de que un elemento simple hereda operaciones que sólo tienen sentido para elementos compuestos.
  • Si las operaciones de gestión de los “hijos” (Poner, Quitar, etc...) se ponen en “Componente” prima la transparencia sobre la seguridad. Si se ponen en “Compuesto” sucede al contrario.
  • La estructura de datos utilizada para representar a los “hijos” depende de las circunstancias de cada caso, siempre en aras de la eficiencia.
  • Si los “hijos” están ordenados de alguna forma, el acceso y la gestión de los mismos debe ser especialmente cuidadosa (ver Iterator). Además, salvo en lenguajes con recolección de basura, la eliminación de los “hijos” es tarea del padre.



Ejemplo de aplicación

Un editor de dibujos permite al usuario construir complejas composiciones a partir de elementos básicos, que se ensamblan unos con otros. Utilizando el patrón Composición podemos usar adecuadamente la composición recursiva para ocultar al cliente las diferencias entre elementos gráficos sencillos y compuestos.


Fuentes

  • Patrones del "Gang of Four". Unidad Docente de Ingeniería del Software Facultad de informática - Universidad Politécnica de Madrid
  • DesingPatterns.chm.
  • http://www.martinfowler.com/