UNIVERSIDAD NACIONAL DE TRUJILLO

PATRONES
DE
DISEÑO
COMPOSITE
1
 UNIVERSIDAD NACIONAL DE TRUJILLO

TABLA DE CONTENIDO

INTRODUCCION……………………………………………………………………………………………..…….……4
PATRONES DE DISEÑO COMPOSITE……………………………………………………………………........5
1. Definición………………………………………………………………………………………….…….......5
2. Elementos de un patrón…………………………………………………….………………………….5
3. Propósito……………………………………………………………………………………………….........6
4. Motivación…………………………………………………………………………………………………….6
5. Aplicabilidad………………………………………………………………………………………………….6
6. Ventajas……………………………………………………………………………………………………..…7
7. Inconvenientes………………………………………………………………………………………………7
8. El problema: La escalabilidad…………………………………………………………………….....8
9. La solución..……………………………………………………………….………………………………….8
10. Consecuencia………………………………………………………………………………………………..9
11. Estructura……………………………………………………………………………………………………10
12. Implementación………………………………………………………………………………………….12
13. BIBLIOGRAFIA…………………………………………………………..…………………………………13

2
 UNIVERSIDAD NACIONAL DE TRUJILLO

INTRODUCCION

La programación orientada a objetos (POO) es un paradigma en la que los sistemas

se diseñan mediante clases y relaciones entre ellas. Se utilizan conceptos como la
herencia, polimorfismo, abstracción, encapsulamiento y ocultación.
Conocer estas propiedades es importante para programar en un lenguaje orientado
a objetos sin embargo no es suficiente para diseñar sistemas que sean fáciles de
mantener y que permitan adaptarse a nuevos cambios sin rediseñar los sistemas.
Aquí es donde aparecen los patrones de diseño y principios a la hora de diseñar los
sistemas orientados a objetos. Los patrones de diseño son formas identificadas que
resuelven de forma correcta diferentes problemas comunes a algunos escenarios.
Los principios son unas guías que dirigen el diseño que realizamos y que en gran
medida están presentes en los patrones de diseño.
Muy resumidamente los patrones de diseño tienen como objetivo permitir hacer
frente a toda constante que posee cualquier aplicación, el cambio, de tal forma que
permitan escalar a los sistemas incorporando nuevas funcionalidades y prefiriendo
añadir nuevo código a modificar código existente.

3
 UNIVERSIDAD NACIONAL DE TRUJILLO

¿QUÉ SON LOS PATRONES DE DISEÑO?

Los Patrones de diseño son herramientas para solucionar problemas de Diseño

enfocados al desarrollo de software, estos patrones deben ser reusables
permitiendo así que sean adaptados a diferentes problemáticas.
Cuando hablamos de problemáticas nos referimos a condiciones o problemas
reiterativos en el desarrollo de software donde la solución se encuentra identificada
mediante la aplicación de una serie de pasos, adaptando el sistema a una estructura
definida por un patrón, garantizando que esta solución pueda ser aplicada cuantas
veces sea necesario en circunstancias similares, evitando así la búsqueda de otras
soluciones cuando estas ya se han dado anteriormente.

PATRONES DE DISEÑO COMPOSITE

1. DEFINICION:
Un patrón es un conjunto de información que proporciona respuesta a un
conjunto de problemas similares. Para ello se aíslan los aspectos comunes y su
solución y se añaden cuantos comentarios y ejemplos sean oportunos.
Podríamos definir patrón como una solución a un problema en un contexto.
Contexto. Las situaciones recurrentes.
Problema. Metas y restricciones en el contexto.
Solución. Diseño para conseguir las metas dentro de las
restricciones.
Los patrones ayudan a capturar conocimiento y a crear un vocabulario
técnico, hacen el diseño orientado a objetos más flexible, elegante y en
algunos casos reusable.

4
 UNIVERSIDAD NACIONAL DE TRUJILLO

2. ELEMENTOS DE UN PATRON:

 Nombre. Una o dos palabras, alto nivel de abstracción para facilitar la

