Newsgroup: it.comp.java
Titolo: Due domande provocatorie

1) E' vero, secondo voi, che chi usa Java raramente produce del vero codice
a oggetti?
2) Se sě, perché? Colpa della sintassi, di una mancanza di cultura, o del
fatto che il tempo č sempre troppo poco per progettare oggetti realmente
utili e riusabili?
Ciao,
Alessio.

: 

?

?? 
:-)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 utili e riusabili?
La seconda che hai detto. Mancanza di cultura da parte del programmatore
improvvisato dall'oggi al domani (coi tool Microsoft è tutto così
semplice... disegni la mascherina, piazzi un bottone quà, un controllo
là... classi? che roba è?) ma anche mancanza di cultura da parte del
manager che dopo un giorno vuole già vedere "qualcosa di funzionante" e
chi se ne frega di come è scritto il codice. Purtroppo "riusabilità del
codice" viene spesso tradotto in "taglia e incolla"... 
Ciao, Cris
-- 
Cristian Veronesi ><((((º> 
http://www.crpa.it
"Ogni limite ha una pazienza" (A. De Curtis)

 >del fatto che il tempo è sempre troppo poco per progettare oggetti


per domani.... 
Imho, la seconda che hai detto - ma non e' che abbia dati statistici. :)
Puoi avere il linguaggio piu' bello del mondo, ma se non hai le idee,
parlerai sempre male. :)


> a oggetti?
CV> Per quanto riguarda Java in particolare non so, in generale credo di
CV> potere affermare che non sempre chi dice di sapere programmare produce
CV> poi del codice decente (basta guardare come sono scritte la maggior
CV> parte delle applicazioni basate su VB).
MI chiami ad oggetti il VB (mio bagno penale) ?
CV> La seconda che hai detto.
Concordo.  Stranamente è più  facile trovare  gente che  acquisisce la
mentalità giusta tra chi ha cominciato col C nudo e crudo...
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )


Perche forse quel tipo di progetti non hanno una fondamentale necessita' di
essere sviluppati con un linguaggio ad oggetti, laddove la complessita' del
sistema aumenta di conseguenza aumenta anche la necessita di un buon design
ad oggetti.


Continuiamo con le provocazioni, che apprezzo particolarmente per
tirare fuori qualcosa di diverso dai soliti concetti 'sparati' qualche
volta a caso xchè letti da qualche parte:
Raramente si vede del codice OO in giro: cosa vuol dire codice OO?
 - non elencare le qualità del software più o meno teoriche e più o
meno raggiungibili: voglio sapere i 'cosa' e non gli ipotetici
effetti.
Il riuso non esiste, se non nei libri
- definizione di riuso, un po' abusata e di cui si parla a sproposito
- esperienze PRATICHE di riuso in progetti reali: non servono
citazioni da libri
Differenze fra componenti ed oggetti, se ci sono. Un software scritto
con gli EJB in quale misura è OO?
Cosa è l'incapsulamento, differenze con l'information hiding (se ci
sono)
- i getter e i setter incapsulano qualcosa?
- incapsulare vuol dire mettere private agli attributi ed avere metodi
public x leggergli?
ciao ciao, buoni pensieri
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services
     /_____/ \/ / /          
    /_____/ /   \//\         SUN Microsystems Italia S.p.A.
    \_____\//\   / /         Via Romagnosi, 4
     \_____/ / /\ /          00196 - Rome (RM) - Italy
      \_____/ \\ \           @mail : 
ugo.l...@sun.com
       \_____\ \\            Phone : +39 (0)  6 xxxx.xxx
        \_____\/             GSM   : +39 (0)  335 7766651

ereditarietà e polimorfismo ottiene riusabilità.
riuso = chimera. Eleviamo il livello della provocazione.
ciao



E quello, giustamente, risponde chissenefrega.
Ultima provocazione (giuro):
I Design Patterns si applicano:
- mentre si scrive il codice?
- prima di scriverlo?
- dopo?
- in tutti i casi precedenti?
- mai?
Risposte da esperienze REALI, pls. 



Continuiamo con le provocazioni, che apprezzo particolarmente per
tirare fuori qualcosa di diverso dai soliti concetti:
Raramente si vede del codice OO in giro: cosa vuol dire codice OO?
 - non elencare le qualità del software più o meno teoriche e più o
meno raggiungibili: voglio sapere i 'cosa' e non gli ipotetici
effetti.
Il riuso non esiste, se non nei libri
- definizione di riuso, un po' abusata e di cui si parla a sproposito
- esperienze PRATICHE di riuso in progetti reali: non servono
citazioni da libri
Differenze fra componenti ed oggetti, se ci sono. Un software scritto
con gli EJB in quale misura è OO?
Cosa è l'incapsulamento, differenze con l'information hiding (se ci
sono)
- i getter e i setter incapsulano qualcosa?
- incapsulare vuol dire mettere private agli attributi ed avere metodi
public x leggergli?
ciao ciao, buoni pensieri


...
Continuiamo con le provocazioni, che apprezzo particolarmente per
tirare fuori qualcosa di diverso dal solito:
Raramente si vede del codice OO in giro: ok, ma cosa vuol dire codice
OO?
 - non elencare le qualità del software più o meno teoriche e più o
meno raggiungibili: vorrei ascoltare i 'cosa' e non gli ipotetici


 public x leggergli?
NO!!!!!!!!!!!!!!!!!!!!!
Vuol dire avere degli attributi di cui l'utente ignora l'esistenza.
Tu sai che in button ci sono dei rettangoli, c'è la posizione del primo
carattere, in un frame c'è la variabile spessore del bordo. Le chiami mai?
No.
Ciao.
Ale

Risposte da esperienze REALI, pls. 
Considerando "scrivere" come design+codice, mentre. Applicare patterns e' come saper usare i congiuntivi. 


        \_____\/             GSM   : +39 (0)  335 7766651
|
| Bruno Bossola
| A Java Software Engineer :-)
|

public x leggergli?
Incapsulamento - cito una definizione di Michela e Andrea 
"Un oggetto è composto inscindibilmente di uno stato e di operazioni che si applicano su
di esso. E' possibile accedere allo stato di un oggetto solo attraveso l'insieme delle
operazioni da esso esposte e mai direttamente." 
 
Information hiding - cito una definizione di Silvia:
"Possibilità che un oggetto ha di differenziare l'accesso senza per questo contraddire il
principio dell'incapsulation. Ad esempio ognuno di noi è ben incapsualato, ha dei propri
pensieri e delle propie idee: nel momento in cui qualcuno ci chiede la nostra opinione su
una determinata cosa, siamo liberi di rispondere in modo più o meno trasparente e
soprattutto in maniera differente a seconda del nostro interlocutore."
Bella eh? Anche l'esempio e' molto ficcante! Certo che c'e' molto Francesco dietro... ;-D
Ciao,
    Bruno.
P.S.
Ugo, io da un po' sto cercando di scrivere un libro su OO, Java e UML in italiano... ti
interesserebbe unirti? All'epoca chiesi anche a Cristiano... 


 writes:
UL> - esperienze PRATICHE di riuso in progetti reali: non servono
Come detto altrove,  riuso di logiche businnes se  ne vede assai poco,
molto piů comune  č il Meta-W programming (Cut & Paste)  o il riuso di
librerie, ma questo ha poco a  che vedere con lo OO. La programmazione
a oggetti permette  il riuso nel momento in  cui si sviluppano oggetti
di uso generale e non legati ad una certa applicazione.
UL> - i getter e i setter incapsulano qualcosa?
I Get() e  Set() incapsulano il valore cui  accedi tramite loro. Ovvio
che tra  una variabile  pubblica ed una  coppia get&set che  assegna e
rende  il valore  senza controlli  o elaborazioni  meglio la  prima (i
cicli macchina costano poco ma  costano :) ) salvo alcuni casi (beans,
se non erro). 
Una controprovocazione :), a che si deve la raffica di post ? :)


Come detto altrove,  riuso di logiche businnes se  ne vede assai poco,
Si, infatti - e' semplicemente che per definizione le logiche di 
business son diverse a seconda del business :)
Tra parentesi, e' interessante notare come parte dello sforzo di noti
ERP vendors (leggi SAP, ma non solo:) sia proprio quello di definire best
practices per certi processi (e ovviamente implementarle col loro
software). 



In effetti č tanto tempo che non posto spesso, cerco xň di trovare il
tempo quando posso. Ma l'argomento mi interessa parecchio, xchč? 
ciao



Nessuno ti ha invitato ;)
Quello che dici non vale, vorrei i pareri di chi NON lavora in XP e ha
la fortuna di essere in un ambiente stimolante ed innovativo.
Soprattutto pareri 'tradizionali', ma motivati e 'giustificati' da
esperienze reali.



Utopia? Sono anni che dico che lo farò, ma non comincio mai. Mi ci
vogliono mesi x scrivere un articolo, penso che un libro su Java lo
finirei quando finalmente uscirà .net!



Daccordo. Allora chi è che parla tanto di riuso, di componenti
riusabili, ecc,? Voglio uno che mi dica che ha riusato del codice!!!!
(D'Alema, dì qualcosa di sinistra! N.Moretti)



Quanto meglio? E soprattutto: cui prodest?
Se dietro due metodi accessor c'č il membro nudo e crudo, quale
information hiding ho ottenuto? Quale informazione ho 'occultato' se
dai metodi si capisce benissimo che dietro c'č una String o un int?
Ok, ho un gancio per fare 'interpositioning' (alla EJB), ma questo č
Information Hiding?



Addirittura! Vabbe', vorra dire che leggerai prima il mio :-D
Ciao,
    Bruno.



Uh! :-D
Ciao,
    Bruno.


> 
UL> In effetti č tanto tempo che non posto spesso, cerco xň di trovare il
UL> tempo quando posso. Ma l'argomento mi interessa parecchio, xchč? 
No, mi  riferivo ai  post multipli (stesso  post + volte  - usualmente
colpa  di pulsanti che  danno un  feedback errato  come in  Netscape o
Outlook) e ovviamente era scherzoso.
Certi sassi nell'acqua sono comunque utili.


codifica. Sono OO?
Naturalmente. ;-)


