Programmazione orientata agli oggetti in ANSI-C. Manutenzione delle gerarchie di classe. Requisiti

L'ereditarietà ci permette di passare da tipi di dati generali a tipi di dati più speciliazzati e ci permette di incrementarne le funzionalità. Il linking dinamico (dynamic linkage) permette di far fronte a piccoli problemi che possono verificarsi quando si passa dall'uso dei tipi di dati generali a tipi di dato più specializzati.

Abbiamo comunque bisogno di una organizzazione globale e funzionale che ci permetta di gestire un gruppo di classi in eventuale aumento nel tempo:

1)tutti i link dinamici devono puntare ai metodi corretti – significa che un costruttore non dovrebbe essere inserito nel posto sbagliato in una descrizione di classe
2)sorge la necessità di utilizzare una modalità coerente nel tempo per aggiungere, rimuovere, cambiare l'ordine dei metodi linkati dinamicamente per una superclasse, garantendo allo stesso tempo il corretto meccanismo di ereditarietà per le sottoclassi;
3)non ci dovrebbero essere metodi non definiti oppure link dinamici mancanti
4)se un metodo linkato dinamicamente viene ereditato, l'implementazione della superclasse dalla quale ereditiamo deve rimanere invariato nel modo più assoluto, ossia l'ereditarietà deve essere possibile usando solo informazioni binarie.
5)Insiemi diversi di classi dovrebbero essere in grado di avere insiemi diversi di metodi linkati dinamicamente – ossia solo Point e Circle dovrebbero utilizzare il metodo draw, e non gli insiemi del capitolo 1 oppure i nodi delle espressioni dei capitoli 3 e 5.

Per la maggior parte, questa lista indica che mantenere il linking dinamico è difficile e non esente da errori – se non facciamo in modo di migliorarre sostanzialmente la gestione delle classi, la situazione rischia di degenerare e non diventare più gestibile.

Nei capitoli precedenti abbiamo lavorato con una lista semplice di metodi linkati dinamicamente, senza preoccuparci se avesse senso o no in una classe particolare. La lista è stata definita come struct Class ed è stata inclusa ogni volta che è sorta la necessità di inizializzare il meccanismo del dynamic linkage. Grazie ai prototipi delle funzioni, il C ANSI verificherà che i nomi delle funzioni come Point_ctor sia coerente con la descrizione della classe, dove i prototipi sono utilizzati come inizializzatori statici.
Il problema evidenziato in (1) è un problema reale se più metodi avranno interfacce compatibili oppure se verrà modificata la struct Class.

Nel problema evidenziato in (2), cambiare la struct Class equivale ad un vero incubo – avremmo la necessità di accedere manualmente ad ogni implementazione di classe per aggiornare l'inizializzazione statica della descrizione di classe e possiamo quindi facilmente dimenticare di aggiungere un nuovo metodo in qualche classe, tanto da causare il problema in (3).

Abbiamo un modo elegante di aggiungere l'assegnazione al calcolatore della sezione 5.6: cambiamo la struttura del codice sorgente e facciamo in modo di rendere pubblici i metodi linkati dinamicamente dei nodi binari del paragrafo 3.6 in modo da poterli riutilizzare come inizializzatori per la descrizione Assign, ma questo viola chiaramente il requisito (4).

Se manteniamo una sola struct Class significa andare incontro ad una sfida. Il requisito (5) suggerisce che dovremmo avere diverse versioni della struct Class per differenti insiemi di classi. Il requisito è più che ragionevole, comunque: ogni classe necessita di un costruttore e di un distruttore; per i punti, i cerchi, e gli altri oggetti grafici aggiungiamo le funzioni di disegno, per gli atomi e le stringhe aggiungiamo i confronti e per le collezioni come sets, bags o liste aggiungeremo metodi per aggiungere, trovare o eliminare oggetti e così via.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend