Appunti OOP: Cause di riprogettazione

A cosa stare attenti quando si progettano delle classi al fine di evitare di trovarsi nei guai successivamente:

1. Creare oggetti specificando in modo esplicito una classe.
   Il problema consiste nel legare il progetto ad una specifica implementazione di una classe piuttosto che ad una interfaccia. Quindi, dovendo cambiare per una qualche ragione la classe soggetta a istanza è obbligo modificare tutti i punti in cui sono creati gli oggetti di tale classe e codice del client, qualora l'interfaccia (intesa come metodi pubblici esposti dalla classe) della nuova classe differisca dalla vecchia. Creare gli oggetti tramite metodi (statici, polimorfici o come suggerisce la fantasia) facendo sempre attenzione alla corretta e puntuale definizione delle interfacce, con classi astratte o interfacce, per garantire la compatibilità nell'utilizzo di classi differenti con le medesime finalità.
   
2. Dipendenza da specifiche operazioni
   Mai fare affidamento sul come una richiesta è soddisfatta dalla classe. Ciò implica che, al variare dell'implementazione del metodo, occorre modificare il codice del client.
   
3. Dipendenza da hardware o software
   Legare il proprio codice ad un piattaforma, che sia hardware o software, lo rende non portabile e difficile da tenere aggiornato sulla piattaforma per cui è progettato.
   
4. Dipendenza dalla rappresentazione o implementazione di un oggetto
   Fare affidamento sul modo in cui un oggetto, istanza di una certa classe, archivia i dati significa dover modificare il codice client qualora la classe cambi il modo di archiviare i dati da parte dell'oggetto.
   
5. Dipendenza dagli algoritmi
   E' opportuno intrappolare gli algoritmi in apposite classi all'uopo dedicate.

In generale occorre evitare le dipendenze dall'implementazione di una classe (istanza diretta, operazioni, modo di memorizzazione dei dati), dagli algoritmi (legare il proprio codice ad un algoritmo specifico) o da hardware/software presenti su una certa piattaforma.

L'oggetto, quale istanza di una certa classe, deve essere una scatola nera di cui non dobbiamo conoscere nulla se non i suoi elementi pubblici, meglio se solo metodi, precisamente definiti tramite interfaccia o classe astratta. Il nostro codice (client) non deve fare affidamento sulla presenza di una certa classe ma confidare nell'implementazione di una interfaccia, di modo che qualunque classe implementi l'interfaccia necessaria al client è utile allo scopo.