Ingeniera de Sistemas II

Decorator
Universidad Catlica de La Plata
Facultad de Ciencia y Tecnologa
Profesor: C. Sebastin Castaeda
 Decorator
Propsito

Asigna responsabilidades adicionales a un objeto

dinmicamente; proporcionando una alternativa flexible a la
herencia, para extender la funcionalidad.

Motivacin

Ejemplo del libro: asignacin de scrollbars y bordes a

componentes visuales de una interfaz.

Ingeniera de Sistemas II - UCALP 2

 Decorator
Aplicabilidad

Para aadir objetos individuales de forma dinmica y

transparente.
Para aadir responsabilidades que pueden ser retiradas.
Cuando la extensin mediante la herencia no es viable (explosin
de clases para permitir todas las combinaciones).

Ingeniera de Sistemas II - UCALP 3

Estructura Decorator
Cada componentes puede ser usado por si
mismo, o encapsulado en un decorator.
El componente
Cada decorator TIENE-UN
concreto es el objeto
componente. Significa que
que vamos a extender
el decorator tiene una
dinmicamente
variable de instancia que
agregando nuevo
referencia a un objeto de la
comportamiento
clase Component.
Decorator implementa la misma
interfaz o clase abstracta que el
componente que va a decorar.
El decorador concreto tiene una Los decoradores pueden
variable de instancia para extender el estado del
referenciar al "objeto" que Component
decora.
Los decoradores pueden agregar nuevos mtodos. Sin embargo, el nuevo comportamiento
es usualmente agregado realizando acciones antes y despus de la invocacin de un mtodo
del Component.
Ingeniera de Sistemas II - UCALP 4
 Decorator
Participantes
Component
Define la interfaz para los objetos a los que se les puede aadir
responsabilidades dinmicamente.
ConcreteComponent
Define un objeto al que se le pueden aadir responsabilidades
adicionales.
Decorator
Mantiene una referencia a un objeto Componente y define una interfaz
que se ajusta a la interfaz del Component.
ConcreteDecoratorA, ConcreteDecoratorB,
Aade responsabilidades adicionales al Component.
Ingeniera de Sistemas II - UCALP 5
 Decorator
Colaboraciones
El Decorador redirige las peticiones al Component y
opcionalmente puede realizar operaciones antes y despus de
redirigir la peticin.

Ingeniera de Sistemas II - UCALP 6

 Decorator
Consecuencias

Ventajas
Otorga mas flexibilidad que la herencia esttica -> aade y quita
responsabilidades en tiempo de ejecucin.
Evite clases cargadas de funciones en el tope de la jerarqua.
Desventajas
Proliferacin de objetos. Dificulta la comprensin y depuracin.
Identidad de objetos. Un componente decorado es el mismo
objeto (==) que dicho componente sin decorar?
Ingeniera de Sistemas II - UCALP 7
 Decorator
Resumen

La herencia es una forma de extensin; pero no es necesariamente la

mejor manera de obtener flexibilidad en nuestros diseos.
En nuestro diseos sera deseable poder extender el comportamiento
sin la necesidad de modificar el cdigo existente.
La composicin y delegacin pueden usualmente ser utilizadas para
agregar nuevos comportamientos en tiempo de ejecucin.
El patrn Decorator provee una alternativa a la subclasificacin para
agregar comportamiento.

Ingeniera de Sistemas II - UCALP 8

 Decorator
Resumen

El patrn Decorator involucra un conjunto de clases decoradores que

son utilizadas para envolver (wrappear) los componentes concretos.
Las clases Decorador espejan el tipo de los componentes que decoran.
(De hecho, tiene el mismo tipo que los componentes que decoran, ya
sea mediante implementacin por herencia o interfaces).
Los decoradores cambian el comportamiento de los componentes
agregando nueva funcionalidad antes y/o despus (o incluso en lugar
de) de las llamadas a los mtodos del componente.
Se puede wrappear/decorar un componente con cualquier numero de
decoradores.

Ingeniera de Sistemas II - UCALP 9

 Decorator
Resumen

Los decoradores son tpicamente trasparentes para el cliente que utiliza

el componente; esto es as, a menos que el cliente este tratando con el
tipo concreto del componente.
Los decoradores pueden generar la existencia de muchos objetos
pequeos en nuestro diseo, y su uso excesivo puede ser complejo.
Principio de diseo: Las clases deben estar abiertas para la
extensin, pero cerradas a las modificaciones.

Ingeniera de Sistemas II - UCALP 10