Newsgroup: it.comp.java
Titolo: Bruno,Cristiano, Le variabili membro public static final & Design di Java

Ciao a tutto il ng..
a seguito della discussione tra Bruno e Cristiano sulla "compilazione
incrementale" ho ritenuto giuto aprire un altro thread per riflettere e
sentire le opinioni di Bruno, Cristiano e di chiunque volesse dire la sua su
un argomento che è nato da quel thread "le variabili membro public static
final"..
Vorrei capire una cosa ...
Se (almeno da quello che mi è parso di capire da Bruno), non bisogna *mai*
definire in una classe delle variabili membro"public static final" perchè
vanno contro la filosofia OO ... allora mi chiedo ... visto che nelle
interfacce vi è la possibilità di definire delle *costanti*  le quali
vengono sempre considerate come *public static final* (e alle quali IMHO non
è possibile modificare tale visibilità)... vi è (per quanto modesto possa
essere) un problema di design interno a java?
Ciao ciao
Dani
--
Daniele Piras
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If at first the idea is not absurd then there is no hope for it. - Albert
Einstein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

......
Per come la vedo io, è l'unico modo per definire delle costanti,
accessibili ovunque
Carlo.

 accessibili ovunque
[CUT]
Anche io Carlo la vedo cosě .. altrimenti credo che non lo avrebbero
permesso nelle interfacce .. ma a questo punto .. ci sfugge qualcosa o a
volte non bisogna seguire in modo rigido la filosofia OO ?
Ciao ciao
Dany



Mah, direi di no, in realtà se i requisiti non cambiassero potrebbe avere senso dichiarare
attributi pubblici: sfortunatamente lavorando in questo modo quando il cambiamento avviene
(e di solito e' in agguato :-D) siete costretti a mettere mano ad una montagna di codice.
In generale, in Java (e in tutti gli altri linguaggi OO) si possono fare un sacco di
schifezze :-) sintatticamente legali e che ovviamente non hanno niente a che fare con
Object Oriented: penso sia praticamente impossibile creare un linguaggio che costringa
l'utente a comportarsi in un modo "corretto" :-), qualcosa si puo' fare ma non si puo'
fare tutto. Anche perche' neanche coloro che hanno sviluppato il core di certe routine
Java ci capiscono poco, ci sono errori gravi in molte parti delle librerie, e solo
ultimamente ci si sta "risollevando".
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola

 design interno a java? 
I miei $0.10: no.
Associare il principio OC direttamente a costanti e' imho esagerato: se una 
costante cambia il suo _valore_, non serve *modificare* il sorgente 
dipendente da tali costanti, solo ricompilarlo. Un buon makefile fa tutto 
il lavoro. 
In caso di componenti chiusi, entra in gioco il versioning - e non e' un 
caso che java metta a disposizione package sealing e versioning. In COP, ad 
esempio, l'idea di versioning di un componente e' essenziale al riuso tanto 
quanto, per dire, l'idea di incapsulazione, cosi' come le idee associate di 
freezing, deployment, e context assumptions di un componente, o la 
distinzione tra development, deployment e run time, eccetera. Che 
semplicemente, in OO (e negli anni '80 e '90, epoca da cui molti "principi" 
derivano) non erano ancora particolarmente considerate e/o chiare - a 
fronte di modelli e pratiche di sviluppo software decisamente diverse da 
quelle odierne.
Lo stesso principio OC e' talvolta discutibile - prendi ad esempio tutto lo 
sviluppo open source in cui l'adattamento via modifiche del sorgente 
debolmente coordinate e' _il_ meccanismo di base. In altre parole, come 
tutti i principi, devi esservi coerente solo se lo accetti - ma ci sono 
casi in cui puoi *non* accettarlo. :-)
Se dai un'occhiata all'articolo di Martin, noterai che ci cose alla Booch 
tipo "l'astrazione e' la chiave" (bene, bravo, bis - ma il problema e' 
trovare il giusto livello di astrazione per permettere estensione senza 
modifica.. c'e' gente che considera "QuadroDiPicasso" un'astrazione, e 
talvolta ha pure ragione :-), gli esempi sono del (solito, per quegli anni) 
tipo "figura"-"quadrato"-"rettangolo", che poco hanno a che vedere con le 
complessita' di gerarchie "reali". Non e' che sia un problema di Martin, 
che fa il suo lavoro e il suo punto benissimo, e' che - per quanto vorremmo 
- *non* ci sono principi generali applicabili immediatamente ad ogni 
situazione, ma si deve sempre ragionare in base al contesto o alle 
proprieta' desiderate. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

