I Design Pattern

_Logo I Design Pattern sono una soluzione progettuale a problemi comuni che si ripetono continuamente. Essi non definiscono una specifica implementazione ad un problema ma offrono le linee guida per delineare, capire ed affrontare il problema. Si parla di soluzione ben documentata ed espressa con un linguaggio ben definito.

Quando si parla di Design Pattern si è soliti citare la cosiddetta Gang of Four, quattro autori che con il testo Design Patterns Elements of Reusable Object-Oriented Software hanno delineato il concetto di design pattern nell'informatica. Il libro illustra un catalogo di 23 pattern che, nonostante risalgono al 1994, sono tuttora validi. Ciò che è cambiato sono gli strumenti utilizzati per implementare il modello delle soluzioni proposte.

E' interessante notare che la definizione di pattern deriva dal testo A pattern language di C. Alexandaer, pubblicato nel 1977 e dedicato all'architettura, non quindi allo sviluppo software. Il concetto di pattern si applica infatti in diverse discipline: là dove c'è un problema ricorrente si offre una soluzione altrettanto ricorrente. Vediamo quindi la definizione:

I pattern descrivono un problema che si verifica continuamente nel nostro ambiente e descrivono il cuore della soluzione a quel problema in un modo che la soluzione può essere usata altrettanto continuamente, senza doverla fare nello stesso modo due volte

Tipicamente l'argomento appare molto più complesso di quello che è, visto che in realtà molti dei pattern definiti sono talmente diffusi e integrati nei sistema di sviluppo e nei framework che non ci si accorge di usarli. E' comunque preferibile non ignorarne la definizione e saperli indentificare in modo da non sottovalutarne le relazioni con altri pattern ne gli eventuali effetti collaterali. Bisogna anche ricordare che i design pattern sono *concetti e quindi soggettivi ad una certa interpretazione (e soprattutto a diverse implementazioni).

Un esempio banalissimo di problema comune è quello di iterare tra gli elementi di una collezione o sequenza: la sua ovvia soluzione è modellata con un design pattern. In modo analogo la necessità di estendere un oggetto senza modificarlo (perché magari non ne abbiamo il codice sorgente) è risolto da un altro design pattern. Un altro tipico esempio riguarda il ricevere una notifica quando un processo è finito o vi è un cambio di stato.

Ecco quindi i pattern Iterator, Observer, Proxy, Facade che sono così diffusi che li utilizziamo, magari grazie al codice auto generato da Visual Studo, senza saperlo. Ma conosciamo effettivamente le conseguenze che comportano?

Come detto i design pattern non offrono un'implementazione ma un modello che è indipendente dal linguaggio o dall'ambiente di sviluppo: il come implementare tale modello lo decidiamo noi e spesso, sempre nell'ottica del DDIY (Don't Do It Yourself), vi sono Framework o strumenti che ne offrono un’implementazione per l’ambiente in cui operiamo.

I design pattern sono quindi modelli di soluzione e vengono catalogati in base al contesto della problematica che considerano. La definizione di un design pattern, così come presentata dai più comuni cataloghi di pattern, ha la seguente struttura:

  • Nome: il nome deve essere ovviamente univoco, ma succedere che uno stesso pattern abbia più di un nome.
  • Motivazione: il problema comune da risolvere.
  • Applicabilità: possibili scenari di utilizzo.
  • Scopo: il modello della soluzione, che è spesso articolato definendo:
  • Struttura
  • Partecipanti: quindi gli elementi da gestire e le loro responsabilità.
  • Collaborazione: interazione tra gli elementi definiti.
  • Conseguenze: come accennato ogni pattern ha un costo da valutare con i benefici che apporta.
  • Esempi: eventuali esempi, magari riferiti ad uno specifico ambiente/linguaggio.

La definizione dei design pattern ha i seguenti vantaggi:

  • Descrivono un problema e una soluzione definita da specialisti del settore e valutata dall'intera comunità nel corso degli anni.
  • Utilizzano un vocabolario condiviso dalla comunità che permette inoltre di esprimersi in modo conciso.
  • Permette di concentrarsi il più lungo possibile sul design del proprio software, sull'astrazione generale e passare all’implementazione in un secondo momento, quando è stato definito quale soluzione adottare.
  • L'utilizzo ne diffonde l'uso e quindi incoraggia gli altri sviluppatori a comprenderli e ad usarli.

La Gang of Four ha definito tre categorie di pattern che ripropongo anche in questa mia sezione:

  • Creational patterns: riguarda il come istanziare gli oggetti
  • Structural patterns: come sono composti i vari elementi del sistema
  • Behavioral patterns: algoritmi e assegnazione delle responsabilità tra oggetti

Riferimenti:

Tag: Design Pattern, GoF