La programmazione ad oggetti -2

Indice dei Contenuti

• Il Linguaggio UML
• Il concetto di sotto classe
• Metodo costruttore e distruttore
• Modificatori di Accesso
• Overloading dei Metodi
• Override dei Metodi

Il linguaggio UML

La classe in UML si rappresenta con un rettangolo diviso in tre aree nella prima il nome della classe, nella seconda gli attributi, nella terza i metodi.

Lo schema UML, mostra quanto affermato in precedenza, vi è un solo elemento di novità è il segno “+” davanti agli attributi e ai metodi che indica la modalità di accesso agli attributi e i metodi della classe che sono discussi più avanti in modo dettagliato.

Ora se nella classe definiamo un oggetto specificando valori per gli attributi e invocando metodi quando richiesto per compiere delle operazioni, significa che avremo definito istanza della classe. Ora una classe essendo astratta anche se definita a livello di codice nel nostro programma non allocherò risorse in termini di memoria fin quando non verrà istanziata.

Lo schema UML, di un oggetto quale istanza di una classe è sotto rappresentato:

Le classi e gli oggetti sono quindi le fondamenta della programmazione OOP, ma non sono l’unico elemento di novità introdotto nella metodologia. Abbiamo detto che la classe è composta da attributi e metodi; quest’ultimi rappresentano gli algoritmi che implementano le azioni sulle istanze (oggetti) della classe e solo attraverso di loro è possibile modificare gli attributi.
Questa proprietà degli oggetti è detta incapsulamento.
Da qui discende, che una classe che incorpora al suo interno attributi e metodi. In questo modo il programmatore non deve interessarsi dell’implementazione dei metodi della classe, ma solo di come utilizzarli; infatti egli vede solo le funzionalità della classe e non le modalità con cui quest’ultime si realizzano. Dell’implementazione dei metodi, eventualmente può essere interessato creatore di quella classe o che vuole estendere o ridefinire le funzionalità della classe.
Nel maggior parte dei casi, una classe per essere riutilizzata deve essere documentata.

Per gli sviluppatori questo approccio porta innumerevoli vantaggi;

1. Robustezza del codice;
2. Facilità di manutenzione;
3. Facilità di comprensione del codice;
4. Aumentata risolubilità di problemi complessi, in quanto il programma viene strutturato secondo specifici moduli funzionali. SI pensi ad esempio se uno sviluppatore deve realizzare un software di elaborazione testi.
   La realizzazione di tale software è complessa, in quanto il software deve possedere numerose funzionalità che spesso sono anche dipendenti fra loro. Ad esempio la gestione del documento, dipende dall’impaginazione, dalla formattazione, da elementi aggiuntivi del documento; così come ad esempio la stampa dipende dal documento stesso. In base a questo ragionamento, lo sviluppatore deve creare tante classi che interagiscono fra loro ma che spesso e volentieri non devono essere immediatamente disponibili in memoria centrale per problemi di spezio, ma anche di efficienza.

Il concetto di Sotto Classe

Nell’esempio precedente, si è vista la metodologia di definizione della classe come elemento fondamentale della nuova metodologia OOP. L’abilità dello sviluppatore che realizza classi sta nel definire classi più generiche possibili in modo da poter poi eventualmente derivare delle sotto classi come casi specifici della classe di livello superiore che si definisce superclasse.
In senso generico in UML lo scherma di una superclasse con una sottoclasse può essere formalizzato come riportato in figura.

Nello schema UML si evidenzia la relazione di generalizzazione ovvero la classe più generale possibile è “Veicoli a motore” che possiede i suoi attributi e metodi, poi da essa si possono derivare due sottoclassi con ulteriori attributi e metodi aggiuntivi caratteristici di quelle sottoclassi “Auto” e “Motoveicoli”. Questo è il secondo elemento di novità della programmazione OOP ovvero l’ereditarietà la possibilità di derivare classi a partire da altre o attraverso generalizzazione.
Questo approccio è molto potente perché permette un adattamento delle classi che non corrispondendo in pieno alle esigenze dello sviluppatore possono essere derivate.
Appare evidente che potrebbe capitare che alcuni metodi e/o attributi della sottoclasse e/o superclasse devono essere sostituiti per mutate esigenze di utilizzo.
L’esempio mostrato mostra un tipico problema che si presenta con l’ereditarietà ovvero quella dell’istanziamento dell’oggetto giusto.
In altri termini immaginiamo di dover istanziare sia un oggetto “auto” che “motoveicolo” a partire dalla superclasse o viceversa come occorre procedere in questo caso ?
L’ereditarietà porta con se due modalità per aggirare il problema l’overloarding dei metodi, e l’overriding. La prima parola significa “sovraccarticamento” ovvero la possibilità di dichiarare più metodi con lo stesso nome ma con argomenti diversi.
Il secondo termine “overriding” è la sovrapposizione di metodi ad altri.

Nel nostro caso per poter utilizzare entrambi gli oggetti “auto” e “motoveicoli” a partire dalla superclasse occorre definire due metodi che inizializzano in modo corretto i due oggetti.
Questo argomento sarà oggetto di ampia trattazione, nei paragrafi successivi.