Design Patterns

Da Skypedia.

Una delle definizioni di Design Pattern è la seguente: "una soluzione comprovata ad un problema ricorrente". Il contesto della definizione è quello della programmazione ad oggetti (OOP) e in particolare quello della progettazione della soluzione del problema. Analizziamo allora la definizione data.

  • I problemi che vengono affrontati con i Design Patterns sono ricorrenti. Ciò vuol dire che i D.P. non permettono di risolvere qualsiasi problema ma solo quelli relativi ad alcune classi note e che si ripresentano frequentemente durante la progettazione di molte classi di software.
  • La soluzione proposta da un D.P. è comprovata. Questo vuol dire che coloro i quali hanno affrontato il problema in precedenza non hanno soltanto cercato di dare una soluzione al problema ma ne hanno anche ricercato i limiti e le possibilità di estensione. La soluzione offerta da un pattern allora sarà:
    • corretta;
    • efficiente;
    • solida;
    • performante.

La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software.


Storia e origine

Per quanto possa sembrare strano l'origine dei Design Pattern non è da attribuirsi all'ambito dell'Ingegneria del software, bensì agli studi di progettazione di un architetto austriaco che si chiama Christopher Alexander. Il mutuare il concetto di pattern e le sue implicazioni fu abbastanza semplice visto che comunque essi danno risposta a delle domande concettuali che ricadono in un ambito puramente logico e che si applicano bene all'OOP basata infine sugli ADT.

La nascita dei design pattern nell'ambito dell'ingegneria del software avvenne ad opera della Gang of Four, nome con cui si fa riferimento agli autori del libro "Design Patterns: elements of reusable Object-Oriented software" che per l'appunto sono:

  • Erich Gamma
  • Richard Helm
  • Ralph Johnson
  • John Vlissides

Principi dei design patterns

Open-Closed Principle

L'OCP afferma che un prodotto dovrebbe essere "aperto" alle estensioni ma "chiuso" alle modifiche. Il principio può essere facilmente espresso con il seguente concetto: "Identifica la parte del tuo codice che cambia ed incapsulala".

Single Responsability Principle

Il SRP afferma che un oggetto dovrebbe avere dei metodi per manipolare solo un singolo aspetto di un dato problema. Quindi è bene dividere la propria applicazione affinché ogni blocco abbia una singola responsabilità.

Casi di studio


Risorse