PATRON DE DISEÑO
COMPOSITE
INTEGRANTES:
MIGUEL ANGEL AGREDA CATORCENO
JOSÉ RODRIGO SANDOVAL CHAVEZ
IVAN ALFREDO VACA VARGAS
INTRODUCCION
• El patrón Coomposite sirve para construir objetos complejos a partir
de otros más simples y similares entre sí. Gracias a la composición
recursiva y a una estructura en forma de árbol.
• Esto simplifica el tratamiento de los objetos creados, ya que al poseer
todos ellos una interfaz común, se tratan todos de la misma manera.
PROPOSITO
• Componer objetos en estructuras de árbol para representar jerarquías todo
parte. El patrón permite a los clientes tratar a los objetos individuales y a las
composiciones de objetos uniformemente.
• Podemos equipar este patrón a un panal y sus celdas. Cada objeto simple
(celda) puede relacionarse con otros formando una estructura más compleja
(panal).
ESTRUCTURA
• El patrón Composite es un patrón estructural.
• Los patrones estructurales se refieren a como se
componen las clases y objetos para formar
estructuras más grandes.
• Los patrones de objetos estructurales definen
formas de componer objetos para obtener
nuevas funcionalidades.
DIAGRAMA DE CLASES DEL COMPOSITE
PARTICIPANTES
• Componente (Component) Generalmente es una interface
o clase abstracta que tiene las operaciones mínimas que
serán utilizadas, este componente deberá ser extendido por
los otros dos componentes Leaf y Composite.
• Hoja(Leaft) El leaf u hoja, representa la parte más simple o
pequeña de toda la estructura y ésta hereda de Component.
Leaf recibe su nombre de la teoría de árboles, donde se le
nombra así a todo nodo que no tiene descendencia, en este
caso son clases simple que no están compuestas de otras.
• Composite Este componente es el que le da vida al patrón
de diseño ya que este objeto está conformado por un
conjunto de Component y Leaf. En teoría de árboles este
componente representaría una rama.
• Cliente Manipula los objetos de la composición a través de
la interfaz.
COLABORACIONES
Cliente usa el interfaz de
componente para interactuar con
objetos en la estructura de
composite.
• Si el receptor es una hoja,
entonces la petición es manejada
directamente.
• Si el receptor es un Composite,
lanza la petición a sus hijos.
APLICABILIDAD
El patrón composite se usa cuando:
• Cuando se quieren representar
jerarquías de objetos.
• Cuando queremos que los clientes
puedan ignorar la diferencia entre
composiciones de objetos y objetos
individuales.
IMPLEMENTACION
Algunas recomendaciones para implementación del patrón son las siguientes.
• Referencia explicitas a los padres. Con ello se simplifica algunas operaciones de la
estructura compuesta. Lo mejor es definirlas en la clase Componente. Gestionarlas al
añadir/eliminar elementos de un Composite.
• Compartir Componentes: Es muy útil por el ahorro de memoria que supone. La gestión del
componente con varios padres puede llegar a ser compleja.
• Maximizar la Interfaz del Componente: Dar un comportamiento por defecto que
sobrescribirán las subclases.
• Orden de los hijos: En ocasiones los hijos representan un orden, y hay que tenerlo en cuanta
para la implementación.
• Declaración de las operaciones de manejo de hijos: Definirlas en la raíz Componente y
darle una implementación por defecto permite aumentar la transparencia, pero se pierde
seguridad (¿Cómo evitar que añada/elimine objetos a una hoja?). Si las definimos en clase
Composite se obtiene más seguridad pero se pierde transparencia al no existir una interfaz
uniforme.
VENTAJAS
• Define jerarquías de clase que consisten en objetos simples y en
composiciones de esos objetos: Los objetos simples pueden ser
compuestos en objetos más complejos que a su vez puede ser
compuestos por otros objetos compuestos y así recursivamente. En
cualquier lugar del código del cliente donde se necesite un objeto
simple, también se podrá usar un objeto compuesto.
• Hace al cliente más simple: Los clientes pueden tratar los objetos
simples y compuestos uniformemente. Los clientes normalmente no
saben (y no les debería importar) si están tratando con una hoja (Leaf) o
con un objeto Composite. Esto simplifica el código del cliente.
• Hace más fácil añadir nuevos tipos de componentes: Si se define una
nueva clase Leaf o Composite, esta funcionara automáticamente con la
estructura que ya estaba definida y el cliente no tendrá que cambiar.
DESVENTAJAS
• Puede hacer nuestro diseño demasiado
general: La desventaja de hacer más fácil
añadir nuevos componentes es que también
hace más difícil restringir los componentes
de una composición. A veces queremos que
una composición tenga solo un
determinado tipo de componentes. Con este
patrón tendríamos que hacer
comprobaciones en tiempo de ejecución.
