Decorator

Fra tanti pattern utili il decorator troneggia, anche se potrebbe non esser sempre chiaro lo scopo, o dove come quando applicarlo.

Tecnicamente parlando il decorator non fa altro che "estendere una base" e aggiungere "qualcosa".

Nel caso in esempio, esiste una classe Generic Item che è descritta da due proprietà e due metodi.
Le proprietà appartengono a Generic Item
I metodi sono virtuali (ossia) esiste la firma e volendo il codice del metodo, ma potrà essere esteso.

La classe book, estende Generic Item aggiunge due proprietà ed esegue l'override dei due metodi.
La classe brochure , estende Generic Item aggiunge una proprietà ed esegue l'override dei due metodi.

E' pur logico che il modo di Editare un libro sia diverso dal modo di Editare una brochure e tanto vale anche
per il modo in cui esse verranno visualizzati.

La classe astratta decorator ha un compito Creare Oggetti che abbiano come BASE Generic Item.

La classe coDecorator effettuerà il management di ciò che il decorator ha creato.

Ciò Detto ..
E' facile intuire quanto sia semplice individuare i casi d'uso, il rischio e che offuscati dalla voglia di utilizzare questo
pattern lo si "infili" un po da tutte le parti.

Un caso comune potrebbe essere la necessità di aggregare ad una classe Entity le sue derivate.

Utente e Utente Esteso
la classe utente (la nostra Generic Item ) contiene Nome Cognome, Login, Password
la classe utente Esteso (la nostra brochure o book) contiene in più Numero matricola, interno telefonico, sede di lavoro...

I dati della prima classe risiedono sulla tabelle Utenti mentre i dati di utente esteso potrebbero provenire da Ldap.

Per cui in Decorator creeremo UtenteEsteso e in coDecorator Popoleremo i dati.