I principi SOLID riassumono le migliori pratiche della programmazione orientata agli oggetti, paradigma utile nel web development, tra le altre cose, per la realizzazione delle interfacce grafiche. La programmazione a oggetti aiuta a scrivere codice flessibile, scalabile, riutilizzabile e di facile manutenzione. Per un programmatore informatico, quindi, le linee guida SOLID sono tra i concetti da comprendere a fondo e utilizzare nel quotidiano. Vediamo, allora, che cosa sono i principi SOLID e perché sono utili.
Cosa sono i principi SOLID
Nei primi anni 2000, il primo a riassumere i principi SOLID, già utilizzati da molti web developers senior prima della loro diffusione con questo nome, è stato Robert C. Martin, conosciuto anche con il soprannome amichevole “Zio Bob”. Lo scopo principale di queste pratiche è di ridurre la complessità associata alle modifiche a un software o a un’applicazione, permettendo così di scrivere codice più efficiente. In pratica, aiutano a ridurre l’accoppiamento stretto o alto (tight coupling) tra gruppi di classi, privilegiando l’accoppiamento lasco o basso (loose coupling). Si limita così la necessità di cambiamenti estensivi al codice in caso di modifiche o aggiunte, rendendolo più stabile, flessibile e riutilizzabile. Per questo, uno dei contesti che trae grandi vantaggi dai principi SOLID è quello dello sviluppo agile, che ha tra i suoi valori chiave proprio la capacità di rispondere ai cambiamenti in modo flessibile.
“SOLID” è un acrostico che aiuta a ricordare i cinque principi che descrive:
- Single responsibility principle (principio di singola responsabilità)
- Open/closed principle (principio aperto/chiuso)
- Liskov’s substitution principle (principio di sostituzione di Liskov)
- Interface segregation principle (principio di segregazione delle interfacce)
- Dependency inversion principle (principio di inversione delle dipendenze).
Scopriamo più nel dettaglio a che cosa fanno riferimento questi principi e in che modo permettono di scrivere codice migliore nella programmazione ad oggetti.
1. Single responsibility principle
Secondo il principio di singola responsabilità, o single responsibility principle (SRP), non deve mai esserci più di una ragione per modificare una classe. In altre parole, ogni classe deve avere soltanto una singola responsabilità o un singolo scopo. Ad esempio, uno sviluppatore web che voglia aggiungere una nuova funzione o un nuovo comportamento deve creare allo scopo una nuova classe, e non implementare le modifiche in una classe preesistente. Dare più di una responsabilità a una sola classe, infatti, rende il codice pesante, aumenta il livello di complessità e rende eventuali modifiche future più difficili e dispendiose in termini di tempo.
2. Open/closed principle
Il principio aperto/chiuso (open/closed principle) indica che le entità della programmazione informatica, come classi, moduli, funzioni e così via, devono essere aperte alle estensioni, ma chiuse alle modifiche. Questo vuol dire che deve essere possibile estendere il comportamento di una classe, senza bisogno di modificarla. Seguendo questa linea guida è possibile scrivere codice flessibile e in grado di rispondere alle normali evoluzioni delle applicazioni, evitando da parte del developer la necessità di effettuare modifiche, ma permettendone con facilità l’estensione. Ancora una volta, si ha il vantaggio di un codice più stabile e di semplice manutenzione, con una ridotta necessità di cambiamenti.
3. Liskov’s substitution principle
Introdotto da Barbara Liskov nel 1987, il principio di sostituzione di Liskov (Liskov’s substitution principle o LSP) dichiara che le sottoclassi devono sempre poter essere utilizzate in sostituzione della propria classe padre. Nella gerarchia della oop, quindi, ogni classe figlia deve poter essere impiegata al posto della classe padre senza creare comportamenti imprevisti o problemi per il funzionamento dell’applicazione. Se ciò non accade, può essere necessario prendere provvedimenti come rendere più generica la classe padre o implementare in essa le differenze emerse, creare una nuova classe padre, oppure rinunciare all’ereditarietà tra le classi interessate. Uno sviluppatore di siti web che non rispetti questo principio corre il rischio di realizzare un’applicazione rigida a cui è difficile apportare modifiche.
4. Interface segregation principle
Al contrario dei precedenti principi, che facevano riferimento alle classi della programmazione a oggetti, il principio di segregazione delle interfacce (interface segregation principle o ISP) applica appunto alle interfacce un concetto simile a quello esposto dal principio di singola responsabilità. Questo principio asserisce che ai client non deve essere imposta l’implementazione di interfacce che non utilizzano. Un web developer dovrebbe impegnarsi, quindi, nel realizzare interfacce specializzate per ogni client, invece di una sola grossa interfaccia. Ogni interfaccia, dunque, dovrebbe avere una responsabilità specifica. L’utilizzo di questo principio aiuta a ridurre la necessità di cambiamenti frequenti e gli effetti collaterali che ne derivano.
5. Dependency inversion principle
L’ultimo tra i principi SOLID è il principio di inversione delle dipendenze o dependency inversion principle (DIP), esposto dallo stesso Robert C. Martin. Questo principio è composto da due concetti. Il primo enuncia che moduli o classi di alto livello non devono dipendere da moduli o classi di basso livello, e che entrambi devono dipendere da astrazioni. Il secondo punto è che le astrazioni non devono dipendere dai dettagli, i dettagli devono dipendere dalle astrazioni. In parole più semplici, se un modulo di alto livello dipende da un modulo di basso livello si va a formare un accoppiamento stretto che, come già accennato, aumenta il rischio di problemi in caso di modifiche al codice. Per ottenere classi e moduli con accoppiamento lasco, la scelta da preferire, ci si può avvalere delle astrazioni. Grazie al principio di inversione delle dipendenze di può scrivere codice più facile da riutilizzare in altri progetti, aumentando produttività ed efficienza.
