Utente:LoStrangolatore/Sac à poche: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
mNessun oggetto della modifica
mNessun oggetto della modifica
Riga 7:
 
== Tipo di dato astratto ==
Ciò avviene anche nel mondo reale. Un esempio: in genere, una persona non conosce gli esattii meccanismi burocratici che vengono attivati da una richiesta svolta ad un ufficio pubblico o non; tutto ciò che fa è inviare la richiesta e attendere che sia completata. Ciò che il cliente conosce è il concetto di ''richiesta inviata a tale ufficio'' e il comportamento che ci si aspetta da tale ufficio in conseguenza della richiesta.
 
Nella programmazione a oggetti è esattamente così. Un oggetto considera un altro oggetto solo in funzione dei messaggi che può inviargli e del loro significato di questi messaggiconcettuale, ma non del modo in cui questi messaggi sianosono realmente implementati. L'elenco dei messaggi è scritto in linguaggio Java ed è definito dalla classe di cui l'oggetto è istanza; il loro significato (detto "semantica") è definitofornito da commenti aggiuntivi, scritti dal programmatore in linguaggio naturale, che collettivamente sono chiamati ''"documentazione''". Ad esempio:
<br />''TODO: inserire qui del codice Java che definisce l'interfaccia di una classe (metodi e documentazione), seguito da un paragrafo che indichi come il solo elenco dei metodi non sia sufficiente, portando come esempio (e conferma) un metodo il cui nome potrebbe un significato diverso da quello indicato nella documentazione, ma altrettanto plausibile.''
 
Alla base della programmazione orientata agli oggetti c'è il concetto di [[:w:tipo di dato astratto|tipo di dato astratto]], ovvero un tipo definito da una collezione di operazioni e dal loro significato (''semantica''). I ''client'' attivano le operazioni sulle istanze di quel tipo, senza conoscerne i meccanismi interni, ma solo in funzione del loro significato.
 
; Stato interno
Riga 20:
Si consideri un qualunque oggetto meccanico o elettronico, come un computer. All'interno del computer ci sono dispositivi che l'utente non vede: il processore, i cavi di collegamento tra le periferiche, e così via. L'utente vede solo l'esterno, ovvero il ''case'' e le periferiche. Analogamente, nella maggioranza dei casi, per creare un oggetto è necessario definire più membri di quelli che si vogliono rendere disponibili ai client. I client non devono avere accesso ai membri interni, i quali sono ad uso privato dell'oggetto stesso.
 
L'insieme dei membri resi disponibili ai client prende il nome di ''interfaccia'', mentre i membri usati internamente dall'oggetto e non visibili altrove sono chiamati collettivamente ''implementazione''. La classe può essere considerata come un documento che definisce l'interfaccia e l'implementazione delle sue istanze.<br />
Per spostare un membro dall'interfaccia all'implementazione si usa il modificatore <tt>private</tt>. I client non possono accedere all'implementazione, perché il compilatore si rifiuta di compilarli, appunto perché legge il modificatore <tt>private</tt>.<br />
La regola generale quando si scrive una classe è che la sua interfaccia deve essere quanto più piccola e semplice possibile. Tutto ciò che non deve stare nell'interfaccia dovrebbe stare nell'implementazione.