Gli effetti della scarsa qualità progettuale nello sviluppo di un software, che gli anglosassoni definiscono rotting design, si fanno sentire nelle varie fasi del suo ciclo di vita. Questo problema si ripercuote nelle fasi di modifica o integrazione del codice, che possono diventare attività molto complesse, delicate e costose.

Per capire da dove proviene il problema, si deve evidenziare che spesso la scelta di un design pattern scorretto o gli errori nella fase di analisi, precedente alla progettazione, si percepiscono quando lo sviluppo è in fase troppo avanzata per porvi rimedio. In alcuni casi i progettisti partono nel migliore dei modi, ma la situazione può cambiare drasticamente in corso di sviluppo del prodotto, quando si aggiungono o modificano le funzionalità.

Sono stati individuati diversi elementi, che caratterizzano i problemi di rotting design; nel precedente articolo si sono esaminate le problematiche indotte dalle eccessive interdipendenze, che possono esistere tra le varie classi nell’ambito della programmazione orientata agli oggetti. Su questo aspetto è utile fare ancora alcune precisazioni.

Innanzitutto una classe con pochi legami o dipendenze da altre classi risulta estendibile in modo abbastanza semplice, senza parlare della facilità con cui la si può testare. Prima di tutto quindi è utile eliminare qualsiasi fronzolo inutile, che comporti una interdipendenza eccessiva tra le classi. Si può obiettare che questo procedimento comporta però la creazione di strutture ridondanti, che per certi versi si assomigliano nelle funzionalità da espletare. In questo caso il giusto bilanciamento tra le due necessità è la soluzione migliore.

Si può ancora aggiungere che l’eccessiva presenza di relazioni/dipendenze tra sezioni di codice rende il software “fragile” o particolarmente vulnerabile; in questo caso l’eventuale modifica di un rapporto di dipendenza tra due classi può ripercuotersi su altri legami esistenti tra diverse sezioni del codice, portando al collasso dell’intera architettura delle dipendenze e quindi del sistema. In tal caso il software non è modificabile o integrabile.

L’applicazione dell'Open Closed Principle, che contempla la possibilità di estendere le funzionalità di un modulo (classe) senza apportarvi modifiche, può essere molto utile. In particolare risulta efficace aggiungere funzionalità mediante nuovo codice, che però non modifica quello esistente. A questo ovviamente si affianca il discorso relativo all’architettura Agile, che rappresenta un corretto approccio al problema, ma che necessiterebbe di una specifica analisi.

• Pubblicazioni correlate:
• 29-12-2009 Qualità progettuale nelle fasi di modifica del software (1/2)