Nuova roba per programmazione a oggetti (Java)

in genere, reinventare la ruota è una pessima idea
mantieni l'interfaccia di un oggetto o di una API quanto più piccola e semplice possibile
- + link ad una pagina che descriva il code bloat, su en.wikipedia

Programmazione a oggetti (Java)

Per approfondire, vedi Java/Programmazione ad oggetti.

Immagini

Tipo di dato astratto

Ciò avviene anche nel mondo reale. Un esempio: in genere, una persona non conosce i 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 concettuale, ma non del modo in cui questi messaggi sono realmente implementati. L'elenco dei messaggi è scritto in linguaggio Java ed è definito dalla classe di cui l'oggetto è istanza; il loro significato (detto "semantica") è fornito da commenti aggiuntivi, scritti dal programmatore in linguaggio naturale, che collettivamente sono chiamati "documentazione". Ad esempio:
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 tipo di dato astratto, ovvero un tipo definito da una collezione di operazioni e dal loro significato. I client attivano le operazioni sulle istanze di quel tipo, senza conoscerne i meccanismi interni, ma solo in funzione del loro significato.

Stato interno

TODO: inserire qui l'implementazione della classe di cui sopra, e usarla per mostrare che gli oggetti hanno un proprio stato interno. Validità dello stato interno di un oggetto.

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. La classe può essere considerata come un documento che definisce l'interfaccia e l'implementazione delle sue istanze.
Per spostare un membro dall'interfaccia all'implementazione si usa il modificatore private. I client non possono accedere all'implementazione, perché il compilatore si rifiuta di compilarli, appunto perché legge il modificatore private.
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 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 ( /** ... */ ) 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.

Un altro modo di documentare il codice è fare uso di annotazioni.

Esempi non ancora assegnati

Laboratorio di ricerca

Esempio

Ad esempio, supponiamo che un laboratorio di ricerca ci chieda di scrivere un programma per il calcolo scientifico. Il programma sarà installato sui computer del laboratorio (che sono vecchi e poco potenti) e farà svolgere i calcoli ad un server: un supercomputer che si trova in Florida ed appartiene all'Università che finanzia il laboratorio. I ricercatori inseriranno i dati nel programma, che li passerà al supercomputer, e questi li elaborerà; il nostro programma riceverà i risultati e li mostrerà ai ricercatori, sullo schermo o stampandoli su carta.

Tra gli "attori" che hanno un ruolo in questo programma, ci sono di certo l'utente (i ricercatori che inseriscono i dati) e il server. L'utente invia un messaggio al programma: dai questi dati al server; il programma deve, in qualche modo, comunicare con il server, e inviargli un messaggio: elabora questi dati; il server restituisce i risultati con il messaggio: ho elaborato i dati e questi sono i risultati; il programma deve restituire i dati all'utente.

Nel programma, il server è rappresentato con un oggetto. I messaggi che questo oggetto riceve sono trasmessi sulla Rete fino al server, il quale si occupa di eseguire le elaborazioni vere e proprie, così che i ricercatori e il programma stesso abbiano l'illusione di lavorare direttamente con il server, anche se in realtà comunicano solo con un "intermediario".

Inventario di un negozio

Esempio

Ad esempio, si supponga di voler scrivere un programma per la gestione dell'inventario di un negozio. Per semplicità, consideriamo un minimarket con una sola cassa, con un computer. Il proprietario inserisce nel programma il materiale acquistato dal grossista, indicandone la quantità precisa, e il materiale acquistato dai clienti, anche in questo caso indicandone la quantità; il programma calcola la differenza e segnala quando c'è bisogno di comprare nuovi oggetti dal grossista.

In questo caso, si possono individuare i seguenti "attori":

il cassiere che comunica con la finestra del programma
la finestra del programma
la base di dati dove è memorizzato il materiale

Closure di Javascript

"inner functions created inside of loops can be tricky, since each one has access to the same outer variables rather than grabbing a copy of the variables at the time the function is created or called" (fonte: http://stackoverflow.com/questions/111102/how-do-javascript-closures-work)

Differenze tra le closure di Javascript e le classi anonime del Java (i cui metodi cmq non sono closure, perché non possono modificare i valori dei metodi esterni):

(DA VERIFICARE la parte sul Java) le closure di Javascript vedono l'ultimo valore che le variaibli della funzione esterna avevano al termina della funzione esterna, mentre (VERIFICARE quanto segue) in Java le classi anonime vedono il valore assunto al momento dell'istanziazione della classe
...

IE6 aveva un memory leak nel caso in cui la closure veniva associata ad un oggetto del DOM. Comunque è un problema di IE6 (peraltro corretto nelle verisoni successive) e non di Javascript.

Collegamenti esterni:

[1]
[2] (leggere però tutte le risposte e tutti i commenti)
[3]