Programmo Subito

Supponiamo di dover implementare un ambiente di disegno per la realizzazione di interfacce grafiche. Questo ambiente dovrà permettere di disegnare una finestra che contenga al suo interno diversi tipi di control, come pulsanti, textbox e scrollbar. Alla pressione del pulsante Save il programma dovrà salvare il contenuto della finestra all’interno di un file di testo o di un database.

Per implementare questo programma si potrebbe scegliere di definire delle classi DesignButton, DesignTextBox e DesignScrollBar che forniscano sia le necessarie funzionalità di tipo grafico, sia la capacità di salvare i propri attributi nel formato prescelto.

Questa soluzione, però, presenta dei problemi. Prima di tutto, le classi necessarie sarebbero moltissime, una per ogni tipo di control disponibile. Inoltre, la gestione di un nuovo tipo di control non inizialmente previsto comporterebbe la necessità di definire una nuova classe, con conseguenti problemi di manutenzione dell’applicazione.

Questo pattern fornisce una soluzione al precedente problema, introducendo l’idea di estendere le potenzialità di una classe non tramite la definizione di una sottoclasse, ma attraverso l’aggiunta di proprietà a run time alle sue istanze.

In pratica, invece di definire delle classi separate per ognuno dei control che potrebbero essere disegnati all’interno della finestra, il pattern propone di creare un’unica classe DesignControl, a cui aggiungere, come "decorazioni", una lista di proprietà. In questo modo, ogni istanza della classe potrebbe avere delle proprietà differenti, per rappresentare diversi tipi di control.

Ecco una definizione più precisa di questo pattern.

• Nome: Decorator.
• Categoria: progettazione del software.
• Problema affrontato: in alcuni sistemi può essere necessario creare un gran numero di classi con poche differenze tra di loro. Questo può causare notevoli problemi in fase di manutenzione del programma.
• Soluzione: invece di creare tante classi diverse, si crea un’unica classe (o una piccola gerarchia di classi), fornendo la possibilità di aggiungere a run-time delle proprietà alle sue istanze.
• Applicabilità: questo pattern è applicabile solo nel caso in cui le differenze tra le varie classi siano modeste e comunque tali da permettere di incapsulare il codice necessario per la loro gestione all’interno di un’unica classe base. In particolare, Decorator risulta utile qualora le varie proprietà aggiunte a runtime debbano essere gestite in maniera uniforme e prevedibile (per esempio, caricate da file, proposte all’utente per essere modificate e quindi salvate).

Una possibile implementazione di questo pattern è mostrata in Figura 1. La classe base Classe contiene una lista di istanze di Componente. Queste istanze rappresentano le proprietà che possono essere aggiunte a runtime. Eventuali sottoclassi di Classe ereditano la gestione di questa lista e possono quindi usufruire della possibilità di aggiungere "decorazioni" alle proprie istanze. La classe Componente, che può essere anche una classe astratta o una semplice interfaccia, può a sua volta essere derivata per definire diversi tipi di "decoratori".

I pattern inclusi in [1] rimangono in assoluto i più diffusi ed utilizzati. Nonostante non sia uno dei pattern più noti, Decorator è molto utilizzato. Personalmente, mi è capitato di usarlo in due progetti e in entrambi i casi ha costituito una soluzione ottimale.

[1] E.Gamma, R.Helm, R.Johnson, J.Vlissides, "Design Patterns: Elements of reusable object-oriented software", Addison-Wesley, 1995