> 
UL> Quanto meglio? E soprattutto: cui prodest?
Tanto  meglio. Una chiamata  a metodo  non final  se non  ricordo male
richiede  4  jump di  cui  2  fatti a  seguito  di  un  lookup in  una
tabella. Una chiamata ad un metodo final migliora la cosa di molto (ma
al prezzo  noto) ma non ricordo quanto  (la cosa la lessi  su Byte nel
'96). Un'accesso diretto non richiede salti :).
UL> Se dietro due metodi accessor c'č il membro nudo e crudo, quale
UL> information hiding ho ottenuto?
Nessuno, hai ottemperato perņ ad un protocollo che in alcuni casi č utile.
Altrimenti hai fatto solo zucchero sintattico.


>Il riuso non esiste, se non nei libri
Se si parla di riuso di componenti EJB all'interno della stessa
azienda su progetti differenti (ma con comuni denominatori
naturalmente) il riuso esiste.
Dipende dal grado di specializzazione dell'EJB, e da come è stata
implementata la separazione tra tier. Quasi sempre sarà possibile
appoggiare sul tier "business" un presentation layer qualsiasi; un po'
più difficile sarà separare gli EJB dallo strato sottostante.
Parlo di esperienze vere, non posso però andare oltre un certo limite
di dettaglio.
Umberto


Mi basta che mi dai delle percentuali di codice riusato da un progetto
all'altro.


Outlook) e ovviamente era scherzoso.
Vade retro Satana! Mai usato Outllloockkk. Comunque il mio ng reader
(FOrtč Agent) non mi ha segnalato probs.
Grazie per la segnalazione!



Scusa, intendevo l'inverso. Dicevo quanto č meglio avere dei setter al
posto del public, non considerando performance ma solo design etc.


 writes:
UL> Scusa, intendevo l'inverso. Dicevo quanto č meglio avere dei setter al
UL> posto del public, non considerando performance ma solo design etc.
Per  me per  nulla meglio  (IMNSMO).  Se  tu puoi  assegnare qualsiasi
valore legale  per il linguaggio ad una  variabile senza compromettere
la correttezza del codice allora l'uso di getter e setter č una scelta
deplorevole (salvo in casi particolari come i bean) in quanto a fronte
di  un  vantaggio  ininfluente  (solo  estetico) hai  una  perdita  di
prestazioni  che non č  affatto trascurabile  e questo  _č_ importante
nella progettazione di un sistema.
UL> Sun Educational Services
Migliorate i gadget ai corsi :) :) :) :) :) :)
Non pretendo un'altra Samsonite,  ma un palloncino con buon compleanno
Java... :) :) :) :) :) :)


all'altro.
Dipende dalle "affinità" tra progetti, non è facile dare percentuali.
Se sono previsti una serie di progetti simili, ad esempio portali web,
è possibile progettare già in partenza una serie di componenti
riusabili da tutti, e in quel caso si puo' parlare di riuso al 60%/70%
del codice.
Il discorso cambia se si parla della crezione di componenti "stand
alone" da mettere in bacheca e usare quando necessario, in questo non
siamo all'utopia, ma poco ci manca (l'utopia è infatti il passo
successivo descritto da alcuni malati del "component based": la
commercializzazione sul mercato di componenti software).
Comunque si potrebbe parlare ore di riuso, le sfaccettature sono
molteplici.
Umberto


Questo è la definizione di riuso classica e soprattutto diversa dal
riuso che c'è sempre stato prima dell'OO. Allora erano OO pure le
vecchie librerie C o Pascal o addirittura Assembly?
Quindi, o il riuso c'è sempre stato (ed è una fandonia quella che gira
come 'qualità del software' di un progetto scritto secondo i canoni
OO) o nessuno riesce ad ottenerlo xchè troppo complesso, o ancora
nessuno programma veramente in maniera OO. 
Cosa ne pensate?


      /_____\ \\ /           Sun Educational Services
Hem.. ma questi tuoi dubbi come sono interpretati dai "Sun Educational
Services"? :-) C'e` qualche domanda retorica o e` in arrivo una crisi
mistica ? :-))
[non voglio polemizzare, e trovo molto interessante questo thread..]


Ovviamente, l'ultima che hai detto!
E' sufficiente chiedere a qualcuno i principi del paradigma OO, e ti risponderanno
invariabilmente classe, ereditarieta' e polimorfismo :-D. Inoltre coloro che si dicono
esperto di OO sono tipicamente class-oriented :-), verticalisti (orientati cioe' alla
realizzazione di gerarchie piuttosto che di collaborazioni), focalizzati piu' sugli
aspetti statici dei problemi (class diagram a go-go, ad esempio) invece che sugli aspetti
dinamici, ed in genere cercano tecniche "meccanicistiche" da applicare1 (pattern, case, i
vari processi...) invece di ragionare sul problema  supportati da una profonda conoscenza
dei principi OO, senza applicarli beceramente ma "riconoscendoli".
Inoltre i metodi oggi usati aiutano poco, tipicamente sono troppo orientati alla
produzione di carta (diagrammni UML utilizzabili come carta da parati :-D), troppo
"meccanici" (fai questo, poi questo...). Alcuni poi, come il waterfall "classico", sono
clamorosamente errati :-) (per un articolo divertente su questo potete dare un'occhiata a
questo articolo: 
http://www.objectmentor.com/publications/IIDI.pdf
)


 Cosa ne pensate?
Il riuso c'e' sempre stato, chi programma in ambito GNU lo sa benissimo.
D'altronde, basta andare su 
sourceforge.org
 e fare click su "code snipplets":
quello e' "riuso" in senso puro, ovvero cut and paste di codice C... :-)
ciao ciao ciao
-- 
Marco Ermini
http://www.markoer.org
 - ICQ # 50825709
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.      -- Jeremy S. Anderson

nessuno programma veramente in maniera OO. 
Be', la domanda e' *La* domanda della s/e degli ultimi 15 anni, quindi
non e' propriamente semplice rispondere. :) 'nsomma, abbiamo convinto
mezzo mondo che OO e' buono bello, ma e' vero? :) Posto che tutti
sappiamo ormai che "OO allows, doesn't provide", e quindi e' difficile
fare un discorso generalizzato a OO e sensato (leggi, utile :) senza 
scendere nella pragmatica dei singoli casi (che include cose che vanno
da metodologia, approccio al design, linguaggi di programmazione,
linguaggi di modellazione, processi e loro gestione, eccetera 
fino alla locazione fisica delle persone che compongono il team, se ce
n'e' uno, alla loro esperienza, alle piattaforme in uso, etc); comunque,
a costo di dire cose non troppo sensate :), vediamo un po' i miei $0.10. 
Tieni anche presente che OO vuol dire un sacco di cose diverse. Il mio
approccio, per dire, e quello di un progettista OO dei primi '80 e'
parecchio differente - ma entrambi facciamo/facevamo OO. E usare Java
come linguaggio di implementazione e', concretamente, piuttosto diverso
da usare, per dire, Smalltalk o Obj.
Molto dipende, come hai detto, dalla definizione di riuso, e ce ne
sono varie, a loro volta, in dipendenza da a che livello ti poni.
Implementazione; c'e' riuso di codice: si faceva gia' con librerie,
vero - ma si fa pure con cut&paste, come ben sappiamo. In questo l'OO
promette (e in parte mantiene) *semplicemente* una maggiore facilita' di
riuso che non tecniche tradizionali; o, alternativamente, a parita' di
difficolta', il riuso di implementazioni (funzionalita') piu' complesse.
Il che e' vero: se hai mai usato le curses, per dire, ti accorgi di come
in effetti sia piu' semplice costruire implementazioni di UI a finestre
oggidi'; o come - restando a Java - sia piu' semplice costruire un
sistemino c/s con classi network-oriented che non con le (funzionalmente
equivalenti) socket BSD. 
Insomma, librerie OO, ben fatte (doesn't provide..), permettono di usare
meno tempo scrivere meno per realizzare le stesse cose; meno tempo
perche' si scrive meno codice; meno codice perche' si riusano
funzionalita' gia' implementate - visto che si realizzano le stesse cose.
Insieme ad opportuni ambienti di sviluppo il riuso c'e' ed e' molto
maggiore che non con librerie in senso standard, procedurali. Prova
ad usare string STL o char * in C++, per dire.
Allo stesso livello, c'e' riuso di algoritmi. In questo caso, l'impatto
OO e' abbastanza piccolo (per ragioni storiche, piu' che altro). La
generalizzazione di algoritmi tramite tecniche OO e' un'area interessante
ma poco reclamizzata e conosciuta. Se vuoi ci torniamo sopra - il sunto
e' che no, non c'e' imho grossa differenza ad oggi da questo punto di
vista. 
A design level, c'e' riuso, appunto, di pattern - set di ruoli,
responsabilita' e collaborazioni per garantire certe proprieta' ad un
risultato. Qui l'impatto e' (sempre nell'ottica del doesn't provide)
enorme. Non dimentichiamoci che oggidi' facciamo sistemi molto piu'
complessi di un tempo, con tempi simili e con ratio successo/fallimento
di progetti (ahime') simile. Ma guardare solo alla ratio senza 
considerare la complessita' dei fallimenti significa avere una visione
perlomeno parziale. Pattern, ovviamente, sia strutturali che
comportamentali. Ora, quanto di questo si traduca in codice e'
abbastanza irrilevante: il codice necessario per uno specifico caso
viene "prodotto" in modo estremamente piu' efficace e veloce, perche'
si riusa il design sottostante. In pratica, signfica che accade raramente
che sia la "prima volta" che si fa qualcosa - e questo e', se vuoi,
meta-riuso; ma l'impatto e' imho (lo vedo ogni giorno) decisamente
non trascurabile.
(volendo, molto di cio' puo' avere un riscontro formale in metriche,
griglie di valutazione e studi empirici in letteratura, ma evito per non
appesantire il discorso)
A questo livello appartengono anche le tecniche generative: ma siccome
vuoi un discorso "concreto", e sono piuttosto nuove e poco diffuse, 
le salto a pie' pari.
Process level, ed e' un punto spesso trascurato, c'e' riuso di *idee*.
L'approccio OO stesso, che tiene conto della specifica statica *e* della
specifica dinamica e' oggi (perlmeno tra chi si occupa di architettura)
scontato: ma non lo era affatto, ne' per "analisti" procedurali, ne' ai
tempi dell'affermazione commerciale dell'OO (leggi, anni '80 e
Smalltalk/C++). Come giustamente Bruno dice, e' tipico di progetti OO
"immaturi" (o progetti non OO) l'avere mezzo chilo di diagrammi di classi
e non un sequence nemmeno a pagarlo. Tutte le metodologie di questo
mondo, dalla piu' blindata DoD-style fino alla piu' leggera e
(apparentemente) anarchica sono inoltre esempi di riuso di processi. 
Che - certamente - non e' caratteristica di soli processi OO, ma a cui
l'approccio OO presta un vocabolario ed un'interpretazione "naturale" ed
immediata. In questo senso, tali "riusi", storicamente nati con l'OO,
(specie quello "leggero" non pesantemente basato sull'ereditarieta', ma
su composizione) hanno un effetto vantaggioso anche su approcci
storicamente precedenti; a nessun progettista (competente ;-) verrebbe
in mente oggi di limitare la specifica di un sistema al set di procedure
che espone, anche se e' realizzato e disegnato con tecniche puramente
procedurali. Cio' non era affatto ovvio, nei '70 e anche dopo.
Analisi e approccio ai problemi. Ancora, il riuso e' nelle idee -
l'approccio OO consente di astrarre dettagli che approcci precedenti,
semplicemente, incoraggiavano a lasciare; e *concretamente* erano
lasciati. Ancora, a livello pratico, cio' si traduce o nel riuso di
specifiche o nel maggiore potere di specifica a parita' di sforzo. Ogni
volta che affronto un caso con un analista del cliente, parlare in
termini di oggetti (spesso riusando, da parte mia, esempi, diagrammi e
spiegazioni che non devo inventare ogni volta) mi permette un'efficienza
di comunicazione semplicemente impensabile (per me, almeno ;-) se mi
dovessi limitare ad un approccio funzionale.
Ho lasciato fuori un aspetto, quello per cui OO sarebbe piu' "educativo"
rispetto all'approccio procedurale, suggerendo di piu' "la cosa giusta" 
- un tempo ci credevo abbastanza, oggi decisamente meno. :)
Infine, una nota, forse ovvia ma spesso trascurata. L'OO (o l'approccio
pincopallo) puo' "riusare" cose (dove per "riuso" si intenda "senza
modifiche" o quasi) solo finche' gli ambiti dove 'ste cose sono applicate
sono simili. Come dicevo scherzando qualche post fa, logiche di business
diverse *sono* diverse: non possono essere implementate senza far cose
diverse. Il riuso al 100% di implementazioni a quel livello e',
semplicemente, una chimera - a meno di avere l'approccio ERP/best
practices (ma quanto costa? Siamo sicuri sia una soluzione?). Si possono
rendere le cose piu' facili - ma le cose non saranno mai piu' facili del
minimo possibile. Che per logica di business e' probabilmente un "minimo"
non tanto piccolo. 
Questo e' l'equivoco solito - pensare che "il piu' piccolo possibile"
equivalga a "piccolo" :) 
Riusare un oggetto che incapsula una coda FIFO e' facile ed immediato.
Riusare un oggetto che incapsula una polizza assicurativa no, per il
semplice motivo che ogni dannata compagnia d'assicurazione :) considera
"polizza" una cosa diversa - spesso *molto* diversa. 
E in questi casi lo sforzo per adattare un'implementazione esistente 
semplicemente e' comparabile a quello di riscriverla. Cio' che si riusa,
nel caso, sono le idee di come scrivere un'implementazione, appunto,
riusi a livello superiore che non quello del codice.
I ragazzi del mio team sono spesso sorpresi quando glielo dico, ama
buttar via codice, a mio modo di vedere, non e' particolarmente un male:
talvolta e' l'unica cosa possibile *anche* se quel codice e buono,
a patto che si riusino le idee. Dopo un po', in genere, apprezzano -
almeno finche' il codice buttato via non e' il loro.. ;-)



Beh, diciamo che portare questi dubbi (qualche volta anche senza
risposte, perchè no?) di solito è il valore aggiunto che un docente
può dare in un'aula in un corso 'avanzato' sull'OO, ma comnunque
restano e sono mie posizioni personali. Nei corsi 'classici'
chiaramente la posizione è quella... classica.
ciao!
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services



Ci stanno lavorando, vedrai che belli!


non tanto piccolo. 
Questo è il punto: tu hai perfettamente ragione, ma la realtà è che
nei libri che si trovano in giro l'equivoco di cui parli sia passato
per approccio OO. Basta sfogliare la maggior parte dei libri, anche
blasonati, per rendersene conto. O anche qualche specifica... (a buon
intenditor)
Comunque, a questo proposito, mi piacerebbe sentire l'opinione di
persone che si occupano da relativamente poco di questo tipo di
problemi (non pochissimo! diciamo uno o due anni). Quella che mi
interessa è la percezione che ha la maggioranza dei softwaristi,
ovvero come convincerebbero qualcuno che l'approccio OO sia il
migliore e perchè.
Se volete, posso fare da 'avvocato del diavolo'....


intenditor)
Piuttosto vero, ahime'. Trascurando la semplice incompetenza :), imho 
ci sono due motivi - uno, il fatto che fino a tempi recenti l'OO
(e oggi, ad esempio, una certa piattaforma distribuita basata su Java
e RMI-IIOP ;-) si doveva "vendere". Oggi l'OO e', se mi passi il
termine, socialmente accettato nel mercato IT (anzi :), ma fino a poco, 
pochissimo tempo fa non era certo cosi'. Per tornare minimamente in topic, 
Java da questo punto di vista ha avuto un impatto notevole imho.
Stessa cosa accadde per Java, dove l'hype e gli "evangelizzatori"
abbondavano nei primi tempi, anche a costo di far passare l'idea
che Java e' "er mejo" e senza difetti (cosa ovviamente piuttosto
ridicola). Stessa cosa, piu' in ambito tecnico, accadde a suo 
tempo con C++. Ora le cose stanno tornando a proporzioni piu' 
ragionevoli - ma quel periodo c'e' stato. 
Secondo, il fatto che c'e' un notevole divario tra lo stato dell'arte
OO in accademia e mercato. Cioe', in ricerca si danno per scontate
tecniche e possibilita' che il mercato IT commerciale non vede nemmeno 
col canocchiale: prendi tutte le idee sull'analisi statica del codice,
che *potrebbero*, applicate su larga scala, migliorare enormemente
il riuso di logiche di business. Quindi se a scrivere un libro e'
qualcuno piu' in contatto con quell'ambiente che con quello
puramente commerciale, voila'.. :)


puramente commerciale, voila'.. :)
Bella tesi Crì! Ma vuoi troppo bene a questa gente....
conosco persone che scrivono questi libri e non credo siano in
contatto con qualsiasi cosa con cui non sia in contatto pure il resto
del pianeta (nie tempi di Internet, basta cercare le info per
trovarle...)
Vabbè dai, facciamo che per alcuni di loro in effetti 'riuso' sia una
parola pregna di significati esoterici che noi comuni mortali
commerciali ancora non conosciamo, ma sembra proprio che per gli altri
(e qui lista di nomi e cognomi :)) riuso sia effettivamente un modo di
riutilizzare codice nudo e crudo, e soprattutto attraverso
l'ereditarietà.
ciao


l'ereditarietà.
Io ti posso solo ripetere la mia opinione: di riuso ne faccio moltissimo,
ma molto di tale riuso e' concettuale - si manifesta nel fatto che si',
spesso riscrivo il codice, ma lo riscrivo meglio e (molto) piu' in
fretta. (e' anche uno dei motivi per cui continuo ad apprezzare e usare
UML: mi consente di trasferire tali concetti ad altri, e quindi non
limitare il riuso a me stesso :).
L'unico codice riusato direttamente e' quello di libreria, o widget
grafici. Il resto e' abbastanza utopico - almeno con lo stato attuale dei
tool. 
Per l'ereditarieta'.. prova a chiedere come si regola la gente per
decidere se dichiarare un membro di una classe private o protected... :-)


 
Una bella nota su protected che ho letto da qualche parte: 
"... una classe con membri protected o e' molto ben disegnata o e' molto
male disegnata: nessuna via di mezzo..."
ciao
-- 
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services
     /_____/ \/ / /          
    /_____/ /   \//\         SUN Microsystems Italia S.p.A.
    \_____\//\   / /         Via Romagnosi, 4
     \_____/ / /\ /          00196 - Rome (RM) - Italy
      \_____/ \\ \           @mail : 
ugo.l...@sun.com
       \_____\ \\            Phone : +39 (0)  6 36708.682


        \_____\/             GSM   : +39 (0)  335 7766651
|


 E non e' una provocazione :-D
Giustificazioni, pls. 
Quindi tu sei del partito public/private e basta? Secondo te non ci sono
motivi per assegnare visibilita' protected ad un metodo? Facci sapere.


 manager che dopo un giorno vuole già vedere "qualcosa di funzionante" e
Che comunque e' giusto: il 'cliente' deve partecipare piu' attivamente
nel processo ed avere delle stime valide, e non e' tenuto a 'capire' la
tecnologia od esserne innamorato come noi (anzi, e' molto meglio se non
lo e').
Come affrontate questi problemi? Si puo' dire al manager: ok, se lo vuoi
fatto veramente bene mi servono 6 mesi per farmi un framework, poi
cominciamo sul serio con l'applicazione xyz. Il vantaggio e' che la
prossima wxy la faremo in un mese. E' vera questa cosa? E se serve il
piu' possibile fatto entro 4 mesi cosa fate? e se wxy non si fara' mai?
E' il manager/cliente che non capisce la tecnologia o e' la tecnologia
che dovrebbe essere al servizio dei manager/cliente? (mi sento un po'
Marzullo...azz...)


 e se wxy non si fara' mai?
Uff... e questo è proprio il genere di osservazioni che fanno i capi... 
Non capisco perchè queste cose succedono soltanto nel nostro mestiere...
mio cognato fa il geometra e nessuno entra nel suo studio e dice "voglio
un condominio di dieci piani, ma deve essere assolutamente pronto entro
un mese", o, se lo fa, viene gentilmente accompagnato alla porta.
Lei, signor Marzullo, come la vede? :)
Ciao, Cris
-- 
Cristian Veronesi ><((((º> 
http://www.crpa.it
"The more constraints one imposes, the more one frees oneself
 of the chains that shackle the spirit."  (I. Stravinsky)

utili e riusabili?
... più sorgenti e meno parole.
Viva l'open-source!

A domande provocatorie non si può far altro che rispondere in modo provocatorio... 
... spero di aver dato il mio "costruttivo" contributo!

 un mese", o, se lo fa, viene gentilmente accompagnato alla porta.
Alt. Non confondiamo l'ingegneria con l'informatica ;)
Per un palazzo, un ponte o altro di solito il progetto e' chiaro e non
ci sono grosse sorprese. Il condominio di 10 piani e' quello e gia' si
sa quanto ci vorra' per costruirlo: se ti dicono che ci vogliono 6 mesi,
al sesto mese o e' finito o mancano pochi giorni, e cliente e
costruttore sono daccordo gia' da prima su tempi e costi (salvo casi
eccezionali, ovvio). Nell'informatica l'eccezione e' l'opposto: siamo in
tempo con il progetto e tutto va liscio. Il problema e' che per un
condominio non  succede che man mano che si costruisce si scopre che il
condominio volendo potrebbe pure fare da albergo, da ostello della
gioventu' e da palestra comunale, non si aggiungono o tolgono piani, non
si scoprono materiali migliori o si scopre che il cemento usato e'
adatto per reggere 10 piani ma non 11. Si sa tutto (tutto rispetto al
poco del software, intendiamoci) prima.
Quindi la domnada e': si puo' sapere tutto nel software prima? 
Se si:	caso poco probabile, forse sto semplicemente rivendendoti la
stessa applicazione fatta 6 mesi fa cambiando le stringhe! (e se non uso
Java con la Localizzazione diventa un boomerang pure questo...!)
Se no: ???


 Alt. Non confondiamo l'ingegneria con l'informatica ;)
Ehm, non per fare polemica ma... non sei tu che hai scritto questo? (gli
asterischi sono miei)
"Per anni il software è stato scritto senza l'appoggio di alcun
formalismo o di processi ben collaudati, ma è stato lasciato nelle mani
e nell'inventiva dei singoli programmatori. Questo approccio, antitetico
a qualsiasi *altro* ramo del'Ingegneria, ha prodotto danni
notevolissimi."
Ciao, Cris ;)


        \_____\/             GSM   : +39 (0)  335 7766651
|



Il problema sono i requisiti, ed il processo che noi utilizziamo per gestirne il
cambiamento, che e', purtroppo, inefficiente.
Che dite?
Ciao,
    Bruno.