asimilación del
Funcionamiento del mismo. Estos nombres se incorporan a la memoria y
son utilizados en la comunicación.

 Problema. Describe cuando se debe aplicar el patrón y su contexto.

 Solución. Detalla el mejor diseño disponible.
 Consecuencias. Describe las ventajas y desventajas del mismo.

Los patrones de diseño pueden relacionarse y aplicarse de forma simultánea en

muchos casos.
El patrón Composite nos permite construir objetos complejos partiendo de otros
más sencillos utilizando una estrategia de composición recursiva. Podemos
equiparar este patrón a un panel y sus celdas. Cada objeto simple (celda) puede
relacionarse con otros formando una estructura más compleja (panel). Lo
podemos ver también como un libro cada hoja (objeto sencillo) se puede
relacionar con otras hojas y forman un libro (objeto compuesto).
Combina objetos en estructuras de árbol para representar jerarquías de parte-
todo. Permite que los clientes traten de manera uniforme a los objetos
individuales y a los compuestos.

3. PROPÓSITO
Componer objetos en estructuras arbóreas para representar jerarquías todo-
parte. Manipular todos los objetos del árbol de manera uniforme.

4. MOTIVACION
• Ej.: las aplicaciones gráficas manejan grupos de figuras hechas de
componentes sencillos (líneas, texto...)
• Solución: Primitivas para los componentes sencillos, ¿y otras para los
contenedores? No porque no se tratan de manera uniforme.
Definir una clase abstracta que represente componentes y contenedores,
de la cual todas heredan, y que define sus operaciones.

5
 UNIVERSIDAD NACIONAL DE TRUJILLO

5. APLICABILIDAD
El patrón Composite se usa cuando se quieren representar jerarquías
de objetos
Cuando queremos que los clientes puedan ignorar la diferencia entre
composiciones de objetos y objetos individuales.

6. VENTAJAS
• Permite tratamiento uniforme de objetos simples y complejos así como
composiciones recursivas.
• Simplifica el código de los clientes, que sólo usan una interfaz.
• Facilita añadir nuevos componentes sin afectar a los clientes .

7. INCONVENIENTES
• Es difícil restringir los tipos de los hijos.
• Las operaciones de gestión de hijos en los objetos simples pueden
presentar problemas: seguridad frente a flexibilidad.

8. EL PROBLEMA: LA ESCALABILIDAD
Un documento está formado por varias páginas, las cuales están
formadas por columnas que contienen líneas de texto, formadas por
caracteres. Las columnas y páginas pueden contener marcos. Los
marcos pueden contener columnas. Las columnas, marcos y líneas
de texto pueden contener imágenes.

6
 UNIVERSIDAD NACIONAL DE TRUJILLO

9. LA SOLUCIÓN
Un documento está formado por varias páginas, las cuales están formadas por
columnas que contienen líneas de texto, formadas por caracteres. Las columnas
y páginas pueden contener marcos. Los marcos pueden contener columnas. Las
columnas, marcos y líneas de texto pueden contener imágenes.

7
 UNIVERSIDAD NACIONAL DE TRUJILLO

• Participantes

 Componente: declara una clase abstracta para la composición de

objetos
 Simple: representa los objetos de la composición que no tienen
hijos e implementa sus operaciones.
 Compuesto: implementa las operaciones para los componentes
con hijos y almacena a los hijos.
 Cliente: utiliza objetos de la composición mediante la interfaz de
Componente.

10. CONSECUENCIAS
• Define jerarquías de clases hechas de objetos primitivos y compuestos.
Si el código cliente espera un objeto simple, puede recibir también uno
compuesto.
• Simplifica el cliente. Objetos simples y compuestos se tratan
homogéneamente
• Facilita la incorporación de nuevos tipos de componentes.
• Puede hacer el diseño demasiado general. Es complicado restringir el tipo
de componentes de un composite.

8
 UNIVERSIDAD NACIONAL DE TRUJILLO

11. ESTRUCTURA

12. IMPLEMENTACIÓN
• Referencias explícitas a los padres.
 Simplifica algunas operaciones de la
estructura compuesta.
 Definirlas en la clase Component
 Gestionarlas al añadir/eliminar elementos de un Composite
