| COMPOSITE |
1. CLASIFICACIÓN DEL PATRÓN
Patrón Estructural.
2. INTENCIÓN
Compone objetos en las estructuras de árbol para representar jerarquías parte-enteras. Composite deja al cliente tratar objetos y las composiciones individuales de objetos uniformemente.
3. MOTIVACIÓN
Los usos aplicaciones como editores de dibujo y sistemas esquemáticos de la captura dejaron a usuarios construir diagramas complejos fuera de componentes simples.
El usuario puede agrupar componentes para formar componentes más grandes, que alternadamente se pueden agrupar todavía para formar más grande componentes. Una puesta en práctica simple podría definir las clases para los primitivos gráficos tales como texto y líneas más otras clases que actúan como envases para éstos primitivos.
Pero hay un problema con este intento: código que utiliza estas clases debe tratar primitivo y el envase se opone diferentemente, incluso si la mayor parte del tiempo el usuario las trata idénticamente. Teniendo que distinguir estos objetos hace el uso más complejo. El patrón compuesto describe cómo utilizar la composición recurrente de modo que los clientes don' t tiene que hacer esta distinción.
4. POSIBLES APLICACIONES PARA EL COMPOSITE
Se debe usar el patrón Composite cuando:
· Se quiere representar una herencia parte-todo de objetos.
· Se quiere que el cliente sea capaz de ignorar la diferencia entre las composiciones de objetos, el cliente trataran todos los objetos en la estructura compuesta uniformemente.
5. ESTRUCTURA
La estructura básica que maneja el Composite está compuesta por:
Fig. 1. Diagrama de clases del modelo de uso del Composite.
6. PARTICIPANTES
· Component: declara la interface para los objetos de la composición. Implementa el comportamiento por defecto de la interfaz común de todas las clases apropiadamente. Declara una interfaz para accesar y manejar los componentes hijos. Define la interfaz para accesar a los componentes padres en la estructura recursiva e implementa esta si es necesario (opcional).
· Leaf: representa objetos leaf en la composición, un leaf no tiene hijos. Define el comportamiento de los objetos primitivos en la composición.
· Composite: define el comportamiento de los hijos, guarda los componentes de los hijos, implementa las operaciones relacionadas con la interfaz del componente.
· Client: manipula objetos en composición a través de la interfaz de componente.
7. COLABORACIONES
Los clientes utilizan la interfaz de componente de la clase para obrar recíprocamente con los objetos en la estructura compuesta. Si el recipiente es una hoja, después la petición se maneja directamente. Si el recipiente es un compuesto, después transmite generalmente a peticiones sus componentes del niño, posiblemente realizando operaciones adicionales antes y/o después de remitir.
8. CONSECUENCIAS
El patrón Composite tiene las siguientes consecuencias:
· Define las jerarquías de la clase que consisten en objetos primitivos y objetos compuestos. Los objetos primitivos se pueden componer en objetos más complejos, que alternadamente pueden ser compuestos, y así sucesivamente recurrentemente. Dondequiera que el código de cliente cuente con un objeto primitivo, puede también tomar un objeto compuesto.
· Hace al cliente simple. Los clientes pueden tratar las estructuras compuestas y objetos individuales uniformemente. Clientes normalmente no saben (y no les debe importar) si están tratando con una hoja o con un componente compuesto. Esto simplifica código de cliente, porque evita tener que escribir el etiqueta-y-caso-declaración-estilo funciona sobre las clases que definen composición.
· Hace más fácil agregar nuevas clases de componentes. Las subclases nuevamente definidas del compuesto o de la hoja trabajan automáticamente con las estructuras y código de cliente existentes. Cliente no tiene que ser cambiado para las nuevas clases componentes.
· Puede hacer a su diseño excesivamente general. La desventaja de hacerlo fácil agregar nuevos componentes es que hace más duro restringir los componentes de un compuesto. Usted quisiera a veces que un compuesto tuviera solamente seguro componentes. Con el compuesto, usted no puede confiar en el tipo sistema para hacer cumplir esos apremios para usted. usted tiene que utilizar cheques run-time en lugar de otro.
7. IMPLEMENTACIÓN
Para la implementación del Composite es recomendable usar algunas “técnicas” para facilitar su uso.
· Referencias explícitas del padre. Las referencias que mantienen de componentes del niño a su padre pueden simplificar el traversal y la gerencia de una estructura compuesta. La referencia del padre simplifica levantar la estructura y la supresión de un componente.
· Distribución de componentes. Es a menudo útil para compartir componentes, por ejemplo, para reducir requisitos de almacenaje. Pero cuando un componente puede tener no más de un padre, la distribución de componentes llega a ser difícil.
· Maximización de la interfaz componente. Una de las metas del patrón compuesto es hacer a clientes inconscientes de las clases específicas de la hoja o del compuesto; re usando. Para lograr esta meta, la clase componente debe definir tantas operaciones comunes para las clases del compuesto y de la hoja como sea posible. La clase componente proporciona generalmente las puestas en práctica del defecto para éstos las operaciones, y las subclases del hoja y compuestas las eliminarán.
· Declaración de las operaciones de la gerencia del niño. Aunque la clase del compuesto ejecute el adición y quite las operaciones para los niños de manejo, una edición importante en el patrón compuesto es qué clases declaran estas operaciones en la jerarquía compuesta de la clase. ¿Debemos declarar estas operaciones en el componente y hacerlas significativas para las clases de la hoja, o debemos nosotros declararlas y definir solamente en compuesto y sus subclases?
· ¿Debe el componente ejecutar una lista de componentes? Usted puede ser que sea tentado para definir el sistema de niños como variable de caso en la clase componente donde se declaran las operaciones del acceso y de la gerencia del niño. Pero poner el indicador del niño en la clase baja incurre en una pena del espacio para cada hoja, aunque una hoja nunca tiene niños. Esto es de mérito solamente si hay relativamente pocos niños en la estructura.
· El ordenar del niño. Muchos diseños especifican ordenar en los niños del compuesto. En el ejemplo anterior de los gráficos, el ordenar puede reflejar delantero--detrás a ordenar. Si los compuestos representan analice los árboles, después las declaraciones compuestas pueden ser casos de un compuesto cuyos niños deban ser ordenados reflejar el programa.
· El ordenar de hijos. Muchos diseños especifican ordenar en los niños de la puesta en ante memoria para mejorar funcionamiento. Si usted necesita atravesar o buscar las composiciones con frecuencia, la clase compuesta pueden depositar traversal o buscar la información sobre sus niños. El compuesto puede depositar resultados reales o apenas la información que la deja cortocircuitos el traversal o buscar. Por ejemplo, la clase del cuadro del ejemplo de la motivación podía depositar la caja de limitación de sus niños. Durante el dibujo o la selección, esto caja de limitación depositada deja el cuadro evitar dibujar o buscar cuando sus niños aren' t visible en la ventana actual.
· ¿Cuál es la mejor estructura de datos para almacenar componentes? Los compuestos pueden utilizar una variedad de estructuras de datos para almacenar a sus niños, incluyendo listas encadenadas, árboles, órdenes, y tablas de elección arbitraria. La opción de la estructura de datos depende (como siempre) de eficacia. De hecho, no es incluso necesario utilizar una estructura de datos de fines generales en absoluto. Los compuestos tienen a veces una variable para cada niño, aunque éste requiera cada subclase del compuesto a ejecute su propio interfaz de la gerencia.
8. CÓDIGO DE EJEMPLO
class Equipment {
public:
virtual ~Equipment();
const char* Name() { return _name; }
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual void Remove(Equipment*);
virtual Iterator* CreateIterator();
protected:
Equipment(const char*);
private:
const char* _name;
};
class FloppyDisk : public Equipment {
public:
FloppyDisk(const char*);
virtual ~FloppyDisk();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
};
class CompositeEquipment : public Equipment {
public:
virtual ~CompositeEquipment();
virtual Watt Power();
virtual Currency NetPrice();
virtual Currency DiscountPrice();
virtual void Add(Equipment*);
virtual void Remove(Equipment*);
virtual Iterator* CreateIterator();
protected:
CompositeEquipment(const char*);
private:
List_equipment;
};
9. USOS CONOCIDOS
Los ejemplos del patrón compuesto se pueden encontrar en casi todos los sistemas orientados al objeto. La clase original de la visión de modelo/opinión/el regulador del palique [KP88] era un compuesto, y casi cada juego de herramientas o marco del interfaz utilizador ha seguido en sus pasos, incluyendo ET++ (con su VObjects [WGM88]) y las entrevistas (estilos [LCI+92], gráficos [VL88], y Glyphs [CL90]). It' s interesante observar que la vista original del modelo/de la visión/del regulador tenía un sistema de subviews; es decir la visión era la clase componente y la clase compuesta. Lanzamiento 4.0 de Smalltalk-80 revisó el modelo/la visión/el regulador con una clase de VisualComponent que tiene la opinión y CompositeView de las subclases.
10. PATRONES ASOCIADOS
Se le relaciona al patrón composite frecuentemente con los patrones; chain of responsibility, decorator, flyweight, iterator, visitor.
REFERENCIAS BIBLIOGRÁFICAS
Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)
Thinking in patterns in java – Bruce Eckel
Patterns in Java - Mark Grand – Wiley
No hay comentarios:
Publicar un comentario