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

Contenuto cancellato Contenuto aggiunto
Riga 6:
*Vedi anche [[:commons:Category:Object-oriented_design]]
 
= Programmazione a oggetti =
=== Responsabilità ===
=== Tipo di dato astratto ===
''Da mettere tra le prime sezioni.''
''(documentazione e stato interno)''
Ciò avviene anche nel mondo reale. Un esempio: in genere, una persona non conosce gli esatti 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 significato di questi messaggi, ma non del modo in cui questi messaggi siano realmente implementati. L'elenco dei messaggi è scritto in linguaggio Java ed è definito dalla classe di cui l'oggetto è istanza; il loro significato è definito da commenti aggiuntivi, scritti in linguaggio naturale, che collettivamente sono chiamati ''documentazione''. Ad esempio:
<br />''TODO: inserire qui del codice Java che definisce una classe con 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.
 
=== Incapsulamento ===
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''. 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.
 
I vantaggi sono molteplici. Infatti, ciò impedisce di scrivere un client (difettoso o malevolo) che modifichi erroneamente lo stato interno dell'oggetto; inoltre, permette di modificare in futuro la classe in esame senza dover ricompilare i client, ovviamente a patto che l'interfaccia resti immutata.
 
=== Responsabilità ===
Esempio: un programma è come un'azienda e gli oggetti sono come i dipendenti. Ogni dipendente non può svolgere un compito che appartiene ad un altro: non può entrare nel suo ufficio, consultare le sue scartoffie, e firmare i documenti al suo posto; né può svolgere per conto suo una richiesta ad un altro ufficio della stessa azienda o di altre aziende; non gli spetta, anche nel caso in cui può tecnicamente farlo (per es. se le scartoffie non sono state messe sotto chiave e il computer non è protetto da password). Invece, tutto ciò che può (e che deve) fare è contattare l'impiegato, e chiedergli che ''lui stesso'' svolga quel compito. Nella programmazione a oggetti, ciò significa che ogni oggetto deve limitarsi a svolgere il proprio compito (in gergo si parla di ''responsabilità''), e per attivare gli altri compiti deve limitarsi ad inviare messaggi agli oggetti di competenza.
 
Ad esempio: se una azienda ha dei dipendenti, e ogni dipendente ha un conto corrente, allora inviare un messaggio al dipendente dicendogli "ricevi stipendio" è preferibile ad inviare un messaggio "incrementa" al suo conto corrente.
 
=== Documentazione ===
La documentazione è una vera e propria [[:w:specifica|specifica]], quindi dovrebbe essere chiara, precisa e univoca (non ambigua), perché è il documento di riferimento per i programmatori che scrivono i ''client'' per la parte di programma interessata.
 
; Come scrivere la documentazione
Non esiste una regola vincolante di carattere generale, tuttavia è pratica comune scrivere la documentazione nel codice sorgente, in coppia con l'elemento di programma interessato, sotto forma di commento. Ciò ha evidenti vantaggi in termini di leggibilità del codice e rende più facili le modifiche, e al contempo non ha alcun impatto a tempo di esecuzione, perché i commenti vengono scartati durante la fase di compilazione.
 
Se inseriti con una sintassi speciale (&nbsp;&nbsp;<tt>/** ... */</tt>&nbsp;&nbsp;) e subito prima dell'elemento di programma interessato (classe, metodo o altro), questi commenti possono anche essere riconosciuti da un tool apposito, detto Javadoc (distribuito con il JDK) che, con un procedimento automatizzato, è in grado di metterli insieme per generare pagine di documentazione in vari formati (HTML o altri) che possono essere distribuite indipendentemente dal sorgente.<br />
 
Un altro modo di documentare il codice è fare uso di [[Java/Annotazioni|annotazioni]].
 
=== Esempi non ancora assegnati ===