Pattern Decorator

Summary Un design pattern che aggiunge responsabilità al singolo oggetto dinamicamente a run-time invece che all'intera classe a staticamente design-time con l'ereditarietà.

Conosciuto anche come

Wrapper o Wrap Class. Anche il PatternAdapter viene chiamato Wrapper.

Intento

Il design pattern Decorator aggiunge responsabilità in modo dinamico, ossia a run-time, ad un singolo oggetto senza richiedere l'uso della ereditarietà che invece aggiunge responsabilità alla classe, e quindi a tutti gli oggetti istanziati, ed in modo statico ossia già a design-time.

Le responsabilità (ConcreteDecoratorA, ConcreteDecoratorB,...) vengono aggiunte dinamicamente all'oggetto (ConcreteComponent) a run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Strutturali.

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

Il alcuni casi si presenta l'esigenza di aggiungere o rimuovere una responsabilità ad un singolo oggetto, in altri casi il numero responsabilità distinte è così elevato da far esplodere le di possibili combinazione di responsabilità e classi che dovrebbero essere create se si una l'ereditarietà.

In tutti questi casi il design pattern Decorator è utile.

Esempi d'uso in .NET

Un esempio di ConcreteDecorator in .NET è BufferedStream che può essere applicato a diversi ConcreteComponent quali ad esempio CryptoStream, NetworkStream o FileStream per leggere lo stream con la modalità desiderata (ad esempio byte per byte) lasciando che lo stream sottostante venga letto con il buffer ottimizzato per quel particolare stream.

XmlValidatingReader e XmlTextReader sono due possibili ConcreteDecorator che possono essere applicati a XmlReader. Il primo valida il documento Xml letto dal XmlReader rispetto ad uso schema, il secondo controlla solamente che il documento Xml letto dal XmlReader sia ben formato.

Note sulla implementazione in .NET

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Il PatternComposite può usare il design pattern Decorator per far si che i figli aggiungano responsabilità al nodo padre e quindi ogni nodo foglia rappresenti una diversa catena di responsabilità.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

L'utilizzatore (Client) avrà un riferimento quindo all'ultimo ConcreteDecorator aggiunto e non direttamente al ConcertComponent. Rispetto al'interfaccia che vede l'utilizzatore non cambia nulla, ossia la presenza di un Decorator è del tutto trasparente. Rispetto l'identità dell'oggetto referenziato (ossia il ConcreteDecorator) se si fa ad esempio un ReferenceEquals non è più quella di ConcertComponent ma è un'altra (quella del ConcreteDecorator).

Domande di approfondimento

Se il ConcreteDecoratorA di ConcreteComponent ha un metodo X che non è metodo di ConcreteComponent e il Client può richiamare il metodo X, allora ConcreteDecoratorA non è più un Decorator nel senso stretto del design pattern?
Perchiò, perché è importante che il Decorator di un oggetto abbia la medesima interfaccia del Component che va a decorare?
Che differenza c'è tra questo design pattern e il PatternAdapter?
Che differenza c'è tra questo design pattern e il PatternComposite in cui il component ha un solo figlio?
Che differenza c'è tra questo design pattern e il PatternStrategy?

Link

VediAnche CatalogoDeiDesignPattern