Newsgroup: it.comp.java
Titolo: Perplessità sulle INNER CLASSES...

Cari programmatori, volevo chiedervi se secondo voi le INNER CLASSES
sono utili anche nel caso in cui il codice che costituisce la "Inner
Class" sia di parecchie linee.
Mi spiego: da quel che ho capito il vantaggio delle INNER CLASSES è,
se ho una classe A che è la sola ad utilizzare un metodo della classe
B, e se la classe B deve/può essere vista solo dala classe A e da
nessun'altra classe, a scrivere il codice della classe B  *dentro* la
classe A e in particolare *vicino* alla chiamata in A del metodo di B.
Quindi il vantaggio sarebbe da una parte l'information hiding e
dall'altra una maggiore "logicità" nella vicinanza di pezzi di codice
attinenti. E' così o mi sbaglio?
E, in particolare, se la classe B fosse composta da parecchie linee di
codice, non si avrebbe un PROBLEMA DI LEGGIBILITA' della classe A, che
si troverebbe ad ospitare il lungo pezzo della classe B al suo
interno?
Quali sono i VERI vantaggi delle inner classes?
Sperando che mi diate qualche dritta sulle INNER CLASSES vi saluto e
vi ringrazio in anticipo.
Elisa

classe A e in particolare *vicino* alla chiamata in A del metodo di B.
Non c'e` solo questo: le inner classes sono anche il quasi-equivalente
delle CLOSURE, un paradigma di programmazione potentissimo.
Abelson e Sussman, "Structure and Interpretation of Computer
Programs", presentano molto bene le closure (usando il linguaggio
Scheme, simile per vari versi al Lisp).  In Scheme, puoi usare le
closure per fare un po' di tutto.  Le inner classes hanno piu` limiti
(Java non ha un vero Lambda di Church, la chiusura lessicale e`
limitata ai campi const), ma, in congiuzione con altri meccanismi
(OO), si puo` fare un po' di tutto.
Alex

 Quali sono i VERI vantaggi delle inner classes?
Io personalmente uso le inner class solo per la gestione degli eventi,
perche' sono molto comode per realizzare i vari listener.
E' vero che ogni inner class si traduce poi in una classe in piu'
sul server, e se si sta realizzando un applet e' una classe in piu' da
scaricare, pero' se si mette poi tutto in un Jar non cambia molto dal
punto di vista delle prestazioni, no?
Infine, vorrei pregare Alex Martelli di spiegare in poche parole 
(se e' possibile!) cosa sono le closure in un linguaggio di
programmazione,
perche' io non lo so proprio. Grazie!
Ciao,
  Marina

Quali sono i VERI vantaggi delle inner classes?
Sono indispensabili per creare interfacce in modo comodo: quando
scrivi una classe che estende qualche altra classe, non puoi anche
dire che estende un Adapter, perciò o usi una inner class o dici che
la tua classe implementa il relativo Listener, ma poi ti devi scrivere
anche tutti i metodi vuoti.
tutorial/ui/swingEvents/generalrules.html#innerclasses
per avere maggiori info.
--
Bye,
  Dario
ICQ: 
http://wwp.mirabilis.com/11871099
Remove anti-spam from e-mail address

programmazione, perche' io non lo so proprio. Grazie!
Prego... ci provo!
In parole povere, una closure e` "una funzione" che "si porta
dietro" la propria ``chiusura'', cioe` l'insieme di associazioni
fra nomi e valori, lessicamente determinate alla creazione.  E`
un modo alternativo ad una classe di fare un "bundle" di codice
e dati; i due approcci, tuttavia, possono anche essere usati
assieme, e, visto che coprono esigenze diverse, hanno anche
una buona sinergia in certi usi congiunti.
L'uso "completo" delle closure presuppone un linguaggio di
programmazione in cui le funzioni sono "soggetti di prima
classe", cioe` possono essere create, passate come
argomenti, tornate come valori, eccetera; in Java, come nella
maggior parte dei linguaggi (con la notevole eccezione di
quelli tratti dal Lisp) le funzioni non sono "di prima classe" --
lo sono, tuttavia, le classi (beh, quasi -- non e` agevole
creare una nuova classe al volo -- tuttavia, il "caricamento
dinamico" di classi puo` approssimare questa "creazione");
e una classe puo` in particolare incapsulare una funzione
(o famiglia di funzioni) asserendo di implementare una
interfaccia.  Attraverso questi schemi, si possono in pratica
implementare le closure (o quasi) come classi, specialmente
come classi interne visto che in questo caso il linguaggio ci
assicura le "connessioni" ("binding") lessicali necessarie
(purtroppo, per ragioni di prestazioni, ai soli elementi "final"
del contesto lessicale, ma e` una limitazione ragionevole).
Facciamo un esempio.  Diciamo che la famiglia di
funzioni che mi interessano sono tutte e sole quelle che
prendono un double e tornano un double (Java essendo
un linguaggio "compile-time type-safe", e` necessario
precisare queste cose!).  Anzitutto, modelliamo l'intera
famiglia con una interface:
    interface Funzione {
        double f(double x);
    }
Riferimenti a Funzione possono ora essere passati
come argomenti, tornati come risultati, eccetera, insomma
siamo un pezzo avanti perche` siano "di prima classe".
E` anche gia` facile concepire vari brani di "codice
cliente" che USANO un riferimento-a-Funzione: ad
esempio, uno ne fa il grafico, un altro ne calcola
numericamente l'integrale definito, eccetera.
Ma come possiamo "generare" (o simulare la generazione)
questi "riferimenti-a-Funzione"?  Chiaramente, ognuno
dovra` "sotto sotto" riferirsi ad una class che asserisce
"implements Funzione" (e implementa l'opportuno metodo f).
Ma se e` una classe interna, possiamo anche lasciare
anonima la class vera e propria, e avere un metodo
generatore del tipo:
    class Lineare {
        public static Funzione aPerXPiuB(final double a, final double b) {
            return new Funzione() {
                public double f(double x) {
                    return a*x+b;
                }
            };
        }
    }
Chiamando Lineare.aPerXPiuB(1.2,3.4) si ottiene cosi`
una specifica Funzione, "costruita al volo" sulle nostre
esigenze -- con a e b "fissati", ovvero "chiusi" (vedi il
"final" nella loro dichiarazione).
Naturalmente, potrei ottenere lo stesso effetto
"rivoltando come un guanto" le cose, dal paradigma
di closure a quello O-O, ad esempio cosi`:
    class Lineare implements Funzione {
        final double a;
        final double b;
        Funzione(final double a, final double b) {
            this.a = a; this.b = b;
        }
        public static Funzione aPerXPiuB(final double a, final double b) {
            return new Lineare(a, b);
        }
        public double f(double x) {
            return a*x+b;
        }
    }
Qui devo gestire esplicitamente i binding (il che, in un caso
cosi` semplice, non e` un problema -- ma in un caso piu`
complicato potrebbe essere almeno una scocciatura); inoltre,
non c'e` uno specifico modo di chiarire al codice cliente che
da questo esso riceve SOLO ED ESCLUSIVAMENTE un
riferimento all'INTERFACCIA Funzione -- abbiamo dovuto
dare un nome alla classe che implementa Funzione, quindi
il cliente "sa" di questa implementazione, anche se, tenendo
non-public il costruttore e canalizzando la costruzione sempre
attraverso lo stesso metodo static, un po' di controllo in merito
lo abbiamo pur sempre mantenuto.
Analogamente, possiamo procedere (per closure, o, con
maggiore complessita`/exposure, riducendo a OO) per
funtori di ordine superiore.  Le inner classes (closure) mi
permettono di fissare automaticamente e implicitamente i
parametri rilevanti all'atto della creazione; l'approccio OO
diretto/completo da` piu` flessibilita` (i parametri potrebbero
non essere final, ecc), ma, quando questa flessibilita` non
serve, richiede comunque di "dettagliare tutti i passaggi",
dare nomi a classi/parametri/ecc, e cosi` via.
Alex

                }
Questa roba non la capisco. Sembra essere una definizione volante di una classe
anonima che implementa l'interfaccia Funzione, pero' e' una sintassi che non
conosco  :-(
Le "INNER CLASSES" sono sempre esistite ?
Ciao
---------------------------------------
Email: sostituire "nospam" con "uol"

Le "INNER CLASSES" sono sempre esistite ?
No, solo da Java 1.1.0 (cioe` da un paio d'anni); in 1.0.0 non c'erano,
e meno ancora _prima_ di Java 1.0...:-).
Alex