Written by 12:12 Design Pattern, DEVeloperS

Design Patterns

Una breve introduzione ai design pattern della GoF.

I design pattern descrivono semplici ed eleganti soluzioni a specifici problemi che periodicamente si riscontrano nella progettazione object oriented di un software. Dunque, sono soluzioni mature a problematiche comuni, raccolte (almeno inizialmente) da quattro dei più illustri personaggi nel panorama del software engineering: Erich GammaRichard Helm, Ralph Johnson e John Vlissides, al secolo conosciuti come la Gang of Four (GoF).

Un nuovo lessico?

I sopracitati Signori è come se avessero coniato un nuovo lessico per l’ingegneria informatica; un vocabolario di parole ognuna col preciso scopo di fornire una soluzione ad un problema già affrontato e risolto più volte.

Per certo, ci sarà capitato di utilizzare o sentire parole come “singleton“, “proxy“, “adapter” o “factory“, dandole per scontate ed assumendo che siano sempre esistite con l’odierno significato che le diamo. Tuttavia, è la GoF che ha fatto per l’ingegneria del software quello che Dante ha fatto per la lingua italiana: raffinando, creando e catalogando un gergo che ci permette, al pari di un buon romanziere, di far uso di collaudate frasi ad effetto per progettare e comporre dell’ottimo software.

Certo, è indubbio che esser il genio che tira fuori sempre la soluzione cervellotica, geniale o ad effetto dal cilindro fa comodo, ma, verosimilmente, è più sensato cercare di rientrare nel fisic du role di un semplice professionista con normali skill ma che segue ottime abitudini. Per l’appunto, queste abitudini frutto dell’esperienza di molti e figlie di una attenta progettazione sono i design pattern.

Va da se che l’applicazione di un design pattern non richieda eccezionali doti nel coding, bensì la volontà (traduci spesso anche in possibilità) di pagare nel breve un effort in termini di tempo o linee di codice ed ottenere alla lunga (e noi dovremmo sempre puntare a tramandare il nostro codice alle generazioni future) vantaggi in termini di flessibilità, riusabilità, modularità, manutenibilità e leggibilità del codice.

Niente male direi…

Cos’è un design  pattern?

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

A Pattern Language, Oxford University Press, 1977.

Questa è una definizione pensata per l’architettura di edifici e palazzi, tratta da un libro che è considerato una pietra miliare nel settore. Il libro in questione illustra un nuovo linguaggio, che gli autori chiamano un “pattern language” derivato da entità atemporali chiamati “pattern”. Tutti i pattern insieme formano un linguaggio ed ognuno offre una soluzione ad un problema in un determinato contesto.

eco design pattern

La definizione è applicabile anche alla progettazione/programmazione object oriented. Grazie al minuzioso lavoro dei quattro della GoF potremo riutilizzare soluzioni architetturali off-the-shelf da piazzare all’interno del dominio e rendere il mondo descritto dal nostro codice un ambiente migliore, più, lasciatemi passare il termine, ingegneristicamente-sostenibile. Ma occorre tenere anche ben presente che un design pattern è una formula, un template di soluzione che va adattato allo specifico problema architetturale da affrontare; nessuno ci regalerà linee di codice, quanto piuttosto dovremo essere noi a capirne l’applicabilità e metterlo in pratica.

Come è descritto?

Dal momento che i pattern trattano di progettazione, l’uso di diagrammi UML come il class diagram è quanto meno scontato. D’altro canto una pura ed esclusiva descrizione in termini grafici, seppure importante ed utile, non è sufficiente. Di fatti, essa cattura solamente una istantanea finale del processo di design, nella quale possiamo apprezzare gli oggetti o le classi e le relazioni che intercorrono tra di essi.

Piuttosto, per poter con efficacia riutilizzare un pattern, occorre anche tener presente le decisioni, le alternative ed i trade-off che hanno fatto virare verso quella soluzione. Ovviamente, nella trattazione anche gli esempi concreti possono risultare utili, poiché aiutano a vedere il design in azione in un preciso caso d’uso.

Detto ciò, segue che la descrizione di un pattern sarà costituita da un insieme di elementi che vanno a formare quel template uniforme, ben strutturato e consistente di cui si parlava prima. Entrando maggiormente nello specifico, avremo (o potremmo avere) queste sezioni nella descrizione del pattern:

  1. Nome e classificazione. Un buon nome è vitale perchè riassume l’essenza del pattern e diventa parte del nostro vocabolario.
  2. Intento. Una breve descrizione del problema e della soluzione.
  3. Altri nomi con la quale è conosciuto.
  4. Motivazione. Uno scenario che illustra un problema di design e come le classi e gli oggetti lo risolvono.
  5. Applicabilità. Descrive in quali situazioni è conveniente l’utilizzo de design pattern .
  6. Struttura. Un modello grafico della struttura del pattern (per lo più tramite class diagram UML).
  7. Partecipanti. Le classi e gli oggetti che partecipano e le loro responsabilità.
  8. Collaborazioni. Come i partecipanti collaborano per portare avanti le loro responsabilità.
  9. Conseguenze. E’ il trade-off da pagare ed i vantaggi risultanti nell’applicazione del pattern.
  10. Implementazione.
  11. Codice esemplificativo.
  12. Esempi del pattern in sistemi reali.
  13. Pattern correlati.

Catalogo e classificazione.

I design pattern possono variare per livello di astrazione o granularità, per cui è stato necessario organizzarli e classificarli. La classificazione, inoltre, è anche un metodo per rendere più pratico e veloce la scelta del pattern.

Un primo criterio di classificazione è il purpose, che riflette lo scopo e cosa un fa il pattern. Secondo questa classificazione, sono possibili tre tipologie, ovvero: creational, behavioral o structural.

Classificazione design pattern
  • Creational pattern: si preoccupano del processo di creazione degli oggetti.
  • Behavioral pattern: caratterizzano il modo con cui le classi e gli oggetti interagiscono.
  • Structural pattern: hanno a che fare con la composizione di classi od oggetti.

Inoltre, un secondo criterio di classificazione è lo scope e specifica se il pattern si applica principalmente alle classi o agli oggetti (le istanze di classe). In questo caso possiamo avere, quindi:

  • Class patterns: riguardano le relazioni tra classi e rispettive sottoclassi. Sono relazioni di ereditarietà, quindi stabilite staticamente a runtime.
  • Object patterns: viceversa riguardano relazioni dinamiche che cambiano a runtime, ovvere quelle che si instaurano tra istanze di oggetti.

Non mi dilungo oltre per questa introduzione. Piuttosto, vi rimando alla lettura dei vari pattern e vi lascio con un paio di consigli sempreverdi che vengono rimarcati spesso nei pattern e che valgono sempre per il mondo object oriented:

Program to an interface, not an implementation.

Favor object composition over class inheritance.

(Visited 211 times, 1 visits today)
Close