Principi di disegno

R. Turco

I sintomi della degradazione del software

Nel seguito vedremo i sintomi, le cause e la prevenzione del fenomeno “degrado del software”.

Il Design Refactoring costituisce, proprio, la prevenzione al degrado del software.Occorre innanzitutto capire quali sono i sintomi che possono segnalare che un sistema softwaresi sta guastando.

Rigidità

E’ la tendenza da parte del software ad essere difficilmente cambiabile. Una modifica anche

semplice comporta un innesco a catena di cambiamenti.

Fragilità

E’ la tendenza del software a spezzarsi in molti pezzi ad ogni modifica, fino a diventare

immanutenibile.

Immobilità

E’ la tendenza ad una difficile riusabilità del software per altri progetti o per altri parti dello

stesso software.

Viscosità del disegno

Quando occorre fare una modifica, i software engineers cercano sempre la strada più semplice.Alcune di queste vie preservano il disegno, altre no.Se la viscosità del disegno è alta, ovvero per preservare il disegno occorre fare una modificaabbastanza difficile, è altamente probabile che gli sviluppatori non seguiranno tale strada ed ildisegno non sarà preservato.

Viscosità dell’ambiente

Se l’ambiente di compilazione o quello di versioning è lento e inefficiente gli

sviluppatori

prenderanno decisioni di sviluppo che riducono l’impatto dell’ambiente; questo però spesso

anche a discapito della necessità di preservare il disegno.

Cambiamento dei requisiti

Non si può pretendere che i requisiti non cambino. Hanno una natura volatile che fa parte delladinamicità del business in gioco.

L’Importante è gestire correttamente i rischi correlati alla variazione di una parte dei requisiti e

mantenere un minimo di flessibilità del software in modo che possa essere aperto aicambiamenti facilmente.

Le cause della degradazione

Un sistema software perché degrada? In realtà la causa è da ricercarsi in una “dipendenzaarchitetturale impropria tra i moduli del software”. In altri termini degrada la dipendenza

architetturale e, di conseguenza, anche le possibilità di mantenere il software.

I principi ed i rimedi

Nel seguito esamineremo dei principi che costituiscono un rimedio al degrado dovuto alladipendenza tra i moduli software.

Open Closed Principle (OCP)

“Un modulo deve essere aperto all’estensione e chiuso alle modifiche”

Il principio OCP è tipico dell’Object Oriented: un nostro modulo deve poter essere esteso perereditarietà senza che sia necessario modificarlo internamente. La chiave dell’OCP èl’

astrazione object oriented

.Un esempio C++.Supponiamo di avere del software di Logon che, purtroppo, richiede di essere modificato ogni

volta a causa dell’aggiunta di un nuovo tipo di modem.

struct Modem {typedef enum Type { hayes, courrier, ernie } type;};struct Hayes {Modem::Type type; // etc};struct Courrier {Modem::Type type; // etc};struct Ernie {Modem::Type type; // etc};void Logon( Modem& m, string& pno, string& user, string& password){if( m.type == Modem::hayes)DialHayes((Hayes&)m, pno);else if(m.type == Modem::courrier)DialCourrier((Courrier&)m, pno);else if(m.type == Modem::ernie)DialErnie((Ernie&)m,pno);}

Qui l’OCP aiuta a capire che sin dall’inizio occorreva progettare il tutto secondo il diagramma in