Skip to content

Design Patterns

February 9, 2010

Norme di buona programmazione ad oggetti

Conosci i pattern? Questa e’ una domanda che prima o poi qualsiasi sviluppatore software si sentira’ fare, o si porra’ da solo. Mitizzati da alcuni, trascurati piu’ o meno volutamente da altri, i pattern, meglio noti come “design patterns”, rappresentano per la progettazione software l’analogo di quelle norme pratiche, tecniche o accorgimenti basilari che costituiscono il fondamento di ogni arte o mestiere.
L’unica differenza e’ che, mentre la maggior parte dei mestieri con una certa dose di creativita’ provengono da una lunga tradizione e i loro procedimenti sono quindi in qualche modo “standardizzati”, quello del programmatore (ad oggetti) e’ un mestiere relativamente recente, e ancora quindi non perfettamente delineato nei suoi canoni. Era inevitabile quindi che un giorno qualcuno si rendesse conto che era il caso di porre ordine in questa situazione, e di provare quindi a delinerare le “regole
del buon programmatore”.

La “banda dei quattro”

Fu cosi’ che nel 1994 un gruppo di 4 persone formato da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides diede alla luce il libro che traccio’ per la prima volta le linee guida della buona programmazione ad oggetti: “Design Patterns: Elements of Reusable Object-Oriented Software”. Destinata fin da subito a diventare una delle pietre miliari della letteratura del software, l’opera dei quattro non fu chiaramente realizzata partendo da zero. Il loro lavoro infatti fu quello di trascrivere, astraendole dalle contingenze, le soluzioni migliori a loro note fino ad allora trovate nel campo della programmazione, ordinandole secondo strutture logiche ben definite e dando loro un nome preciso.
Sorprendentemente, alla fine di questo imponente lavoro, venne fuori che tutto questo insieme di soluzioni si rifaceva in summa a soltanto tre casistiche ben definite: la creazione, la composizione e il comportamento degli oggetti.

Incapsulare il concetto che cambia

Molti e importanti sono i principi alla base di queste soluzioni. Norme comuni di buon senso come “favorire la composizione rispetto all’ereditarieta'”, “ridurre le interdipendenze tra gli oggetti” e via dicendo trovano in questo catalogo motivazioni teoriche e dimostrazioni pratiche. Ma in particolare c’e’ un principio, davvero trasversale a tutti i pattern, il quale a mio avviso raccoglie in se’ tutto lo spirito dei design patterns e quindi della buona programmazione ad oggetti.

L’incapsulamento, tra le caratteristiche dei linguaggi Object Oriented, e’ forse quello piu’ difficile da far proprio per i neofiti della programmazione. Non tanto perche’ sia un concetto di per se’ ostico da capire – del resto viviamo in un mondo fatto di oggetti molto incapsulati, sia naturali che artificiali; quanto perche’ in fase di progettazione stabilire cosa davvero un oggetto debba esporre attraverso la propria interfaccia, e cosa no, sembra in partenza una questione in qualche modo soggettiva, o che comunque richieda una certa dose di esperienza per essere applicata al meglio.

Il manuale dei pattern ci insegna invece un principio fondamentale da seguire per essere sicuri di ottenere un buon livello di incapsulamento, e quindi un buon design, nel proprio software.

Il principio e’ quello di “incapsulare il concetto che cambia”.

Una volta studiato un problema, cioe’, si devono individuare quei fattori che possono “cambiare” nel tempo e nel luogo, allo scopo di rendere il nostro design il piu’ adatto a rispondere correttamente a questi cambiamenti. La progettazione deve quindi mirare ad isolare le parti passibili di cambiamenti in punti ben definiti, mascherando la complessita’ alle altre parti: ne viene fuori quindi un sistema “modulare” in cui ogni “pezzo” svolge un compito ben preciso, del cui svolgimento pero’ nulla e’
visibile alle altre parti del sistema.
Per esempio, se progettiamo un’applicazione grafica, ci sono molti fattori che possono variare nel “luogo”: l’ambiente di esecuzione, le librerie grafiche a disposizione, la risoluzione dello schermo etc., e nel “tempo”: una connessione di rete che puo’ andare su e giu’, un aggiornamento di pacchetti etc.

Nella programmazione ad oggetti un buon incapsulamento e’ alla base della stabilita’ e della longevita’ del software, intesa quest’ultima sia come manutenibilita’ che come vita vera e propria.
Un modello ad oggetti ben incapsulato e’ infatti facile da modificare: oltre ad essere nel complesso piu’ semplice da capire, un codice ben incapsulato dentro una classe puo’ essere modificato senza impattare sul resto del modello ad oggetti.
E un modello facile da modificare e manutenere e’ una carta vincente per un software che mira ad essere utilizzato con successo a lungo e da molte persone.

Un esempio

Vediamo un esempio di questo concetto: il pattern Builder.

Builder pattern

Lo scopo di questo pattern creazionale e’ quello di astrarre la costruzione di oggetti di cui si conosce la logica di base, ma i cui singoli dettagli (i “pezzi” della costruzione) possono variare o non sono noti in fase di design. Esempi di queste situazioni sono le pagine web composte da moduli custom (es. portlet), oppure le interfacce grafiche con look and feel e/o layout personalizzabile o variabile secondo il sistema (es. swing l&f), etc. Come si puo’ notare, il pattern Builder affronta il problema della variabilita’ di costruzione dei componenti incapsulandone il concetto nell’interfaccia AbstractBuilder.
Il creatore dei prodotti finali, il Director, e’ in grado di assemblare il prodotto finale pur non conoscendo nulla della logica stessa di creazione delle singole parti. Il design che ne risulta e’ altamente flessibile e facilmente manutenibile: la modalita’ di creazione dei pezzi puo’ essere modificata a piacimento senza impattare nel risultato del prodotto finale.

Conclusione

La conoscenza dei design pattern e’ una base fondamentale nella progettazione di buon software. Ancora piu’ importante pero’ e’ far propri i principi che stanno alla base dei pattern stessi, in modo da essere in grado di procedere da soli anche quando le problematiche da affrontare sembrano non immediatamente riconducibili ai casi rappresentati nel catalogo. E perche’ no, magari scoprire da soli un nuovo, fantastico design pattern.

Author: Davide Deidda

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: