Asignar nuevas responsabilidades a un objeto dinámicamente. Es una alternativa a la creación de subclases por herencia.
También Conocido como:
Agregar funcionalidad "de adorno" a un objeto.
Una forma de lograrlo es añadiendo responsabilidades con la herencia, de una frontera de otra clase pone un borde alrededor de cada subclase instancia. Esto es inflexible, sin embargo, debido a la elección de la frontera se hace estáticamente. Un cliente no puede controlar cómo y cuándo decorar con un componente de la frontera. Un enfoque más flexible para incluir el componente en otro objeto que añade la frontera. Adjuntando el objeto se llama un decorador. El decorador se ajusta a la interfaz del componente que decora de manera que su presencia es transparente a la del componente clientes. El decorador remite las solicitudes de los componentes y puede realizar acciones adicionales (por ejemplo, dibujar una frontera) antes o después de transmisión.
Los participantes :
• Component:
Define la interfaz que ofrecen los objetos que poseen responsabilidades añadidas dinámicamente.
•ConcreteComponent:
Define un objeto al que responsabilidades adicionales pueden serle añadidas.
•Decorator:
Mantiene referencia a un objeto Component y define una interfaz que conforma la interfaz del Component.
•ConcreteDecorator:
Añade las responsabilidades al Component.
Decorator envía las solicitudes a su componente de objeto. Puede opcionalmente realizar operaciones adicionales antes y después del envío de la solicitud.
Consecuencias:
Más flexibilidad que la herencia de clases (estática): El patrón Decorator proporciona una forma más flexible para añadir funciones a los objetos que puede ser mantenido con estático (múltiple) de herencia. Con decoradores, las responsabilidades pueden ser añadir y suprimir en tiempo de ejecución simplemente conectar y desconectar por ellos. En contrario, la herencia exige la creación de una nueva clase por cada responsabilidad (por ejemplo, BordeedScrollableTextView, BorderedTextView). Esto da lugar a muchas clases y aumenta la complejidad de un sistema. Además, proporcionando diferentes clases Decorator para un Componente de clase le permite mezclar y combinar las responsabilidades.
Permiten añadir una propiedad más de una vez: Decoradores también hacen más fácil para agregar una propiedad dos veces. Por ejemplo, para dar TextView una doble frontera, simplemente conectar dos BorderDecorators. Heredar de una frontera de clase dos veces es propenso a errores, en el mejor.
Evita cargados clases alto de la jerarquía: Decorator ofrece un "pay-as-you-go para añadir responsabilidades. En lugar de tratar de apoyar todas las características previsibles en un complejo, personalizable clase, puede definir una clase y añadir funcionalidad incremental con Decorator objetos. Funcionalidad puede ser simple, compuesto de piezas. También es fácil de definir nuevos tipos de Decoradores independientemente de las clases de objetos se extienden, incluso para imprevistos extensiones. La ampliación de un complejo de clase tiende para exponer los detalles que no estén relacionados con las responsabilidades que estás agregando.
Un Decorator y su Component no son idénticos. Desde el punto de vista de la identidad de los objetos, un DecoratorComponent no es identico al Component. Por esto no se puede confiar en en la identidad de los objetos cuando se usan Decorators; dado que el patrón Decorator hace que hayan muchos objetos pequeños que son muy parecidos.
Implementación:
El siguiente ejemplo permite que un texto tenga diferentes presentaciones en cuanto a su tipo de fuente, color y tamaño.
package logicad;
import java.awt.Color;
import java.awt.Font;
import javax.swing.JTextArea;
/**
*
* @author Katherin
*/
public abstract class Componente {
protected int aumento = 10;
protected Font fuente;
protected int tipoLetra = Font.ITALIC;
protected Color color;
protected JTextArea pizarra;
public JTextArea getTablero() {
return pizarra;
}
public void setTablero(JTextArea a) {
pizarra = a;
}
public int getSize() {
return aumento;
}
public void setSize(int tam) {
aumento = tam;
}
abstract public void operacion();
}
Usos conocidos:
Muchos Toolkits de interfaz de usuario orientados a objetos utilizan decorator, para añadir decoraciones gráficas.
Patrones Relacionados:
- Decorador vs. Strategy: el Decorador puede actuar antes o después de llamar a los métodos de otro objeto, para cambiar lo que se hace en medio de la llamada a un método se usa el patrón Strategy.
- Es distinto del Adaptador ya que sólo añade responsabilidades a un objeto, no su interfaz.
- Puede verse como un caso degenerado de Composite con un solo componente. Sin embargo, el decorador añade responsabilidades.
Referencias:
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 Addison-Wesley.
No hay comentarios:
Publicar un comentario