Follow

Continuiamo la serie di lezioni sulla programmazione generale, questa volta cercando di approfondire molti degli aspetti che nelle prime 10 parti introduttive avevamo lasciato appesi. Cominciamo perciò dal concetto che (dopo i puntatori) spiazza di più chi non ha confidenza con la programmazione: gli oggetti.

Abbiamo già visto nelle parti precedenti il principio base su cui si fondano i linguaggi di programmazione orientati agli oggetti. In particolare abbiamo parlato del concetto di oggetto come del concetto di entità dotata di caratteristiche e abilità particolari.

Adesso cercheremo di entrare più in dettaglio su alcuni aspetti per ottenere le basi per futuri approfondimenti.

Dobbiamo innanzitutto tenere presente che un oggetto può essere visto da due punti di vista:

• Il punto di vista esterno che corrisponde al modo in cui un oggetto viene visto dal mondo esterno, cioè da tutti gli oggetti all’infuori di se stesso.
• Il punto di vista interno che corrisponde a come l’oggetto vede e interpreta se stesso.

Per chiarire un po la situazione considerate che l’interno di un oggetto è di interesse solamente per chi programma l’oggetto mentre il punto di vista esterno è di interesse per chiunque lo usi.

Struttura esterna di un oggetto.

Dall’esterno un oggetto è assimilabile ad una scatola sigillata. L’accesso e il funzionamento di questa scatola è garantito solamente dalle leve esterne chiamate metodi. L’insieme dei metodi esterni prende il nome di interfaccia esterna di un oggetto (spesso chiamata anche con l’acronimo API di un oggetto).

A livello esterno quindi un oggetto non è altro che un dispositivo accessibile dall’esterno grazie alla sua interfaccia esterna. E’ da tenere presente che l’effettivo funzionamento di un oggetto, ovvero gli algoritmi che utilizza per rispondere ai metodi, non sono (ed è giusto che non siano) a conoscenza di un eventuale utilizzatore.

Come anticipato, i metodi caratterizzano cio che un oggetto sa fare, ma a questo punto potremmo essere più precisi definendo i metodi come le richieste a cui un oggetto sa rispondere. Alcuni linguaggi di programmazione ad oggetti (ad esempio ObjC) permettono di invocare su di un oggetto metodi qualunque e, ovviamente, l’oggetto reagirà solamente per i metodi per i quali era stato definito un comportamento.

Facciamo un esempio:

L'oggetto Orologio visto dall'esterno.

L’oggetto Orologio è rappresentato in figura. Noi non sappiamo nulla di come e quali dati contenga e gestisca l’oggetto Orologio. Come è rappresentata l’ora? Con tre interi (ore, minuti, secondi)? Con il numero di secondi dalla mezzanotte? Non lo sappiamo e non ci importa.

Quello che ci interessa è che se noi invochiamo su Orologio il metodo ottieniOra riceveremo l’ora esatta e invocanto impostaOra potremo modificare l’ora.

Uno dei vantaggi di questo approccio è che se un giorno il programmatore che gestisce l’oggetto Orologio volesse stravolgere l’oggetto Orologio, purchè non modifichi l’interfaccia esterna, noi utilizzatori non dovremo preoccuparci perché tutto continuerà a funzionare tranquillamente.

Ma non possiamo limitarci ad usare oggetti altrui, prima o poi, saremo costretti a creare i nostri oggetti. Diamo quindi uno sguardo all’interno di un oggetto.

Autopsia di un oggetto.

Entrare nella struttura interna di un oggetto è simile ad aprire il cofano di un auto. La differenza principale con la struttura esterna è la presenza degli attributi. Gli attributi rappresentano ciò che un oggetto sa di se. Vengono perciò gestiti dall’oggetto stesso: è buona norma infatti non permettere mai l’accesso diretto esterno agli attributi ma permettere la loro modifica/lettura solo attraverso i metodi di interfaccia.

Altra differenza importante è la presenza di metodi accessibili solo dall’oggetto stesso. Questi metodi consistono spesso in metodi ausiliari che non hanno rilevanza esplicita per l’esterno ma sono utilizzati solo dai metodi dell’oggetto stesso.

Un esempio di metodo interno potrebbe essere un algoritmo che converte dei valori di un attributo in un qualche formato che un altro metodo (probabilmente un metodo esterno) elaborerà e restituirà all’esterno.

Ovviamente nella realtà non ci troveremo spesso a vestire i panni di utilizzatore e di programmatore di un oggetto contemporaneamente. Quindi bisogna fare dimestichezza in tutte e due le “divise”.

Ora che conosciamo per bene cosa è un oggetto, andremo ad analizzare cosa rappresentare con un oggetto. Penso che alcuni di voi abbiano già intuito la cosa, ma ci sono due aspetti e alcune problematiche da approfondire: le differenze fra oggetti come entità e oggetti come valori.