• Compartir componentes
 Útil para ahorrar memoria
 La gestión de un componente con varios padres se complica.
• Maximizar la interfaz del componente
 Dar comportamiento por defecto que sobrescribirán las subclase
 Ej: por defecto getChildren no devuelve hijos, lo cual es válido para
las hojas, pero los compuestos deben sobrescribir la operación
• Declaración de las operaciones de gestión de hijos
 Definirlas en la raíz Component y dar implementación por defecto
Se obtiene transparencia, se pierde seguridad (¿cómo evitar que
un cliente añada/elimine objetos a una hoja?)

 Definirlas en Composite
Se obtiene seguridad, se pierde transparencia (interfaz no
uniforme)
Si se pierde el tipo hay que hacer downcasting, lo cual es
inseguro

9
 UNIVERSIDAD NACIONAL DE TRUJILLO

• ¿Debe declarar Component una lista de componentes?

 Penalización de espacio por cada hoja, incluso si no tiene hijos
• A veces los hijos tienen un orden
• ¿Quién debe borrar los componentes?
 Si no hay recolector de basura, el Composite
 Excepción si las hojas son inmutables y pueden estar compartidas.

CÓDIGO DE EJEMPLO 1
public interface Component { public void
add (Component c); public void remove
(Component c); public Component
getChild (int i);

}
public class Leaf implements Component { public void add (Component c) {} //
también puede lanzar una excepción

public void remove (Component c) {} // también puede lanzar una excepción

public Component getChild (int i) { return null; }

public class Composite implements Component { private Vector _children =

new Vector(); public void add (Component c) { _children.addElement(c); }
public void remove (Component c) { _children.removeElement(c); } public
Component getChild (int i) { return _children.elementAt(i); }

CÓDIGO DE EJEMPLO 2
public abstract class Component { public void add (Component c) {} // también
puede lanzar una excepción public void remove (Component c) {} // también
puede lanzar una excepción public Component getChild (int i) { return null; }

10
 UNIVERSIDAD NACIONAL DE TRUJILLO

public class Leaf extends Component {

public class Composite extends Component { private Vector _children = new

Vector(); public void add (Component c) { _children.addElement(c); } public
void remove (Component c) { _children.removeElement(c); } public
Component getChild (int i) { return _children.elementAt(i); }

CÓDIGO DE EJEMPLO 3
public interface Component { public
Composite getComposite ();

public class Leaf implements Component { public

Composite getComposite () { return null; }

public class Composite implements Component { private Vector _children =

new Vector(); public void add (Component c) { _children.addElement(c); }
public void remove (Component c) { _children.removeElement(c);

}
public Component getChild (int i) { return _children.elementAt(i);

}
public Composite getComposite () { return this; }

}
// código cliente

Composite aComposite = new Composite();

11
 UNIVERSIDAD NACIONAL DE TRUJILLO

Leaf aLeaf = new Leaf(); Component

aComponent;

aComponent = aComposite; if (aComponent ==

aComponent.getComposite()) test.add(new Leaf()); // añadirá la hoja
aComponent = aLeaf; if (aComponent ==
aComponent.getComposite()) test.add(new Leaf()); // no añadirá la hoja

EN JAVA
En el paquete java.awt.swing

• Component
 Component
• Composite
 Container (abstracta)
 Panel (concreta)
 Frame (concreta)
 Dialog (concreta)
• Leaf:
 Label
 TextField
 Button

12
 UNIVERSIDAD NACIONAL DE TRUJILLO

BIBLIOGRAFIA

• PDF-Departamento de Sistemas Informáticos y Programación Curso de

doctorado 1999 -2000 Patrones de diseño orientado a objetos.
• DesIgn Patterns: Elements of Reusable Object-Oriented Software
Gamma, Helm, Johnson, Vlissides Editorial AddisonWesley.
• Diseño y Programación Orientado a Objetos. Capítulo 4. Ingeniería
Informática Ingeniería Técnica de Informática de
Sistemas y Gestión Optativa. http://www.info-ab.uclm.es/asignaturas/42579

13