Quando lavoriamo su codebase di grandi dimensioni, spesso ci affidiamo al “sesto senso” per capire se il codice sta diventando troppo complesso o difficile da mantenere. Tuttavia, l’architettura software non deve basarsi solo sulle sensazioni. Alla fine degli anni ’90, Robert C. Martin (noto anche come Uncle Bob) ha introdotto una serie di metriche quantitative per valutare in modo oggettivo la struttura e il bilanciamento di un’applicazione orientata agli oggetti.
In questo articolo esploreremo i due pilastri di queste metriche — l’Astrattezza e l’Instabilità — e vedremo come la loro combinazione possa salvarci dal codice rigido e impossibile da manutenere.
1. L’Astrattezza : Trovare il bilanciamento tra Regole e Implementazione
L’Astrattezza misura il rapporto tra ciò che il codice dovrebbe fare (la sua progettazione teorica) e ciò che il codice fa effettivamente (la sua implementazione pratica). In termini tecnici, è il rapporto tra gli artefatti astratti (come interfacce e classi astratte) e gli artefatti concreti (le classi di implementazione).
Pensaci un attimo: gli elementi astratti sono fondamentali perché permettono agli sviluppatori di isolare i concetti e comprendere la struttura complessiva del sistema senza affogare nei dettagli. Immagina una codebase composta da un singolo metodo main() e 10.000 righe di codice procedurale: otterrebbe un punteggio di Astrattezza prossimo allo zero, risultando un incubo da leggere, testare e modificare.
La formula matematica per calcolare l’Astrattezza è la seguente:
- rappresenta il numero di elementi astratti (interfacce o classi astratte) all’interno del codice sorgente.
- : rappresenta il numero di elementi concreti (classi standard di implementazione).
Il risultato è un punteggio compreso tra 0 (codice totalmente concreto, nessuna astrazione) e 1 (codice composto solo da interfacce senza alcuna implementazione).
2. L’Instabilità : Capire quanto il codice è “sensibile al vento”
La seconda metrica fondamentale è l’Instabilità, che determina la volatilità di una codebase. Per calcolarla dobbiamo prima introdurre il concetto di accoppiamento, che si divide in due direzioni:
- Accoppiamento Afferente – In entrata): Misura quanti altri componenti esterni dipendono dal nostro componente. È l’indice di “popolarità” del modulo.
- Accoppiamento Efferente – In uscita): Misura da quanti altri moduli esterni dipende il nostro componente per poter funzionare. È l’indice di “vulnerabilità”.
L’Instabilità mette in relazione queste due forze attraverso questa formula:
Una codebase che presenta alti gradi di instabilità (valore vicino a 1) si rompe molto più facilmente quando viene modificata, a causa dell’elevato accoppiamento verso l’esterno. Se il tuo modulo dipende da 5 librerie esterne ma nessuno dipende da lui (\(I\) vicino a 1), basta che una di quelle librerie cambi per costringerti a riscrivere il codice.
Al contrario, un valore vicino a 0 indica massima stabilità: molti dipendono da te, ma tu non dipendi da nessuno.
3. Il Compromesso: Stabilità vs Rigidità
Potremmo pensare che l’obiettivo sia avere sempre un’instabilità pari a zero . In realtà, la stabilità da sola nasconde una trappola.
Se un componente ha un’instabilità vicina a 0, dobbiamo guardare subito la sua Astrattezza ):
- È stabile se il modulo contiene principalmente elementi astratti (interfacce). In questo caso il codice è solido ma flessibile.
- È rigido se il modulo è composto principalmente da elementi concreti. Modificare questo codice diventa un incubo geometrico, perché cambiare una riga rischia di rompere a catena decine di altri moduli che vi sono agganciati.
Tuttavia, il prezzo da pagare per un’elevata stabilità (sia essa flessibile o rigida) è spesso la mancanza di riutilizzo: se ogni componente è isolato e autonomo, la duplicazione del codice è dietro l’angolo.
Conclusione: La Distanza dalla Sequenza Principale
Proprio per questo motivo, gli architetti software non considerano mai i valori di (Instabilità) e (Astrattezza) separatamente. La vera magia avviene quando vengono combinati in una metrica olistica chiamata Distanza dalla Sequenza Principale.
Questa metrica serve a calcolare se il nostro software si trova in una “zona di salute” ottimale, bilanciando perfettamente la flessibilità delle nostre interfacce con la solidità delle nostre dipendenze. Ma di questo equilibrio perfetto — e di come calcolare la distanza ideale — parleremo approfonditamente nel prossimo articolo!
Il componente vicino alla linea è un componente ben bilanciato, mentre quelli che si trovano troppo nell’angolo in alto a destra entrano in quella in gergo si dice
zona dell’inutilità: un codice troppo astratto diventa difficile da usare.
Al contrario, il codice che si posizione nell’angolo in basso a sinistra entra nella zona critica: un codice con troppa implementazione e poca astrazione diventa fragile e difficile da manutenere.