ObjectZone - 
http://space.tin.it/computer/csadun
---


 per le costanti :-), e quindi le costanti private vanno benissimo!
Premetto che nemmeno io volevo sminuire l'importanza e la necessità delle
costanti (secondo me l'utilizzo di costanti facilita e aiuta nello sviluppo
di un buon codice) ... la mia domanda era soltanto sulla dichiarazione di
costanti come "public static final" ..
La cosa che mi sembra più che altro strana è che all'interno di molte classi
di Java vengono utilizzate tali costanti ... un esempio per tutti è il caso
della classe Integer con le sue belle costanti public final static MIN_VALUE
e MIN_VALUE....
Secondo te sarebbe stato molto meglio avere due metodi getMinValue() e
getMaxValue() ?
Non credi che il problema si possa risolvere utilizzando un tool di
compilazione .. quale Ant o cose del genere?
Grazie per la tua riposta costruttiva e interessante come sempre ...


 design OO 
Be', tu sei un XPer, no? :-)
Come ben sai, il mio approccio e' diverso: il riuso io lo cerco, e 
costantemente, e devo dire con un certo successo. Nel senso, papale papale, 
che quando e se faccio qualcosa di extra-lavoro principale (dove ahime', di 
coding ne vedo ormai ben poco), ci metto in genere molto meno del tempo 
stimato *dal committente* assemblando quando possibile componenti gia' 
fatti e che conosco (il "che conosco" e' da stressare. "Riuso", alla fine, 
significa anche "facile trasferimento di conoscenza".. ma e' un discorso 
lungo e da fare separatamente). Oppure, in tutt'altro ambito, chiedi a un 
programmatore Win32/C++ che usa MFC (che e' per certi versi una libreria 
orribile) rispetto alle API dell'SDK. Quel codice *e'* riusabile, eccome.
Vero e' che, piu' il linguaggi evolvono, piu' quanto e' riusabile viene 
gia' fornito pronto. Ma questo indica solo che il riuso funziona, solo non 
necessariamente il riuso del *proprio* codice (che e' proprio il punto :-).
Io trovo anche utilissimo un approccio a generazione di codice - codice 
basato su una libreria predefinita, ma configurabile. In maniera casareccia 
(ehm, "manuale" :-), con generatori appositi; oppure, quando possibile, con 
meccanismi del linguaggio: ad esempio in C++, con tecniche di 
programmazione generativa si possono fare cose deliziose, riusabili e 
comprensibilissime (e, come ogni C++er degno di tal nome ti puntualizzera' 
spocchiosamente, *efficienti* :-) con poche linee di codice. L'approccio "a 
optional" (che si richiama all'idea di un'automobile venduta cn una lista 
fissa di optional configurabili in fabbrica per poco prezzo) e' da questo 
punto di vista estremamente interessante.
Infine, dipende molto anche dal tipo di progetto: per dire, le collection 
classes di Java sono 'na bellezza, e riusatissme, ma uno deve avere il 
posto di lavoro di Josh Bloch per fare una cosa cosi'. :-)



Sicuramente si. Pero' posso chiedere a tutto l'universo di usare ant o un make o un ide,
c'e' sicuramente qualcuno che non lo fa. Piu' importante ancora, cosi' tu curi il
_sintomo_, non la falla nel tuo design.



Beh, adesso che lo dici, personalmente mi sto rifacendo pure quelle (e meglio :-D, quelle
attuali stra-violano un immensita' di principi OO e di design). Pero' lo faccio a mano a
mano che ne ho bisogno, e probabilmente il framework non verra' fuori prima di una
manciata di anni. Beh, chi se ne frega! Nel frattempo il cliente e' contento, io mi
diverto, e magari qualcosa poi verra' fuori, da me o dal mercato.
Ciao,
    Bruno.


Okay, allora mi trovo benissimo a riusare software degli altri :-).
Che e' esattamente il punto del riuso. Per gli altri, tu sei parte degli 
altri. :-)