ma che prendete sul serio quello che scrivo? ;)
yes... io leggo la stessa cosa, battuta a parte.
il fatto è che comunque ora ci si prova (ad avere delle regole, de i
formalismi, dei metodi, ecc.): molto meglio di prima quando si faceva
tutto a c..aso. Che ci si riesca come negli altri campi
dell'ingegneria, questo è un altro discorso. Che il termine Ingegneria
del Software sia pienamente giustificato, è un altro ancora. Forse
ancora non lo è, forse lo è. 
ciao!
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services
     /_____/ \/ / /          
    /_____/ /   \//\         SUN Microsystems Italia S.p.A.
    \_____\//\   / /         Via Romagnosi, 4
     \_____/ / /\ /          00196 - Rome (RM) - Italy
      \_____/ \\ \           @mail : 
ugo.l...@sun.com
       \_____\ \\            Phone : +39 (0)  6 xxxx.xxx


un mese", o, se lo fa, viene gentilmente accompagnato alla porta.
Questo perche' tuo cognato non ha concorrenti che lo dicono, e anche
se lo dicono i clienti non ci credono. Nell'informatica, invece, si'..
probabilmente perche' di un condominio tutti abbiamo esperienza,
di un sistema informatico no.


 salde in mano! I soldi sono i suoi!
D'accordo, ma riprendendo l'esempio di Ugo, se al cliente in corso
d'opera viene in mente che il condominio volendo potrebbe pure fare da
albergo, da ostello della gioventu' e da palestra comunale, rimane il
fatto che noi gli abbiamo fatto un preventivo per un condominio. Non so,
forse sono io che sono rimasto indietro, ma la letteratura dice(va) che
i costi delle modifiche aumentano vertiginosamente in proporzione allo
stadio di avenzamento del progetto, specie se queste modifiche vanno a
toccare strutture di base, come ad esempio il database. E questi costi
chi li paga? Pantalone? ;)



Okay, giustamente di riferisci alla curva di Boehm. Il problema nelle considerazioni
(correttissime, per carita') di Boehm sta nel fatto che e' mappata nei  processi di
sviluppo software in uso al tempo, ripresi e sviluppati dall'ingegneria tradizionale
(quella per costruire condomini, per intenderci :-D), come ad esempio l'arcinoto Waterfall
(Royce). Come si sa questo processo prevede quattro fasi distinte: analisi, design,
codifica, test, con le fasi che terminano a determinate date (milestones). Ovviamente,
usando un processo come questo, gestire un cambiamnento in fase di design e' molto +
difficile da fare che non in fase di analisi, e cosi' via. Ah, per una simpatica
trattazione del waterfall ti consiglio di leggere questo articolo dello zio Bob:
http://www.objectmentor.com/publications/IIDI.pdf
Provo a riprodurre qua sotto la curva, usa un font non proporzionale.
Costo    ^                   
         |                 Test
         |
         |
         |
         |
         |             Codifica
         |               
         |            
         |         Design   
         |        
         |  Analisi
         |
         -------------------------------->
 
Come vedi, gestire il costo di un cambiamento nella fase di test puo' arrivare a costare
parecchietto :-) Quindi, come si potrebbero correggere le cose? Beh, facendo in modo che
la curva si appiattisse. Questo pero' non e' attuabile con il waterfall, ed e' necessario
passare ad un processo che ce lo consenta. 
Il cliente deve avere un ruolo centrale in questo processo: deve poter controllare il
progetto, e deve anche essere a conoscenza dei costi delle singole feature o cambiamenti
che richiede. Il team di sviluppo , invece, deve rendere semplice al cliente decidere,
deve in pratica cercare di rendere piu' "malleabile" possibile il sistema software.
In pratica, le responsabilita' sono splittate. Il cliente:
- decide lo scope, ovvero cosa il sistema dovra' fare
- decide le priorita', ovvero quale feature e' + importante
Il team di invece :
- decide le stime delle singole feature
- informa il cliente delle conseguenze tecniche delle scelte
- decide il processo, cioe' come il team lavora.
Il cliente. insieme al team, decide:
- la composizione delle release
- la data delle release
Diciamo comunque che tipicamente il cliente decide una data di release, e quindi, in base
alle stime date dal team, alle priorita' delle features, ne decide la composiziomne.
Ovviamente il cliente puo poi, in ogni momento, cambiare idea e decidere che alcune
feature non servono piu' ma ne servono invece altre.
Questo riesce a funzionare... come? Semplicemente lavorando sul piccolo e sul semplice:
molte iterazioni piccole (di due settimane al massimo) che consegnano funzionalita', molte
release piccole (max 2 mesi) che mettono funzionalita' in produzione 
Comunque, se l'argomento ti interessa, ti consiglio l'iscrizione a questa lista di
discussione, che parla di XP, aka eXtreme Programming, un metodo che usa il processo di
cui ho parlato:
http://groups.yahoo.com/group/extremeprogramming-it
Oppure, per la letteratura, ti consiglio questo link:
http://www.extremeprogramming.org
Puoi anche dare un'occhiata 
http://www.xprogramming.com
http://www.xprogramming.org
http://c2.com/wiki?ExtremeProgrammingRoadmap
. 
http://www.xp123.com
