Definizione e caratteristiche dei principi SOLID per software di qualità

Software di qualità e principi SOLID

In ingegneria del software, con il termine manutenibilità si indica la facilità con cui un prodotto può essere modificato in modo da correggere i bug presenti sin dall’inizio, correggere i bug introdotti da precedenti modifiche, introdurre nuove funzionalità, migliorare la qualità del software, migliorare le funzionalità già implementate, adattarlo ai cambiamenti dell’hardware o del sistema operativo sottostante.
Il termine SOLID (Single Responsibility, Liskov Substitution, Interface Segregation, Dependency Inversion) è un acronimo mnemonico che si riferisce a cinque principi che permettono di sviluppare software mantenibile e facilmente estendibile. Questi principi sono stati descritti da Robert C. Martin in una serie di articoli pubblicati nel corso dei primi anni 2000.

I cinque principi SOLID sono il principio di singola responsabilità, il principio aperto/chiuso, il principio di sostituzione di Liskov, il principio di segregazione delle interfacce e il principio di inversione delle dipendenze.

Il principio di singola responsabilità afferma che ogni elemento di un programma, come per esempio una classe o un modulo, dovrebbe essere responsabile di una singola funzionalità del software, e questa responsabilità dovrebbe essere incapsulata interamente all’interno dell’elemento stesso. Questo vuol dire che un elemento dovrebbe avere un solo motivo per dover essere modificato.

Il principio aperto/chiuso afferma che ogni elemento di un programma dovrebbe essere aperto alle estensioni, ma chiuso alle modifiche: in questo modo è possibile modificare il suo comportamento senza dover cambiare il suo codice sorgente. L’ereditarietà (dell’implementazione o dell’interfaccia) permette di soddisfare tale principio, prestando attenzione a non violare quello di singola responsabilità e quello di sostituzione di Liskov.

Il principio di sostituzione di Liskov afferma che si dovrebbe poter sostituire un oggetto con un suo sottotipo senza modificare la correttezza del programma che li utilizza.

Il principio di segregazione delle interfacce afferma che un client non dovrebbe dipendere da interfacce che contengono metodi che il client non usa. Conviene quindi avere più interfacce specifiche che una singola interfaccia generica, così che il client conosca solo i metodi che utilizza veramente.

Il principio dell’inversione delle dipendenze afferma che una classe dovrebbe dipendere da astrazioni e non da classi concrete. Questo principio permette di disaccoppiare i moduli software, perché evita che i moduli di alto livello dipendano dai moduli di basso livello e fa in modo che entrambi dipendano da astrazioni. Infatti, quello che accade normalmente nella programmazione è strutturare il software in une gerarchia di componenti, in cui quelli di alto livello sfruttano i componenti del livello sottostante per realizzare le proprie funzioni. Questa dipendenza si ripercuote anche nella compilazione. Invece, seguendo questo principio si fa in modo che i componenti di alto livello dipendano da astrazioni riguardo il funzionamento dei componenti di basso livello: queste astrazioni sono le stesse a cui fanno riferimento i componenti di basso livello. La differenza sta nel fatto che il componente di alto livello utilizza queste astrazioni per realizzare le proprie funzioni, mentre quello di basso livello le implementa. In questo modo, all’atto della compilazione non si genera alcuna dipendenza di compilazione tra i componenti di alto livello e quelli di basso livello. Per rispettare questo principio si utilizzano normalmente le interfacce o le classi astratte in abbinamento a tecniche quali la dependency injection.

Infine, bisogna dire che sviluppare codice mantenibile vuol dire anche sviluppare codice che sia facilmente comprensibile da altri sviluppatori, testabile e riusabile nello sviluppo di nuovi software.

I cinque principi SOLID

Riassumendo, l’acronimo SOLID copre 5 regole fondamentali per la buona programmazione ad oggetti:

1. SRP – Single Responsibility Principle: Una classe (o un metodo) deve avere una sola funzione, se una classe può essere utilizzata per più cose diverse occorre dividerla affinché per ogni necessità esista una classe dedicata.
2. OCP – Open Closed Principle: Una classe deve essere aperta alle estensioni ma chiusa rispetto alle modifiche. In altre parole, deve essere facile modificare la classe per migliorarla, ma non deve essere necessario aggiungere, togliere o alterare le sue funzionalità.
3. LSP – Liskov Substitution Principle: Una sottoclasse deve poter essere sostituibile alla sua classe base, senza alterare il funzionamento del programma.
4. ISP – Interface Segregation Principle: È preferibile avere più interfacce specifiche rispetto ad una singola interfaccia generica.
5. DIP – Dependency Inversion Principle: Bisogna dipendere dalle astrazioni, non dalle concretizzazioni. In altre parole, bisogna adattare il codice al progetto e non il progetto al codice.