<RANT>
Mi piace quando tagli cosi' i quoting, e' quasi come prendere una parola qui e una la e
formare delle nuove frasi... interessante. Comunque so che non e' colpa tua :-D, che non
vuoi offendere e che non c'e' malizia: penso anche che non sia necessario per l'ennesima
volta riquotare completamente la frase, vero? I due lettori attenti che ci seguono spero
che avranno la pazienza di farlo.
</RANT>
A me personalmente sembra ci sia una grossa differenza fra i due approcci: perseguire il
riuso come un fine in contrasto ad arrivarci incrementalmente, riconoscendolo. Io
ovviamente sono per la seconda ipotesi.


</RANT>
Per il resto, domani (ho fame! :-)


Due? Io e te, intendi, vero? :-)
Anch'io vi seguo. Attentamente :-)
-- 
Ciao
	Fabrizio C.

 Anch'io vi seguo. Attentamente :-)
Ci sono anche io che seguo attentamente ciò che dicono ...
Che dici Fabrizio forse i due a cui alludevano siamo noi? :-))


 Due? Io e te, intendi, vero? :-)
Tre, se vi consola...
Non sono intervenuto prima in quanto per qualche giorno non
ho avuto modo di leggere i messaggi... ;)
Devo dire che concordo con Bruno quando afferma che NON
ha lo stesso costo un design riusabile rispetto ad un
design "fortemente verticalizzato" (cioe', per dirla breve,
rispetto a un NON design! ;)
Purtroppo il problema della mancanza di conoscenza "teorica"
(e lo metto tra virgolette perche' se tale conoscenza non la
si cala nella pratica si rimane a livello 2, in base alla
"Scala Sadun" ;), e' un problema che, almeno in italia,
riguarda in gran parte anche i project manager (ne esistono? ;)
E' vero che il riuso puo' essere fatto pagare al cliente,
ma se il manager del progetto non afferra tale concetto, e' 
assai difficile fargli capire che con un po' di tempo in piu' 
si possono ottenere vantaggi (soprattutto interni) che si 
ripagano abbondantemente con il tempo. 
Pero', almeno per la mia esperienza, sembra sempre che le azienda
che sviluppano software debbano chiudere al termine del 
progetto che stanno sviluppando oggi!
E poi, a parte il discorso del riuso, credo che l'obiettivo
principale dell'applicazione di buone tecniche di design sia
il perseguire la realizzazione di software robusto, testabile
e estendibile, ma rimanendo nel dominio per il quale e' stato 
progettato. Sembra una affermazione ovvia, ma tante volte mi 
sono sentito dire dal project manager: "vabbe', 
hai fatto gli oggetti e questa cosa qui adesso mi vieni a 
dire che non si puo' fare: ma allora se la realizzavo io 
in VB facevo prima!"
In realta', "questa cosa qui" era completamente al di fuori
del dominio di flessibilita' previsto dal design originale,
ma questo poco conta... :(
Un ultima cosa: gli articoli di Martin li ho letti e studiati 
(insieme a molti altri testi sui principi dell'OO), e ritengo
che debbano entrare a fra parte del bagaglio culturale fondamentale
di chiunque voglia produrre software OO, sia esso un programmatore,
oppure un designer, oppure una qualsiasi altra figura che entra
attivamente in un progetto di sviluppo software.
La consapevolezza di cio' che si sta facendo e' il primo passo
verso la realizzazione di software di buona qualita'.
Purtroppo credo che la realta', almeno in italia, sia 
alquanto deprimente sotto questo punto di vista.
Saluti
e buon lavoro
Roberto
-- 
+-------------------+
| Bagnoli Roberto   |
| Nouvelle srl      |
| MODENA (ITALY)    |
| 
rbag...@orion.it
 |
+-------------------+

Che dici Fabrizio forse i due a cui alludevano siamo noi? :-))
No, siamo almeno in tre.
Umberto


A me da fastidio che si prenda un pezzo di frase e mi si facciano dire cose che non ho
detto, anche quando non ce n'e' l'intenzione.


cose che non ho detto, anche quando non ce n'e' l'intenzione.
Ma e' l'essenza della comunicazione. Se ogni volta che ti cito devo 
ripetere *tutto* l'ambaradan, la cosa diventa ingestibile (e il thread 
illeggibile) dopo tre minuti - e allora si' che non lo legge nessuno. 


 l'astrazione si alza, ma non abbastanza. 
