Design Pattern
di Gianluca Torta

Introduzione

Quando nel remoto 1979 l'architetto Cristopher Alexander scrisse "The Timeless Way of Building" e introdusse così al mondo il concetto di pattern, verosimilmente(!) non pensò che avrebbe trovato la sua maggiore applicazione nel design di sistemi Object Oriented.

Difatti, si deve attendere l'OOPSLA 1987 perché Cunningham e Beck ne facciano una presentazione alla comunità OO, e addirittura il 1995, anno di pubblicazione di "Design Patterns: Elements of Reusable Object-Oriented Software" perché i pattern siano formalmente consacrati a importante innovazione per la progettazione OO.

La descrizione di ciò che ho imparato da questo libro del GoF (Group of Four, il nomignolo affibiato ai quattro autori, per la verità non molto originale) e di come ho faticosamente (!) tentato di metterlo in relazione con l'informatica reale con cui mi scontro ogni giorno al lavoro, sarà il principale tema dell'articolo completo.

Intanto, vorrei tentare di dare almeno un'idea, a chi non li conoscesse, di che cosa siano i pattern.

Partiamo dalla descrizione che ne dà il loro ideatore Alexander: "Ciascun pattern descrive un problema ricorrente e la sua soluzione, in modo tale che si potrà riusare questa soluzione un milione di volte, senza mai farlo allo stesso modo due volte".

Francamente, la prima volta che ho letto questa definizione su una rivista [GLR97a], due anni fa, la mia reazione è stata - la prima parte è troppo vaga ("soluzione a un problema"); la seconda incomprensibile ("riusare un milione di volte diversamente").
Eppure, rileggendola dopo aver preso un po' di confidenza coi pattern, si riconosce che ne cattura bene l'essenza.

Nella introduzione a [Gof95], si legge qualcosa che inizia a illuminarci un po' su questi misteriosi pattern; un pattern è composto essenzialmente da 4 elementi:

un Nome

questa componente del pattern non è trascurabile perchè permette alla "comunità dei pattern" di comunicare rapidamente e in modo non ambiguo riferendosi esclusivamente al Nome del pattern. Come si vedrà, questo può portare a sviluppare un gergo per esprimere soluzioni che coinvolgono diversi pattern in relazione tra loro

un Problema

un pattern serve essenzialmente a risolvere una classe di problemi; deve essere chiaro, da questa sezione del pattern, se il problema reale che abbiamo sotto mano rientra o meno in tale classe. In caso affermativo, il "Problema" ci fornisce un modello astratto (ma non troppo!) che verrà usato nella sezione successiva per fornire la soluzione

una Soluzione

dato il modello della classe di problemi, in questa sezione se ne descrive una soluzione abbastanza astratta da "essere applicata un milione di volte", ma abbastanza precisa da poter essere immediatamente codificata da chiunque conosca un linguaggio OO (C++, Java, Smalltalk, ...); in [GoF95] gli autori usano la notazione OMT

delle Conseguenze

un pattern spesso può stimolare una riflessione su come migliorare il proprio design anziché fornire una soluzione definitiva. Questa sezione è importantissima per capire quali sono i vantaggi e i possibili svantaggi nell'uso del pattern; spesso, vi si trovano citati pattern che affrontano lo stesso problema privilegiandone aspetti diversi (per esempio la flessibilità contro l'efficienza)

Questo ha (spero) chiarito abbastanza la natura dei pattern, con l'avvertenza che è probabilmente necessario studiarne qualche semplice esempio pratico per poter considerare conclusa la prima fase di conoscenza (per questo ho riportato un breve e discorsivo esempio di pattern poco sotto, al termine di questa introduzione).

Ancora il GoF ci viene in aiuto nell'introduzione di [Gof95] spiegandoci il perché dei pattern. Da esperti progettisti OO, i "quattro" si sono accorti della difficoltà di questo lavoro, e di come solo una lunga esperienza possa evitare a persone anche molto brave di cadere in classici errori di ingenuità che si pagano poi a caro prezzo in tempo/denaro o qualità del sistema.

