Newsgroup: it.comp.java
Titolo: E' esatto?

Dire che una classe java dovrebbe essere vista come
   il costruttore/i,
   il codice che implementa la interfaccia implicitamente definita da
      i metodi non private
      le variabili final
più le variabili non private?
Nicola Grippaldi

 Dire che una classe java dovrebbe essere vista come
Dipende dal motivo per cui la stai guardando. :)
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 Dipende dal motivo per cui la stai guardando. :)
Come uno che vuol pensare OO.
Mi spiego meglio.
Java permette di utilizzare degli oggetti software dichiarando
preliminarmente il tipo, che può essere una classe o una interfaccia.
Sarò permaloso, ma mi sembra intollerabile!!! O classe, o interfaccia.
Cosa significa che due cose diverse sono utilizzabili allo stesso
modo?
Che roba è questa? Polimorfismo? Idee poche ma confuse?!?!
Se vado poi a vedere il funzionamento di un programma nella teoria
dell'OOP... scopro che c'è solo il concetto di oggetto (richiamo del
costruttore di una classe) e di responsabilità dell'oggetto (metodi
pubblici della classe).
Ma non mi pare che sia direttamente necessario il concetto di classe. 
Piuttosto c'è il concetto che il buon programma di una volta è
diventato un sistema di controllo delle interazioni tra gli oggetti
(forse il senso del metodo main?)
Mi sembra che una classe sia "solo" il codice necessario per
implementare concretamente una interfaccia. Prima viene l'interfaccia,
poi da qualche parte ci sarà inevitabilmente una classe da istanziare
concretamente. Se questo è vero non si può programmare a oggetti se
non si è in grado di fare analisi.
Nello stesso tempo l'interfaccia Java mi sembra rispondere molto bene
alla corrispondente definizione dell'OOP.
Mi sembra quasi che Java, consentendo le variabili non private abbia
autorizzato un uso non OO del linguaggio, che forse era meglio
evitare. O no?

 evitare. O no?
Incapsulare i dati è (spesso) MEGLIO, non OBBLIGATORIO.
Anche in C++, per esempio, puoi avere variabili pubbliche.
Ciao

 evitare. O no?
Beh, penso di diventare noioso se mi ripeto ancora nel dire che java non 
vuole essere così rigoroso.
Era meglio evitarlo? Sinceramente non credo. Non bisogna dimenticare la 
sottile (neanche tanto) parentela di java con dei linguaggi che hanno 
grandi estimatori proprio per la grande flessibilità. Io certo sono un 
estimatore del codice puro ma in the real world ci si scontra sempre in 
esigenze di flessibilità.
Applicando ad esempio il tuo modello OO rigoroso per cui la classe è solo 
implementazione mentre i tipi sono solo interfacce, in pratica perderebbe 
ogni senso la caratteristica (utilissima) di una classe di poter 
implementare più interfacce. Oppure bisognerebbe rendere moooolto morbido 
il controllo sui tipi in compilazione (mamma mia...).
Insomma, su... chiudi un occhio :-)

 
Analisi significa capire cosa deve fare il programma dal punto di
vista dell'utilizzatore finale. Dato che le responsabilità degli
oggetti softaware possono essere assegnate in infinite infinità di
modi, mi pare indispensabile dover partire dalla analisi.
Ciao

 Insomma, su... chiudi un occhio :-)
Certo..certo....
Solo che mi sono convinto che finalmente l'informatica sta uscendo
dalle caverne e java è la migliore opportunità che ho mai visto.
Ciao

 evitare. O no?
Bah, a parte che la questione e' un po' di lana caprina :), un attributo 
pubblico non mi pare abbia niente di non-OO: che intendi? 
Certamente, non si presta alla maggioranza di situazioni in cui vuoi 
modellare qualcosa con un attributo (e infatti e' un costrutto che non 
trovi spessissimo). Pero', immagina - che so - una bacheca 
all'universita'.. quello e' un attributo pubblico. :)



Forse hai ragione, ma l'idea di responsabilità di un oggetto mi porta
a intenderla sempre come metodo
Ciao

 a intenderla sempre come metodo
E' che non capisco in che senso un attributo pubblico non sarebbe OO.
E' esposto da una classe, ma disponibile senza sue intermediazioni: per 
quella parte di stato, la classe non si assume responsabilita'.
Come le bacheche, appunto. :)


 ha scritto nel messaggio
news:30971c5e.03010...@posting.google.com...


 Now I just try to write good code, and find that it has good design.
Quello che manca a quella frase e' la nota a margine "funziona se sei 
bravo". :)


 ..
Il tuo punto di vista č molto legato al codice. Quel vero e proprio diamante
che č una classe java ha perņ tante sfaccettature, e limitarci ad ammirare
un diamante soltanto da un profilo č alquanto limitante. Si potrebbero
piuttosto aggiungere altre definizioni, da quella che dice che una classe č
lo stampino che ci permette di creare degli oggetti, a quella che tira in
ballo Platone e le sue Idee. E poi rifletti: se osservassi la classe java
quando č ormai ridotta a bytecode, che cosa vedresti? Sequenze di istruzioni
a 32 bit. E ciononostante quella non č ancora una classe java?
-- 
Ale
La RFD originale per it.comp.dotnet su
http://www.sen.it/stoa/articles.asp?id=10


Il mio problema forse è solo cretino.
Mi riferivo al fatto che l'accesso alla bacheca da parte di un metodo
client deve avvenire con un metodo get della classe che "espone" la
bacheca e non accedendo direttamente alla variabile.
PS.:
LOL, IMHO etc.. dove le trovo spiegate?

 LOL, IMHO etc.. dove le trovo spiegate?
Nel Jargon file. Cercalo con Google.
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 bacheca e non accedendo direttamente alla variabile.
Facevo l'esempio della bacheca proprio perche' una bacheca e' "esposta" da 
un'organizzazione senza alcuna mediazione - e di conseguenza 
l'organizzazione non ha/fornisce alcuna garanzia sul suo contenuto: sia 
persone interne che esterne possono semplicemente leggerne i contenuti in 
un dato momento.