Dipende da cosa intendi per business logic. Esempio: un componente che ho 
usato spesso con successo e' una package che fa una cosa semplicissima, ma 
in modo assolutamente affidabile e preciso - come un orologio svizzero: 
polling di files in una o piu' directory. Chiaro che di per se' questa non 
e' business logic in senso stretto; nel senso, non ti metti a parlare al 
tuo CEO di far soldi vendendo/implementando polling su directory, ne' files 
e directory sono "business objects" in qualunque applicazione (che non sia 
un filesystem, s'intende ;-).
Ma accade che il polling su directory sia un passo cardine per moltissime 
*implementazioni* di processi di business _assolutamente diversi_ che 
implicano comunicazione tra sistemi indipendenti (dal trasferimento di 
transazioni tra banche, per dire, alla piu' recente che mi e' capitata un 
mese fa - scambio di dati da un pool di energia ai sui clienti). Business 
completamente diversi, con diverso gergo, modus operandi eccetera, ma in 
cui l'astrazione "comunicazione" e la sua implementazione mediante scambio 
di dati su filesystem (del tutto troglodita, son d'accordo, ma appunto 
*non* sto usando un occhio tecnologico :-) sono assolutamente riusabili.
Un altro esempio: sforzi come RosettaNet e simili stanno - in un campo 
limitato - automatizzando e rendendo possibili componenti riusabili che 
gestiscano direttamente *colloqui* decisamente a livello di business. Non 
e' realta' oggi, certamente, ma non sarei sorpresissimo se "Windows 2010 
Bookseller edition" se ne venisse fuori con un oggetto COM che implementa 
acquisto/vendita e gestione di libri.
Oppure guarda a quello che e' stato *il* mercato IT per eccellenza negli 
anni '90, e in parte e' ancora.. gli ERP. Cosa sono, se non pacchetti in 
cui la logica di business e' assolutamente riusabile? Tecnologicamente 
deprecabili spesso, ma che catturano l'idea fondamentale per qualunque non-
informatico: il riuso di X ha come fattori costi/benefici di 
implementazione/adattamento di qualcosa di esistente rispetto a 
costi/benefici di riscrittura (che poi il la formula sia stata miscalcolata 
per molti ERP e' vero, ma un'altro discorso ;-).
Diverso il discorso con cose come "pool di thread" o "transazioni 
distribuite", eccetera. Cose come queste (utilissime) tendono ad essere 
piu' "dipendenti" da una certa implementazione, ambiente, o tecnologia - 
son piu' inerentemente "tecnologiche", meno "strutturali" se vuoi a 
processi di *business* e piu' al fatto che una certa implementazione e' 
fatta in un certo modo.
Tempo fa, usavo parlare di "architettura" per connotare il livello "di 
business" - il problema di trasferire informazione, ad esempio, e' 
architetturale e presenta caratteristiche e comportamenti simili 
indipendentemente dalla tecnologia; e di "design" a livello, come dici tu, 
di "astrazione tecnica" (le collections, o qualunque libreria "classica" ne 
sono un esempio perfetto). Ho poi notato che la semantica prevalente di 
queste due parole non si e' evoluta in quella direzione, e che anzi 
"design" e "architettura" stanno tendendo ad assumere sempre piu' 
significati fino a ridursi ad un brodo semantico che vuol dire tutto e 
niente... quindi adesso sono a corto di buoni classificatori. :-)
Un punto importante e' che per catturare astrazioni "di business" 
continuano a servire informatici: perche' ogni specialista di dominio, in 
genere, tende proprio a vedere aspetti, usare gergo, enfatizzare o no 
relazioni specifiche con l'occhio ...dell'esperto di dominio.
La cosa e' difficile perche' servono informatici che passino, in qualche 
modo, attraverso *molte* diverse esperienze di business, e siano in grado 
di coglierne, quando possibile, gli aspetti strutturali, le astrazioni che 
sono "the key" :). 
Anche in presenza di persone di capacita' adeguata, questo richiede un 
sacco di tempo e volonta'.
E' interessante notare che per ogni buon informatico e' ragionevolmente 
facile estrarre queste astrazioni dove il dominio e' ...l'informatica: e' 
per questo che ci sono in giro un sacco di buoni componenti "tecnici" 
riusabili - chi modella il componente e' padrone *sia* del dominio 
"applicativo" che del mezzo di implemetazione. 
Per domini non-informatici (ovvero, quasi tutti quelli che pagano :-) si 
oscilla spesso tra visioni totalmente orientate al business (e 
inerentemente non riusabili, perche' appunto deformate dalla lente del 
dominio) a cose troppo ingombranti, inefficienti e lontane dal dominio da 
essere di qualche utilita' pratica - e in genere troppo dipendenti 
dall'aspetto tecnico. 
Ovviamente ci *sono* le vie di mezzo, ma sono poche ed e' raro essere cosi' 
fortunate da vederle al lavoro. 


 E' vero che il riuso puo' essere fatto pagare al cliente,