Il "gap" tra un progettista esperto e uno alle nuove armi, secondo i nostri, è proprio la memoria di soluzioni che aveva già applicato con successo, magari dopo qualche tentativo fallito, in progetti precedenti. Il designer esperto riconosce le similitudini salienti (e le differenze) rispetto al problema di cui ricorda la soluzione, ed è in grado di intuire che cosa può "riusare" (in senso ampio, non solo di riuso di componenti software) di essa nel contesto attuale, e che cosa no.

I pattern sono proprio un modo "to record experience in designing object-oriented software".
Ed ora, prima di darci appuntamento al prossimo articolo per un maggior approfondimento, un piccolo "assaggio" per sentire il sapore di un pattern vero e proprio.

Assaggio di un pattern

Questo pattern è liberamente tratto dal sito [wAGCS]; l'ho riadattato al nostro schema (Nome-Problema-Soluzione-Conseguenze) per maggior consistenza, ma, come si vede, tale schema non è assolutamente rigido (tanto che lo stesso GoF ne usa uno più esteso).
Ciò che è importante è che, qualunque sia il modo usato per presentare un pattern, esso non ne tradisca lo spirito. Enjoy!

Nome

Don't Flip the Bozo Bit

Problema

Come si può migliorare la comunicazione in un gruppo, in modo che tutti siano più aperti alle nuove idee?
(il gruppo condivide un obiettivo di tipo creativo come, per esempio, lo sviluppo di software).
In un'attività di questo genere, più intelletti lavorano, migliore è la qualità del prodotto. Molte persone, però non vogliono pensare, credono di pensare ma non lo fanno. Quando qualcuno si presenta a un altro con un'idea o un commento, quest'ultimo si trova di fronte a un dilemma: l'informazione ha valore, o la persona che la sta comunicando è uno stupido.
Spesso egli propende per la seconda ipotesi, il che porta a un conflitto attivo o passivo che sia.
Nessuno presta attenzione a uno stupido, per quanto concerne il suo contributo al prodotto è un peso morto; è possibile rivoltare su se stessi questo atteggiamento, convincendosi di non avere la capacità o la forza per proporre delle idee.
Le principali "forze" che agiscono in questo contesto sono:

• è gratificante avere qualcuno che ascolta le tue idee; è ancor più gratificante quando vengono generalmente accettate
• le buone idee sono contagiose; chiunque ascolti una buona idea sentirà un po' del piacere inerente nella creatività
• le idee sono moltiplicative; una volta scardinata qualche assunzione errata con una buona idea, altre idee cominciano a generarsi
• le persone sono sulla difensiva; l'atto di creare con l'intelletto richiede un forte investimento emotivo e creativo.
  Critiche o idee migliori possono essere prese come "attacchi personali"
• le persone sono sensibili al rifiuto e possono reagire aspramente se le loro idee sono state rifiutate per paura o altre motivazioni non valide

Soluzione

Ogni persona deve essere coinvolta nel "gioco": tutti possono contribuire. Chiunque ha un'idea su come ridurre i tempi di lancio sul mercato, o come effettuare tale lancio. Tutti devono pensare in questo modo.
Ognuno deve guardare dentro se stesso e tentare di rendere corretta la propria parte nella comunicazione. Se l'ascoltatore ha problemi a recepire il nostro discorso, cerchiamo di semplificarlo, o almeno spieghiamo la nostra situazione e la nostra frustrazione. Se abbiamo l'impressione che qualcuno continui a fornirci idee e commenti scadenti, consideriamo se qualche pregiudizio difensivo non stia offuscando il nostro giudizio.

Conseguenze

Il segno più chiaro che le persone stanno pensando è quando ascoltano le idee degli altri e fanno critiche costruttive.
Reprimono l'atteggiamento competitivo per una linea di pensiero superiore. Chiedono a se stessi la disciplina intellettuale per valutare con correttezza informazioni nuove e potenzialmente valide. Riescono a filtrare gli aspetti della comunicazione legati al proprio ego.