Richard C. Martin, autore di Clean Code, noto con il soprannome di Zio Bob ha cambiato il modo di scrivere codice professionalmente… ma non solo!

Acquisire le pratiche descritte nel suo manuale può sembrare inizialmente complesso ma diventa uno state of mind nell’istante stesso in cui ci si rende conto di quanto diventi più semplice, rapido e sicuro manutenere il proprio codice.

Non cercheremo di riassumere qui un testo diventato un vero e proprio manifesto noto come Metodologia Agile, o per meglio dire: ci limiteremo ai cosiddetti cinque principi SOLID, che già ci riescono con un certo ordine.

Single responsability

Il primo principio SOLID ci insegna che ogni classe o modulo di codice deve avere un’unica responsabilità. Intuitivamente è vantaggioso separare i contenuti dall’interfaccia (per esempio questa pagina web). Così facendo per esempio potremo sostituire il web con un’app per cellulari o uno script in linea di comando. Ma questo principio dovrebbe essere applicato a ogni altro componente. La logica di business non deve contaminarsi con la lettura e scrittura su Database o con i componenti che dialogano in rete e così via.

Open to extension, closed to modification

Il secondo principio è il più semplice da capire e il più difficile da rispettare. Scoraggia le modifiche al codice stabile, quello che funziona da mesi o anni in produzione, invitando invece a estendere nuove sottoclassi, isolando i frammenti meno stabili in modo che non abbiano impatto sul codice esistente. Fanno eccezioni le operazioni di hot fix.

principio di sostituzione di Liskov

Barbara Liskov e Jeannette Wing sono due ricercatrici autrici del terzo principio SOLID. E’ il principio più complicato da capire ma incredibilmente utile e divertente (perché no?) da rispettare!

Probabilmente lo usate già. Molti linguaggi moderni hanno infatti strutture di memoria dichiarate come iterabili. Di norma sono accomunate da una serie di metodi con nomi come first(), next(), count()… a volte possono essere utilizzati in metodi for o foreach che li percorrono automaticamente. e soprattutto sono mutuamente sostituibili. Questo è possibile perché ciascuna struttura di memoria (che facilmente è una classe fornita dal linguaggio) utilizza la stessa interfaccia, diventando intercambiabili.

L’enunciato del principio di Liskov dice appunto che le classi figlie devono essere sostituibili dalla classe padre. Provate a implementarne qualcuna vostra!

segregazione delle Interfacce

Ci credereste? La parola segregazione può assumere un valore positivo. Il quarto principio dice che sono preferibili più interfacce specifiche che un’unica interfaccia generica. Semplificando un po’ questo principio ci aiuta a implementare sia il primo principio (la singola responsabilità) che il terzo (la sostituzione di Liskov).

Interfacce minimali consentono di nascondere, alla classe che le utilizza, quei metodi della classe concreta che non servono. Isolando i dettagli implementativi.

inversione delle Dipendenze

Per finire il quinto principio è la base dei framework moderni, consente infatti di iniettare i moduli dipendenti in modo da non doverli inizializzare localmente (lo fanno i framework per voi!).

Un modo più accademico di spiegare l’inversione delle dipendenze afferma che i moduli di alto livello non devono dipendere da quelli di basso livello; fino alla sua formulazione la prassi era esattamente opposta. Zio Bob dice che i moduli di alto e basso livello dovrebbero dipendere da astrazioni, sono queste astrazioni che consentono loro di interagire tra loro. Delle astrazioni dipendono invece i dettagli.

Questione di dettagli

Dopo la carrellata SOLID parliamo di un tema assai caro a Zio Bob e ai fan della metodologia Agile. Se devo descrivere Clean Code in una frase direi che

Tutto è dettaglio

E ogni dettaglio è sostituibile. Parlavamo di pagine web che diventano applicazioni per cellulare, DB relazionali che vengono sostituiti con moderni NoSQL (o anche no, eh!), servizi esterni completamente ripensati che non dovrebbero ma scalfire la logica di business.

L’unica cosa che non è un dettaglio è appunto la logica di business. Ma se la definizione di dettaglio si basa sulla sostituibilità, allora anche sulla logica di business dovrei poter cambiare formula o algoritmo senza dover snaturare le interfacce verso il mondo esterno. Questo rende a sua volta dettaglio anche la logica di business.