Il punto e' che scrivere codice riusabile spess costa si' un filo di piu' 
di codice non riusabile (e quindi si va in perdita se questo riuso non si 
concretizza), ma in un sacco di situazioni costa *trascurabilmente* di piu' 
- se appunto si da' alla questione l'attenzione che merita.



Secondo me invece questo succede invariabilmente quando i post diventano troppo lunghi: io
ad esempio cerco sempre di essere sintetico, e di norma rifattorizzo due o tre volte il
messaggio prima di postarlo.



Qualunque via che decide il cliente e' la mia via. Certo, io posso consigliarlo, cercare
di guidarlo di quando in quando, ma lui conosce il suo business, solo lui mi puo' dire
cosa e' piu' strategico e io devo dare il massimo perche' le sue aspettative vengano
soddisfatte. Il mio fine non puo' essere il riuso, io deve essere in grado di fare mio
l'interesse del cliente, e spendere i suoi soldi per fare cio' che interessa a lui, non
quello che interessa a me. Lui mi paga. :-D


 Non concordo.
Benissimo - il mondo sarebbe noioso se tutti avessero le stesse idea. :-)


 devo dare il massimo perche' le sue aspettative vengano soddisfatte.
Ma le due cose (che lui dica cosa e' piu' strategico per lui e che io
dica *come* costruirlo) non sono in conflitto. Il livello di strategia
in cui si pone la scelta funzionale (cosa il sistema deve fare) c'entra
poco con il riuso interno o meno di componenti. 
Cio' che un cliente sa e' che vuole, per dire, permettere ai suoi
clienti di ordinare biglietti aerei via internet, od offrire ai suoi
clienti statistiche precisa sull'uso dei suoi servizi, o permettere ad
un partner di osservare i suoi livelli di magazzino in tempo reale
eccetera eccetera ...il tutto in tempi e costi stimati, con un margine
d'errore concordato. 
Se io so come usare componenti riusabili, potro' stimare costi e tempi 
inferiori. Ma perche' qualcuno li possa usare, i componenti devono essere 
prima scritti da qualcun'altro (o da te stesso prima :-). 
Siccome *senza* riuso quasi tutti i sistemi moderni avrebbero costi e
tempi proibitivi (per dire, immagina scriversi un webserver per ogni
applicazione web.. :-), questi costi qualcuno li deve sostenere. 
Io preferisco indicare chiaramente dove, come e quando, tutto qui. :)



Mi sembra di no, che ai tuoi clienti tu non dica affatto come spendi i loro soldi.
Una nota finale: a questa posizione etica verso il cliente io ci credo _fermamente_, ed e'
un valore che ho maturato con il tempo. Quello che cerco di fare e', mantenendo sempre
fermi i miei valori (fra i quali questo) cercare di lavorare meglio, e ho individuato un
metodo che a mio parere mi consente di farlo. 
Comunque questa discussione mi piace, andiamo avanti!


 Comunque questa discussione mi piace, andiamo avanti!
LOL con piacere. E' sempre piu' interessante che fornire codice per trovare 
il massimo tra quattro numeri... ;-)


 
hubris è, nella letteratura greca antica, l'atto di superbia
dell'uomo, peccato supremo contro la divinità (che di solito si
incazzava parecchio :)
Mentre Horowaks? (se era una battuta/messaggio, temo di non averlo
capito...)
ciao
tityrus


Rispondevo apposta con una cosa assolutamente sconosciuta :-) 
Comunque, gli Horowaks sono una tribu del piano di Amerindia dell'universo di
Jadawin/Wolff nel ciclo "Fabbricanti di Universi" di Philip Jose' Farmer.
