Modifica della progettazione delle classi base dopo la distribuzione
Aggiornamento: novembre 2007
È consigliabile che le gerarchie di classi non vengano mai modificate dopo la distribuzione, perché anche piccole modifiche possono provocare conseguenze impreviste. Nella pratica, tali modifiche sono spesso inevitabili: è possibile che i requisiti di un prodotto vengano modificati e spesso nelle specifiche di progettazione si omettono elementi chiave. Una categoria di problemi relativi all'ereditarietà è quindi dedicata al problema della fragilità della classe base.
Il problema della fragilità della classe base
L'inconveniente principale nell'utilizzo delle gerarchie di ereditarietà è il problema della fragilità delle classi base. Le modifiche apportate alle classi base spesso richiedono la modifica, la ricompilazione e la ridistribuzione della classe base stessa e di tutto il codice delle classi derivate. Il problema è ancora più complesso se la classe base e le classi derivate vengono modificate da più sviluppatori, perché l'accesso al codice sorgente potrebbe essere negato dalle singole parti. Nel caso peggiore, un cliente potrebbe utilizzare inavvertitamente il form binario compilato di una classe base aggiornata con la versione binaria originale e incompatibile delle classi derivate.
Le modifiche di una classe base che potenzialmente possono causare un'interruzione nelle classi derivate sono l'override e la modifica del tipo di dati dei membri della classe base.
Riduzione del problema della fragilità della classe base
Il modo migliore per evitare il problema della fragilità della classe base è apportare modifiche solo nelle classi derivate. Questa procedura tuttavia non è sempre possibile, perché significherebbe considerare tutte le eventualità durante il primo rilascio della classe base. Nonostante tutti gli sforzi, infatti, le modifiche impreviste alla classe base restano a volte inevitabili.
L'utilizzo delle classi MustInherit e dei metodi MustOverride contribuisce a ridurre i problemi della fragilità della classe base, perché consente di trasferire l'implementazione dei dettagli alle classi derivate, riducendo la necessità di modificare la classe base. Anche questo, tuttavia, non sempre è possibile, nonostante la pianificazione più accurata.
Anche i membri dati nascosti delle classi derivate sono utili, perché riducono i conflitti di denominazione con i membri della classe base.
Il modo più sicuro per estendere la funzionalità di una classe base consiste nell'aggiunta di nuovi membri. I nuovi membri possono causare interruzione in una classe base solo se la classe derivata utilizza la parola chiave Overloads per consentire di ereditare i metodi dalla classe base, introducendo nuovi metodi con lo stesso nome. Questo problema può essere evitato specificando in modo esplicito nella classe derivata quali sono i metodi della classe base che si desidera ereditare dalla base, ridefinendo tali metodi ed eseguendo una delega ad essi.
In un certo senso tutte le classi base sono fragili in qualche misura. Concludendo l'analisi, il problema della fragilità della classe base non può essere eliminato, ma può essere limitato tramite un'attenta progettazione delle gerarchie di classi che riduca la necessità di modificare la classe base e attraverso l'esecuzione di un test completo nel caso in cui queste modifiche siano inevitabili.