Newsgroup: it.comp.java
Titolo: E' nato prima il Database o l' Oggetto?

Scusate la "battuta", volevo un po' rifarmi al modo di dire "E' nato prima
l'uovo o la gallina?"
Volevo sottoporvi un quesito divertente che è stato oggetto di un acceso
dibattito ieri sera prima di ritornare a casa dall'ufficio.
Secondo me, una risposta corretta a un quesito come questo, è alla base di
una minimale conoscenza di object oriented.
Una tesi sostiene che l'applicazione debba nascere dalla definizione di un
database, e in secondo luogo si definiscono gli oggetti in funzione del
database.
Quindi si partirebbe dalla definizione del db, e poi si passerebbe al
programma.
Una tesi sostiene che l'applicazione debba nasce dalla definizione degli
oggetti, e in secondo luogo si definisce il database in funzione degli
oggetti.
Quindi si partirebbe dalla definizione degli oggetti, e poi si passerebbe
alla database.
Chiaramente non sto a dirvi come la penso, se no potrei influenzarvi...
A voi l'ardua sentenza.
Ciau.
--Jigi

Mi raccomando rispondete numerosi cosě potremmo risolvere con un
"referendum" questa accesa contesa :)

 wrote in
news:9u6djg$ln8$
1...@pegasus.tiscalinet.it
: 

Io penso che quando implementarono i primi db gerarchici gli oggetti erano 
ancora un'idea remota.
Teo

 ancora un'idea remota.
Hai risposto al subject, ma non alla domanda che ho fatto invece nel
messaggio. Ad ogni modo grazie.

 [cut]
Sembra un po' come quando chiedono ai cantanti se scrivono prima
il testo o la musica...
ad ogni modo personalmente mi verrebbe da dire che in fase di
progettazione le cose possono anche procedere in modo parallelo,
e comunque ho sempre trovato maggiori difficolta' a modificare
un database che non un'applicazione, quindi direi che il db andrebbe
progettato prima, ma in maniera tale rendere indolori eventuali
aggiunte e modifiche "future", modifiche richieste dall'applicazione.
Forse ho fatto un casino (sara' per l'orario), ma volevo dare
il mio (in)utile contributo.
Ciao.

 writes:
J> Una tesi sostiene che l'applicazione debba nascere dalla definizione di un
J> database, e in secondo luogo si definiscono gli oggetti in funzione del
J> database.
Cosi` e`  stato finora ed e` ancora  adesso. Tu hai dei  dati che devi
elaborare e  conservare, lo strumento per elaborarli  e conservarli e`
un  DB relazionale  quindi  pensi  al DB  e  poi all'applicazione  che
governera` le  elaborazioni. Se questa  e` fatta con un  linguaggio ad
oggetti pensi gli  oggetti. Questo perche' il DBMS  e` ottimizzato per
lavorare in  un certo  modo e  farlo lavorare in  un altro  fa perdere
prestazioni.
D'altro  canto ci  sono situazioni  in  cui il  DB deve  fare solo  da
repository in  cui l'efficenza  dell'accesso e` secondaria,  in questo
secondo caso  pensi prima  gli oggetti e  poi la struttura  che dovra`
contenerli.
D'altro canto esistono ora i DB ad oggetti e quindi il metodo potrebbe
divenire "individui  gli oggetti che  sono gestiti dal database  e gli
oggetti che sono gestiti dall'applicazione".
Ah,  sono profondamente  convinto che  non  ci debba  essere nulla  di
dogmatico ma le regole siano dettate dalle condizioni in cui si lavora
e da ragioni chiare e sensate. Chi va avanti seguendo dogmi aurei come
un talebano non ha la mia stima.
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

 il testo o la musica...
Non direi : secondo me la progettazione object oriented impone un approccio
ben preciso su questo argomento. Voi che ne dite?

Il problema è modellare gli oggetti su un database o modellare il database
su degli oggetti?
Continuo a credere che ci sia un approccio dogmatico e inconfutabile in OOP.

prestazioni.
Ho visto ora che hai dato una risposta precisa. Ottimo, finalmente.
Mi stai dicendo che si parte dal DB e poi si definiscono gli oggetti sulla
base del DB.
Ora, puoi indicarmi quali sono i formalismi e le pratiche di analisi da
seguire per fare l'analisi sul Database (ovvero partendo dal database per
poi definire gli oggetti) ? E quale metodologia (e quali testi) dovrei
leggere per trovare riscontro di ciň in OOP ?

 
http://mars.sal.disco.unimib.it/mailman/listinfo/java
-- 
| Andrea Trentini
| SoftArchiLab - DISCo - Universita' di Milano Bicocca
| mailto:
Andrea....@disco.unimib.it
| 
http://www.atrent.it
| wrk 
+39-02-6448.7856
 | fax 
+39-02-6448.7839

> prestazioni.
J> Ho visto ora che hai dato una risposta precisa. Ottimo, finalmente.
J> Mi stai dicendo che si parte dal DB e poi si definiscono gli oggetti sulla
J> base del DB.
E' uno degli approcci,  ne ho esposti 3. Si parte dal  DB quando il DB
relazionale e` vincolante.
J> Ora, puoi indicarmi quali sono i formalismi e le pratiche di analisi da
J> seguire per fare l'analisi sul Database (ovvero partendo dal database per
J> poi definire gli oggetti) ? E quale metodologia (e quali testi) dovrei
J> leggere per trovare riscontro di ciň in OOP ?
Ah, questa e` una domanda da $ 1.000.000. Testi non ne ho da suggerire
e probabilmente mi farebbero comodo.
Ammetto che mi fido molto del mio istinto programmatorio :).


 writes:
J> Il problema è modellare gli oggetti su un database o modellare il database
J> su degli oggetti?
J> Continuo a credere che ci sia un approccio dogmatico e inconfutabile in OOP.
Ripeto, non ci sono dogmi.  Avevo un geniale professore che era solito
ricordarci che  una cosa  e` il  mondo della lavagna,  una cosa  e` la
realta`. Approcciare sistematicamente tutto  seguendo un dogma fa fare
l'errore che  gia` anticamente i giapponesi  stigmatizzavano col detto
"Per l'uomo col  martello ogni problema e` un  chiodo".  Non esiste il
linguaggio universale  e non esiste la  soluzione universale. 
Dipende  tutto  da   quale  e`  il  problema  e   il  come  risolverlo
efficentemente  (se no tanto  valeva non  usare nemmeno  il computer).
Quale e` la  cosa che va trattata con piu`  efficenza e maggiormente ?
Beh, sara` quella  a guidare la scelta. Ho da fare  un uso pesante del
database con  query impegnative  ? Posso ridurre  il passaggio  per il
middleware  attraverso stored  procedure ?  Oppure il  database  e` un
repository di dati che processo principalmente in memoria ?
Con i  database ad  oggetti (o  con un layer  object oriented  come le
ultime  versioni di Oracle)  il problema  non si  pone, al  piu` sara`
interessante  vedere di  partizionare  la gestione  degli oggetti  tra
database ed applicativo. Ma pensi per oggetti sempre.
Invece  se  il database  e`  relazionale  ci  troviamo davanti  a  due
concezioni  differenti  nella  modellizzazione  dei  dati  che  devono
convivere. E  la concezione che verra`  usata di piu`  deve vincere se
vogliamo efficenza. Fluidamente, senza dogmi inamovibili.


 writes:
AT> Questo approccio ha pero' i suoi difetti:
AT> pensate a dover tenere in memoria tutti gli abbonati
AT> di un volume delle pagine gialle... :-)
Cavoli, hai buttato via almeno un decennio fatto per rendere efficente
l'elaborazione dei dati sul DB relazionale... :)


 l'elaborazione dei dati sul DB relazionale... :)
Volevo vedere se scatenavo un flame... :-)
Di solito ai corsi (UML => cobol/mainframisti) capita :-)))
BYE


 definizione degli oggetti, e poi si passerebbe alla database.
Quando si viene all'*uso*, non c'e' una risposta generale: dipende dalla 
situazione. Per un sistema nuovo, e' probabilmente una buona idea partire 
dalla progettazione OO e derivare lo schema migliore per persistere cio' che 
si vuole persistere, con un apposito layer di trasformazione se proprio 
necessario... questo perche', appunto, tutto quanto puoi "dire" con un 
database, lo puoi dire con un diagramma di classi. Con un occhio alle 
performance, pero', e si possono fare scelte di design a livello OO diverse 
da quelle "naturali" guidate dalla necessita' di eseguire persistenza in 
modo efficiente. L'essenziale e' farle a ragion veduta.
Per sistemi legacy.. la scelta diventa tra un mapping stretto tra database e 
struttura ad oggetti (spesso un cattiva idea per la qualita' del modello, ma 
una buona idea per le prestazioni) e la creazione di layer di adattamento 
(viceversa). 
Se poi usi un db object-oriented, e' un'altra cosa ancora.. ;-)
Nella pratica, al di la' di "cosa e' giusto fare", l'approccio "database 
driven", anche se tipicamente associato ad analisi e progettazione 
procedurali ('anni '70 e '80) non e' intrinsecamente peggiore - un E/R e' 
appunto (con i dovuti se e come) un tipo speciale di diagramma di classi,
senza supporto per generalizzazioni, ruoli/realizzazioni etc.
Il problema e' che spesso chi usa quell'approccio considera marginali gli 
aspetti dinamici (che invece sono essenziali per specificare un sistema) e 
centrali quelli funzionali (che nell'approccio OO, pur presenti, sono piu' 
in sottofondo); e che - essendo meno facile in E/R usare ed esprimere 
efficamente relazioni tipiche di un sistema OO, e' meno abiutato ad usarle 
ed esprimerle... e quindi il modello OO sovrastante ne risulta spesso 
condizionato, non facendo a sua volta uso di queste features che, ben 
adoperate, sono parecchio utili.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 adoperate, sono parecchio utili.
Ah ecco... :-)
Avevo cominciato a scrivere di botto... :-)))
Bye


 
Ehm, non hai letto bene, o io ho scritto male. Cio che "converge" sono
_diagrammi di classi_ e diagrammi E/R (nel senso che i diagrammi OO, nati
separatamente, si possono usare per gli stessi scopi), *non*
_modellazione OO_ e modellazione E/R. 


 _modellazione OO_ e modellazione E/R.
Ah, ok :-)
L'avevo capito (e lo davo per scontato),
volevo solo puntualizzare per chi e' all'ascolto...
C'e' anche il fatto che IMHO usare l'OOA&D per modellare db
e' un po' limitativo, serve infatti un grande sforzo
di mappatura sull'implementazione...
BYE


 
Come dicevo, e' per questo che di solito c'e' un layer di adattamento.
;-) 


Vi dico la mia:
Facciamo programmazione Object Oriented? Facciamo Analisi Object Oriented ?
Secondo me (e temo che la cosa sia oggettiva) si parte dal design degli
oggetti e si definisce la persistenza su tali oggetti.
Per chi fa analisi e design (come ha detto un collega illuminato) il
database non esiste (poi quì mi trovo in una realtà dove l'analista di
dominio fornisce addirittura le query al programmatore, e si preoccupa anche
dell'implementazione... non so se mi spiego...).
D'altronde non a caso in UML la struttura del database è un'aspetto molto
marginale, poiché in realtà nei class diagram viene definito in modo
implicito quali saranno i dati contenuti nel DB, e come vanno organizzati.
Se facciamo OOP/OOA dobbiamo partire dagli Oggetti, SEMPRE; la persistenza è
soltanto un aspetto degli oggetti. E soprattutto non è detto che sia la
persistenza sia su DB, quindi a maggior ragione non bisogna partire dal DB,
altrimenti facciamo programmazione orientata al database... e ci mettiamo
tutti a scrivere le stored procedures in pl-sql...
Cito da UML Distilled di M. Fowler:
Class models are comfortably similar to data models; many of the principles
that make for a good data model also make for a good class model. The major
problem in using class diagrams in using class diagrams is that it is easy
to develop a class model that is data oriented rather than being
responsibility oriented.
Questo è giusto una frase estratta da un libriccino, ma tale concetto è
ripreso allo stesso modo da qualunque testo di OOA/OOP.  Che conclusioni ne
traete?
Quindi si disegnano le classi per poi estrapolarne la struttura dati che
dovrà ospitarle E MAI VICEVERSA!
altrimenti non dobbiamo dichiarare che stiamo utilizzando un approccio
object oriented.
Quando il database è disegnato prima delle classi, stiamo avendo a che fare
con una STRUTTURA DATI LEGACY a cui stiamo ADATTANDO LA MODELLAZIONE del
software. Il che è ammissibile, poiché capita spesso che bisogna farlo, ma
non è object oriented.
Ora, trovatemi un testo focalizzato su OOA che dice il contrario e io da
domani vado a fare il pizzaiolo.
Mi aspettavo risposte migliori da un gruppo di discussione su Java... Come
mai?
Scusate la stizza, poi mi passa :) in fondo vi voglio bene.
Jigi

 adoperate, sono parecchio utili.
Una trattazione preparatissima, ed hai anche allargato i miei orizzonti :)
Magnifico!
-Luigi

 Jigi
Jigi, l'approccio classico secondo il paradigma OO e' quello di partire
dagli oggetti e passare poi alla persistenza, ma e' una cosa abbastanza
ovvia... probabilmente ti e' stato risposto a qualcosa di piu' di quello
che avevi chiesto. Perche' invece non ci racconti un caso reale in cui
hai approcciato un problema applicando i canoni OO (ricordati prima di
definire quali tu ritieni siano questi canoni) e come ti sei trovato?
facce sape'...
uL

 l'uovo o la gallina?"
secondo me sei in un vicolo cieco :-))

definire quali tu ritieni siano questi canoni) e come ti sei trovato?
Il mio mestiere è scrivere applicazioni java per il web ed ove possibile
cerco sempre di scrivere software riutilizzabile o facile da estendere, da
utilizzare , sia per chi lo usa come utente, sia per chi ne sfrutta servizi
come programmatore client. Per il momento, non ho raccolto troppe critiche
sul lavoro svolto.
Le critiche, come quella di cui parlavo (database/oggetti) all'inizio di
questo post è stata sollevata da un programmatore con un paio di mesi di
esperienza, una laurea in informatica e nessuna applicazione alle spalle;
abbastanza però da mettermi la pulce nell'orecchio e postare il messaggio su
ng per vedere se però qualcuno potesse darmi una motivazione logica e
sensata che questo tizio comunque non avrebbe mai potuto darmi. Beh, non
l'ho vista (dici che me la son persa o non l'ho afferrata?).
Comunque, come mi son trovato: spesso il mio codice e le strategie adottate
son diventate esempio per applicazioni di altri colleghi; applicazioni che
funzionano, e realizzate a volte con meccanismi più semplici di quelli
utilizzati comunemente (se verrà pubblicato, ti spedirò il link ad un
articolo in preparazione circa il meccanismo di gestione della validazione
dei dati in applicazioni web, e poi mi dirai cosa ne pensi). Un'altro
riconoscimento dovuto probabilmente al fatto che le applicazioni che scrivo
funzionano, sta nel fatto che sto facendo da technical reviewer per un libro
che verrà pubblicato a metà dell'anno prossimo (per ragioni evidenti non
posso dirti solo che si tratta di un'esplorazione dettagliata di un IDE
molto popolare, ma non posso citare né titolo ne argomenti).
Tuttosommato il modo con cui io ho applicato quello che io credo sia OOP non
è stato né disprezzato né fallimentare.
Piuttosto, oltre che dirmi che la risposta è banale, non mi hai detto quel
che ne pensi tu, e la tua opinione sarebbe la benvenuta.
rgds,
Jigi.

Ad ogni modo, il thread cominciato da C. Sadun è l'unico che ho trovato
interessante e l'ho anche detto con un certo apprezzamento.
Tu cosa ne pensi?

 su degli oggetti?
dipende dal dominio del problema

 Di solito ai corsi (UML => cobol/mainframisti) capita :-)))
Io il flame l'ho scatenato con un sedicente C++ista, che ancora mi fa le
paranoie sulla lentezza di java e le virtù dei linguaggi low-level, tanto
che ormai gli dò ragione a priori qualsiasi cosa dica (è il mio vicino di
scrivania), a volte con malcelata insofferenza. Ad ogni modo sono daccordo
che disegnare il db per poi "adattarci su" gli oggetti sia il tipico
approccio da cobol/mainframista. Lungi dall'intenzione di dire che questo
sia un approccio che non funziona, ma sono certo nell'asserire che non sia
l'attegiamento da utilizzare sviluppando con Java.

 dipende dal dominio del problema
Quì il dominio ci fornisce anche il database bell' e pronto , e dice pure le
query che ci devi fare su. Uno schema ERWin è quello che quì dove sono viene
definito "analisi"... Il guaio è constatare che taluni specialisti di
dominio hanno uno strano concetto delle relazioni, ma d'altronde sarei
felice se uno specialista di dominio non fosse al corrente dell'esistenza
dei database sulla faccia della terra.
Il database, secondo me è un aspetto implementativo, non di dominio (a meno
che tu non stia progettando un database relazionale).

> >> Cosi` e`  stato finora
Si è sempre "detto così", si è sempre "fatto così", quindi "è giusto così" ?
Ad ogni modo, finora è stato il regno della programmazione procedurale.

 che tu non stia progettando un database relazionale).
non e' sempre cosi'; se ti e' richiesto nella specifica dei requisiti che i
dati devono
essere ricordati allora e' chiaro che nell'analisi del sistema si dovranno
indicare quali
dati devono essere ricordati poiche' ti e' espressamente richiesto dal
dominio del
problema... ma questo non ha niente a che vedere con il progetto del DB
poiche'
e' poi nella fase di progetto che si decide come "implementare" le decisioni
prese
in fase di analisi... il fatto che tu veda il DB come un aspetto di
implementazione e'
forse dovuto al fatto che tu pensi alla parola DB come la vede un
progettista mentre
io la vedo dal punto di vista dell'analista :-))

 che ne pensi tu, e la tua opinione sarebbe la benvenuta.
Io penso che il 'paradigm shift', o 'paradigm crossing', che c'e' nel
passare da oggetti a tabelle (e viceversa) renda il discorso delicato.
Gli stessi EJB (piu' o meno la risposta ufficiale Sun) possono portare
talvolta a complessita' inutili, proprio perche' cercano di affrontare
un problema *difficile* come quello di far persistere degli oggetti in
un DB relazionale  e renderli transazionali. Talvolta questo approccio
puo' portare a complessita' inutili ed irrigidire inutilmente un design.
Piu' o meno "rispondere a complessita' con complessita'".
Io credo che l'insieme di variabili ed il bilanciamento necessario fra
di esse rendano ogni risposta 'generalizzata' impossibile. Un po' come
fare un framework che vada bene per qualsiasi applicazione...
ciao
uL

design' OO? Comunque secondo me Cristiano ti ha risposto.
Non sono pratico dei newsgroup. Giusto un mese che ho cominciato anche se
sui forum in internet mi son dato parecchio da fare, quì sui ng devo ancora
imparare.
Grazie mille
-Jigi


Ri-Wow!
Ugo, ti stai finalmente convertendo! :-D
Mi sentirei quasi di dire che spesso EJB == possibile lancio da 3 :-D
Ragazzi, sante parole! Evitate la complessita, cercate innanzitutto le soluzioni,
semplici, e partite sempre dai casi d'uso dell'utente, da quello che da' valore al cliente
e non da cio' che rende la vita semplice a voi, ai sistemisti o ai DBA. E' il *cliente*
che vi paga, i soldi sono suoi e ha diritto di scegliere la soluzione piu' adatta ai suoi
problemni al di la' della tecnica che verrà utilizzata.
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|


Sono potenzialmente sbagliate tutte e due :-D 
Un'applicazione nasce da una serie di richieste del cliente che ne specifica, di solito in
modo molto informale, un insieme di storie in cui ne descrive l'uso. E' sicuramente
possibile che per il cliente sia strategico l'interfacciamento con un database
preesistente, nel qual caso esso diverra' una parte importante del sistema, ma questo e'
tutto.
Certamente, una volta formalizzati (se volete farlo) i casi d'uso, e' difficile che si
parta dal database nella progettazione di un sistema OO, anche nel caso in cui il database
sia particolarmente strategico. In quel caso ci sara' un bel pezzo del sistema che si
occupa dell'interfacciamento con il database, ma tutto li. In un sistema le dinamiche di
interazione fra componenti (oggetti) sono molto piu' importanti delle relazioni statiche
fra di essi, ed e' per questo che di norma non si parte dal DB, che introduce solamente
una fortissima rigidità.
Attenzione, pero', che gli oggetti non possono venire modellati tutti in anticipo, con una
bella fase di design, in cui voi (come gli analisti del DB) prevediamo "tutto* quello che
ci servira' nel sistema: probabilmente vi conviene affrontare un caso d'uso alla volta
(c'e' chi direbbe anche meno: io, ad esempio, quando uso XP :-D) e a poco a poco vedrete
che la struttura ad oggetti del vostro sistema emergera' spontaneamente, e piano piano si
evolverà fino a rappresentare tutto il vostro sistema.
E' importante evitare le trappole della rigidità, della fragilita, dell'immobilita'. In
ogni momento deve essere possibile intervenire sul sistema e modificare od aggiungere
funzionalità senza che questo sconvolga il sistema stesso, e ad un costo molto basso.
Se, per esempio, cambiare una foreign key sul database non mi fa funzionare piu' un pezzo
di GUI, beh, state sbagliando *parecchio*. Il vostro sistema e' fortemente accoppiato, ed
e' difficile da modificare: il vostro costo del cambiamento e' molto alto. 
Voi dovete invece lavorare tenendo sempre basso il costo del cambiamento, senza pero'
introdurre delle artificiosita o design troppo complessi ma semplicemento cercando di
mantenere le cose semplici ed evitando, sempre, l'accoppiamento. Il fatto che come sistema
di persistenza il vostro sistema usi un database, o un insieme di file, o un host, deve
esservi completamente indifferente. E attenzione, lo stesso vale per la GUI: il fatto che
il vostro sistema sia basato su pagine HTML, applet o applicazioni, terminali WAP, deve
esservi completamente indifferente. E questi sono solo macro-esempi, in cui eovete cercare
di evitare l'accoppiamento fra le componenti, ma voi questo dovreste farlo con ogni
singolo oggetto, valutando attentamente di volta in volta a chi assegnare una
responsabilita': e non sto parlando di macro-responsabilita' come fornire una interfaccia
utente o un sistema di persistenza, ma di qualsiasi funzione che deve essere espressa dal
sistema.



Sbagliano parecchio :-)
Un'analisi e' un'altra cosa, spiega *cosa* fa il sistema, non dove vanno a finire i dati
una volta che vi sono stati inseriti.


 quali testi) dovrei J> leggere per trovare riscontro di ci• in OOP ?
Nel volume su OMT (Object Modelling Technique, una delle
tecniche/notazioni poi fuse in UML e metodologie correlate) di Rambaugh,
trovi - se non ricordo male - un capitolo esplicitamente su questi
aspetti (il rapporto tra analisi "tradizionale", funzionale e
database-oriented, e object-oriented). 
C'e' anche da notare che c'e' modo e modo di eseguire analisi
tradizionale, funzionale (ovvero, ad esempio, eseguirla o no ;-). 
Metodologie "classiche" (SDSA, Jackson, etc) possono, in dominii
tradizionali, essere altrettanto efficaci di approcci OO: e' solo con
l'aumentare della complessita' che OO/CO e evoluzioni diventano, in
genere, piu' efficaci. E anche loro oggidi' cominciano a mostrare i
propri limiti, dato che l'appetito vien mangiando e col software si
vogliono fare cose sempre piu' complesse.. ed eccoti estensioni ed
evoluzioni di OO come AOP. 


 imparare.
E allora, visto che siamo in tema, leggiti pure questo: poi saprai tutto il
poco che c'e' da sapere sui ng.
http://www.albion.com/netiquette/
(ce n'e' una versione in italiano da qualche parte, ma non mi ricordo dove.
Cristiano, se mi ascolti ;), perche' non mettiamo nelle FAQ anche questi due
indirizzi?)
ciao e buon lavoro
uL
-- 
Posted from 
hebrides.eu.sun.com
 [192.18.240.6] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

> Un'analisi e' un'altra cosa, spiega *cosa* fa il sistema, non dove vanno a
finire i >dati una volta che vi sono stati inseriti.
Sono molto daccordo.

 
A cosa? ;)
Sono nato convertito... (citazione dal mitico Snake Pliskeen, "1997 fuga da
NY")


 un DB relazionale  e renderli transazionali. 
Imho, la complessita' degli EJB e' inutile se... non serve. :-)
A parte gli scherzi, intendo dire che EJB, come altre tecniche simili,
nasce per risolvere *uno* specifico problema (massimo due, ;-) tralascio
appunto la persistenza), che e' appunto quello di "garantire
transazionalita' (che brutto :-) a oggetti". 
Cio' e', ..semplicemente, :-) una cosa complessa, e di solito difficile
da implementare in codice per un programmatore medio. 
Un tipo di difficolta', per certi versi, simile a quello della
programmazione concorrente: per programmare direttamente verso un sistema
transazionale (ad esempio, Tuxedo o simili), bisogna aver ben chiaro in
mente il modello di riferimento, sapere come e' implementato dal sistema
transazionale sottostante, e sapere esattamente cosa si vuole fare e cosa
si sta facendo.... e _anche_ in quel caso e' molto facile commettere
errori. 
Ora, e' chiaro che se ad uno specifico sistema della transazionalita' non
gliene frega nulla (ad esempio, un sistema in cui la concorrenza e' molto
bassa, o puo' essere risolta da tecniche di locking o attempt/fail/retry
senza grosso impatto sulle prestazioni medie) - portarsi dietro tutto
l'ambaradan di EJB e' una cattiva idea. 
Inoltre, il problema e' cosi' complesso che con EJB (o altri) si possono
dichiarare solo *alcuni* tipi di proprieta' transazionali - quelle per
cui EJB e' concepito: quindi, se ne servono altre, EJB e' ancora una
cattiva idea. :-) 
Nel caso, invece, in cui serva comportamento transazionale, e il tipo di
comportamento transazionale dichiarabile in EJB sia proprio quello che
serve, EJB semplifica il lavoro di un bel po', ed e' una buona idea. 
'nsomma, avere una soluzione pronta per un certo tipo di istanze di un
problema difficile sposta la difficolta' verso il valutare se l'istanza
da risolvere e' del tipo risolto dalla soluzione. Che e' dove mi aspetto
dolori da EJB.. ;-) 


 
A questo proposito racconto spesso un aneddoto. Il primo giorno di lavoro
nell'azienda in cui sono attualmente ho apprezzato molto l'esistenza di un tool
da riga di comando per trovare i numeri di cellulare e/o interni dei dipendenti
(che sono sparsi geograficamente) e viceversa (da telefono a nome).
Subito, (deformazione personale), ho cominciato a pensare a come era fatto e a
come invece l'avrei fatto io.
Dopo pochi minuti, avevo gia' un'architettura fantastica con DB XML, java,
socket e chi piu' ne ha piu' ne metta.
Premessa: non sono mai stato un grande sistemista, e' una cosa che odio. E' da
relativamente poco che non sono piu' un newbie in materia (metto le mani
avanti... :))
Mentre pensavo se introdurre un'interfaccia web con framework di comunicazione
applet-servlet (il mio, non quello di Bossola!) nella mia ipotetica
architettura, valutando i possibili problemi di scalabilita' ma soprattutto
apprezzando cosa sarebbe stato possibile fare con questa soluzione (es:
conversione in pdf tramite XSLT per distribuire elenchi cartacei, ecc.) ho
scoperto come era invece fatto il tool andando a fare "reverse engineering":
grep! un banale, bastardissimo grep su un file ASCII... capito? due, diconsi 2
(DUE!) righe di "codice", che qualsiasi sitemista scrive in un tempo oscillante
fra uno o due nanosecondi.
Altro che reverse engineering... eppure piu' che sufficiente per le esigenze
interne, quindi... va bene cosi'.
Mi e' stato di lezione... "think big, but keep it simple". Ed introdurre le
complessita' solo quando danno valore al cliente (non al tecnico!). Altrimenti
che se ne stiano sugli scaffali.
ciao a tutti


 sia particolarmente strategico.
Le trovo un po' in contrasto queste due affermazioni.
Io continuo ad essere convinto che anche che a monte di una DDL ci sia
sempre la volontà di contenere degli oggetti , quindi tanto vale fare una
buona analisi OO prima di scrivere un db che dovremo poi modificare 40
volte. E per quanto un sistema può essere disaccoppiato da tutto, non ho
ancora visto un applicativo in cui spostare qualche campo o fk non involva
in qualche colorita maledizione, magari nel codice :) .
Anche in un posto dove sono stato asserivano di usare XP che per quel poco
che conosco la trovo ottima, ma l' "implementazione" è stata a dir poco
discutibile, dato che son scappati via tutti i programmatori (scambiati con
consulenti esterni), i risultati sono stati miseri, e adesso ho sentito che
si fanno le 4 di notte in ufficio un giorno sì e l'altro pure. Con questo,
niente da dire con XP che anzi mi piacerebbe provare davvero.
Bruno, hai seguito il seminario di XP alla Java Conference di quest'anno?
Impressioni?
-Luigi

 
tutto molto poco XP, anche se secondo me non per colpa del relatore.
ciao


 wrote in message
news:9u97a9$4tj$1...@pegasus.tiscalinet.it...


 fra uno o due nanosecondi.
Fantastico :)

Mi e' stato di lezione... "think big, but keep it simple".
Fico! Ora lo memorizzo e ne abuso!
Invece ecco una citazione fresca, che pero' non e' mia, che ho letto stamattina:
"In un era di ipercomunicazione, dire di meno significa dire di piu'".
[Neil Gerhenfeld, se mi ricordo bene]



No, non l'ho seguito, ma mi hanno detto che il relatore non era molto competente,
quindi... se vuoi approcciare XP, ti consiglio di affidarti alla documentazione ufficiale
o ad un mentor.



Bello! 


 o ad un mentor.
Sono autodidatta in queste cose.
Ho letto un po' di articoletti in giro e ho avuto un'esperienza di rup/xp
che mi ha dato una qualche infarinatura  - proprio con il relatore XP della
JC2001, con cui seppure non ho avuto un rapporto serenissimo conservo molto
rispetto inquanto è un ottimo tecnico.
Quando avrò tempo però studierò la cosa pragmaticamente su qualche testo,
adesso ho altre priorità. L'argomento è molto interessante comunque.
Ciao
-L


Scusa, non volevo essere in alcun modo offensivo, mi riferivo alla competenza in XP,
quello cioe' su cui lui relazionava. Poi probabilmente, anzi sicuramente, e' un ottimo
tecnico, che pero' non conosce troppo bene XP.
XP bisogna usarla, tutte e 12 le pratiche, e prima di queste bisogna sapere
*perfettamente* l'Object Oriented, e *perfettamente* principi e strumenti di design. (DIP,
OCP, LSP, DesingByContract, Use cases, Pattern di design, ecc.ecc.). Non e' facile, di
nuovo, ci vuole tanto studio ed aiuto.
Ciao,
    Bruno,


 rispetto inquanto è un ottimo tecnico.
Allora ci avevo azzeccato (sul lavoro, intendo)
Comunque, semplicemente credo che non avesse un approccio ortodosso ad XP, nel
senso che probabilmente prima di "personalizzarla" bisognerebbe farne
l'esperienza "totale".
Perche', come si dice, le pratiche XP hanno delle sinergie che vanno
sperimentate e che posso stupire.
Solo in iterazioni successive e quando si conosce meglio il team ed il problema
il processo puo' e deve essere personalizzato. Non prima!
Quando non ti importa piu' se stai facendo XP o meno, sei nella fase finale di
maturita'  XP.
Per il resto, sono d'accordo con te:  a parte l'esperienza XP, e'  molto ma
molto competente


 [Neil Gerhenfeld, se mi ricordo bene]
praticamente una nuova versione di "il silenzio vale piu' di mille
parole".... 


Concordo pienamente...queste discussioni sono veramente appasionanti per
newbie come me!!
Ciao
Daniele

Beh, ho cercato anche di dare un "messaggio in codice" in un altro thread.
Non so se ci son riuscito.
Avevo capito che avevi capito :)
Ciao
Luigi

> Scusa, non volevo essere in alcun modo offensivo, mi riferivo alla
competenza in XP,
Figurati :)!

 Pattern di design, ecc.ecc.). 
Che e' sempre il vero problema. Imho, se *sai perfettamente* tutte 'ste
cose , riesci a fare un progetto di successo pure scrivendo in sanscrito
e avendo come metodologia il ricettario di mia nonna. :-) 
Vabbe' forse esagero. ;-)


 e avendo come metodologia il ricettario di mia nonna. :-)
Parole sante, il problema è che "nessuno nasce imparato" ;-) come dicono al
mio paese

Ti svelo un segreto... siamo tutti newbie, semplicemente ci inventiamo
parole e poi facciamo finta di conoscerle. Shhhhh ;-P

Bellissimo thread!
Anche se forse dovrebbe stare su software-eng :-)))
Scherzo, e' ottimo anche qui...
Bye
-- 
| Andrea Trentini
| SoftArchiLab - DISCo - Universita' di Milano Bicocca
| mailto:
Andrea....@disco.unimib.it
| 
http://wwX-Mozilla-Status
: 0009-02-6448.7856 | fax 
+39-02-6448.7839

 newbie come me!!
Lo sono credo per tutti :)

Sai cosa mi dispiace veramente tanto? Io veramente di queste cose ci capisco
praticamente niente, però dall'anno prossimo all'Università studierò
Informatica, ed è più che probabile che ciò diventerà il mio pane
quotidiano...e non posso stare a salvare questa valanga di messaggi sul mio
computer (è anche vero che ho spazio a volontà, ma se lo dovessi fare per
tutte le cose che mi interessano?!? ;-))
sigh...
Ciao by
Daniele

 quotidiano...
Temo che ti attenda una delusione (x me è stato così)

NON DIRMI COSI'!!!!!!!!ARGHHHHHH:-(((((((
E allora come hai fatto a imparare tutte quste cose? Sempre grazie
all'esperienza, ai newsgroup e cose del genere? Spero quindi di essere
sempre di essere sulla stada giusta:
Programmatore Daniele=new Programmatore(Passione p, Laurea l);
Ciao by
Daniele.
P.S.: Credi esista anche il costruttore
Programmatore Daniele=new Programmatore(Passione p);?
Semplificherebbe la vita!!

Nel lavoro troverai ottimi tecnici che non per forza sono laureati.
Ti racconto qualcosa di me: ho frequenticchiato 1 anno di università e
un'altra metà (2°), dando 4 esami.  Poi ho lasciato perdere e ho cominciato
a lavorare.
Sfiga vuole che sono sempre rimasto impelagato con architetture legacy
(cobol mvs, rpg, vms e chi più ne ha... pensa che mi son venduto l'anima per
andare a programmare in VB...). Ora le ho tolte pure dal cv (nonostante
occupino più della metà della mia esperienza "on the road"), xché se no
continuano ancora adesso a chiedermi di sta roba, che non mi interessa.  E'
una questione di scelta.
Finché un giorno mi hanno proposto Java, e ho accettato al volo : era quello
che desideravo; son dovuto andare a Biella, via dai miei a 23 anni, e
accettare di ritornare junior, con conseguente riduzione di stipendio e con
un contratto di formazione a tempo determinato di 2.000.000 per 13
mensilità, più premio che non ho mai visto (siccome quel progetto è ancora
da consegnare...)
Ho studiato tanto per conto mio, tra l'altro facevo le 3 di notte in ufficio
gli ultimi tempi... eravamo nelle canne e mi son preso i caziatoni più
grossi della mia vita per i ritardi sulle consegne, essendo nel frattempo
anche stato promosso a team leader dopo i primi mesi (ma senz'aumento
naturalmente) ho goduto degli oneri, ma solo di quelli.
Quando mi son rotto di questa situazione, e di essere esaurito, ho pensato
che era tempo di tornarmene a Torino; e a quanto pare ho fatto bene, perché
ho sentito che lì ancora si stanno scannando senza risultati.
Io son cresciuto a calci nei ... ti lascio immaginare. Ma la passione x
l'informatica mi è nata probabilmente in seconda elementare quando in tv
c'erano "i ragazzi del computer" e quando cominciavo ad appassionarmi alla
fantascienza, e mi son fatto regalare dai miei la console "Atari 2600". Non
ti dico quante ore ho passato lì davanti. Poi ci sono stati i "computer",
una lista di aggeggi a vapore :) che non sto ad elencarti e che per
meritarmi dovevo fare i salti mortali a scuola e far contento il babbo.
Per crescere ci vuole solo passione e la pazienza di studiare (sui testi in
inglese mi raccomando). E purtroppo, la mia esperienza dice, che per fare il
lavoro che ti piace devi anche saper rinunciare ai soldi, sebbene ora sto
recuperando l'investimento in formazione che ho fatto.
Ogniuno ha la sua storia, ma di sicuro se trovi uno che sa il fatto suo
nell'informatica, è perché è nato con la passione (o è stato folgorato sulla
via di Damasco). E' come essere innamorato (visto "the matrix"?) Questa è la
costante.
boys... scusate tanto per la storia commovente :) e off topic di sicuro.
Ogniuno penso che però abbia la sua. Ma la costante penso sia la stessa.
Ciao
Luigi

Programmatore Daniele=new Programmatore(Passione p);?
Sono convinto di sě, ma potrebbe essere deprecato.
Consigliare di smettere di studiare č *sempre* un pessimo consiglio.
Personalmente finora non rinnego la scelta che ho fatto, ma un giorno potrei
rimpiangerla.

OK...vedrò di studiare a fondo, ma sopratutto di mettere la passione che
provo per i computer.
Certo che ho visto Matrix! Gran film (a proposito per me l'hanno programmato
in Java...)
Scusate a tutti per l'argomento OT...spero mi potrete comprendere!
Ciao by
Daniele
P.S.: a  proposito di testi in inglese, me ne potresti citare qualcuno? Al
momento l'unico testo di java che ho è Java 2 e oltre di jamie Jameworski
(inoltre mi sono scaricato Thinking in Java, ma "devo ancora
aprirlo")...Grazie!!! A proposito, gran risposta "deprecato"!!

 passione != laurea ...
L'universita' e' un'opportunita'. Non necessariamente l'unica e
probabilmente non la migliore, ma non ce ne sono molte altre in cui i
fondamenti concettuali (chiamarli "teorici" li fa sembrare troppo
astratti ;-) della computer science sono *cosi'* a portata di mano. 
Come tutte le opportunita' richiede uno sforzo personale per essere
colta.. e "a portata di mano" non significa necessariamente "semplice da
raccogliere": il poco talento italiano per l'organizzazione efficiente,
il numero fisiologico di scaldacattedre (che corrisponde all'incirca a
quello di scaldabanchi ;-), la scarsa abitudine all'uso della propria
testa fornita dalla scuola superiore, e le radici piu' orientate alla
ricerca che all'insegamento rendono le cose abbastanza complicate. 
Tuttavia, non ci sono molte altre occasioni in cui si puo' imparare cosi'
tanto in cosi' poco tempo. 
Parte di tale sforzo e' 


 Parte di tale sforzo e' 
Dimentica questa parte. :-)


Tutto verissmo. Di certo l'università può darti l'impulso migliore ai più
grandi slanci tecnologici.
Non a caso Unix è nato nelle università... E nelle università internet è
diventato di dominio "civile" (inteso come non-militare) e si potrebbe
andare avanti per parecchio...
Ma questo te lo devi cercare, e con insistenza. Devi avere la fortuna (o
l'abilità) di incontrare il professore giusto e di risultare simpatico alle
persone giuste :) che abbiano voglia di accettarti nel "convivio" . Per
quanto ho constatato, esistono congreghe di ricercatori un po' schivi su
quest'aspetto, come probabilmente però ce ne sono altre molto più aperte e
liberali.
rgds
-Jigi

 Parte di tale sforzo e'
Non ti preoccupare, l'Università non me la lascio scappare...non ha paura di
studiare, anzi!A me non interessa un "semplice" (per non offendere nessuno,
sia ben inteso!;-)) pezzo di carta... a me quello che preme è imparare a
programmare bene, il meglio che posso raggiungere...solo che speravo che
l'Università fosse un mondo diverso dalla scuola secondaria...e invece sono
simili (scaldacattedre, scaldabanchi...ho un ottimo professore
d'informatica, il migliore della scuola, ma secondo te quanti dei miei
compagni sono veramente interessati?...).Sigh :-(((
Ciao by
Daniele

tanto in cosi' poco tempo. 
Perfettamente d'accordo. La chiave è IMHO l'espressione "si può".
-- 
Ciao
	Fabrizio C.

l'ho vista (dici che me la son persa o non l'ho afferrata?).
E spezziamola allora questa lancia in favore del neossunto ...
Un motivo per iniziare a sviluppare un'applicazione pensando alla
struttura piu' adatta a memorizzare le informazioni sulle quale essa
si appoggia piuttosto che all'esigenza contingente che ne ha richiesto
lo sviluppo, mi pare abbastanza evidente: se ci fai caso, nella storia
dello sviluppo di un sistema informatico, le applicazioni possono
essere modificate spesso, avere un utilizzo limitato nel tempo,
nascere e morire numerose; la conoscenza racchiusa in un sistema
informativo invece si evolve in genere lentamente, e rappresenta anzi,
il vero patrimonio di una azienda.
Credo quindi si possa dire con tutta tranquillita' che nella
realizzazione delle applicazioni che servono all'utente, sia spesso
fondamentale avere un occhio di riguardo all'integrazione di
quest'ultima nella struttura del sistema informativo aziendale,
sistema informativo *gia'* presente, a prescindere dall'esistenza o
meno di un sistema informatico, e quindi un occhio di riguardo alla
modellazione dello schema dei dati sottostanti, che dovra' essere in
qualche misura congruente con tale sistema informativo, pena la
necessita' di dover buttare a mare tutto il lavoro non appena le
esigenze del cliente determino una variazione delle esigenze
applicative. Questo, noto fra l'altro, e' stato proprio uno dei motivi
della nascita dei sistemi per la gestione delle basi di dati, dato che
spesso, nel passato, proprio perche' non si teneva conto dell'esigenza
di integrazione con il sistema informativo, si finiva con il
sviluppare applicazioni *indipendentemente*, con propri archivi, anche
se facevano uso di dati che rappresentavano completamente, o in parte,
le stesse informazioni.
Se infatti vai vedere la definizione di base di dati "Una base di dati
e' un insieme di dati strutturati e permanenti, raggruppati in insiemi
omogenei in relazione fra loro, organizzati con la minima ridondanza
per essere usati da applicazioni *diverse* in modo controllato",
noterai come la definizione pone l'accento proprio sull'uso
*molteplice* dei dati, dati quindi che non possono essere modellati
solo in base alle contingenti esigenze di una specifica applicazione
che si sta sviluppando, ma devono tenere conto in qualche modo della
loro integrazione e congruenza con il resto del sistema informativo.
A cosa serve infatti adottare le piu' avanzate tecniche OO se poi ti
dimentichi che la meravigliosa applicazione che hai sviluppato, non
deve servire a far vedere quando bravo sei, bensi' piuttosto a
contribuire all'aumento del patrimonio di conoscenze aziendali,
memorizzate e organizzate per lo piu, attraverso dei sistemi per la
gestione di basi di dati?
Ora tu mi dirai che si puo' benissimo progettare un sistema tenendo
conto anche dell'aspetto della persisenza degli oggetti: al che io ti
rispondo che puo' essere altrettanto utile iniziare un progetto
partendo dalla comprensione delle informazioni che andranno gestite,
delle relazioni di quest'ultime con il resto del sistema informativo,
e quindi dell'aspetto della *persistenza* di quest'ultime, senza
perdere di vista l'obiettivo di progettare di applicazioni che da
quelle informazioni dipendono: in realta', devo dire, tutto cio' mi
sembra una questione di lana caprina, dato che non vedo una netta
distinzione tra i due approcci, come perlatro lo stesso Flowers da te
citato conferma: "Class models are comfortably similar to data
models", e il pericolo che egli intravede, "The major problem in using
class diagrams in using class diagrams is that it is easy to develop a
class model that is data oriented rather than being responsibility
oriented", si puo' benissimo rovesciare nel pericolo opposto, ovvero
quello di sviluppare un progetto che e' legato alle contingenti
necessita' del cliente, perdendo di vista l'importanza di una corretta
modellazione e integrazione dell'informazione utilizzata
dall'applicazione con il sistema informativo.
Ad ogni auguro buona fortuna al tuo nuovo collega, ne avra' bisogno
suppongo.
Michele

Per caso sei un DBA?

Per caso sei un DBA?
"Sei un DBA?"? ... non stiamo parlando delle responsabilita' di un
oggetto in un progetto OO: cosa sono io non l'ho ancora capito, non
vedo quindi come potrei spiegarlo a te.
Michele
"Un monaco curioso pose a un maestro la domanda: 'Che cos'e' la via?'.
'E' proprio davanti ai tuoi occhi' disse il maestro.
'Perche' non la vedo da solo?'.
'Perche' stai pensando a te stesso'.
'E tu la vedi?'.
'Finche vedi doppio, dicendo 'Io no' e 'Tu si' e cosi' via, i tuoi
occhi sono annebbiati' disse il maestro.
'Quando non c'e' ne' 'Io' ne' 'Tu', la si puo' vedere?'.
'Quando non c'e' ne' 'Io' ne' 'Tu', chi la puo' vedere?'."

 dall'applicazione con il sistema informativo.
che non e' bello sia con l'approccio tradizionale che con quello
object-oriented. ;) 
Assunto che l'approccio database-centered e quello object-centered sono
entrambi strumenti per fornire "una corretta modellazione etc etc",
l'object-orientation, per problemi oltre una certa complessita', offre
vantaggi documentati. 


vantaggi documentati. 
Come diceva il maestro che ho cotato l'ultima volta, per avere
l'illuminazione bisogno imparare a non vedere *doppio*, ovvero
riuscire a superare quelle contrapposizioni che sono a volte, solo
apparenti: non c'e' scritto da nessuna parte infatti che anche il
database non possa essere perlomeno pensato in un'ottica OO ;-)
ciao, Michele


Penso che dovresti spiegarci meglio cosa intendi per "ottica OO" e in che modo riesci a
riconoscere un oggetto in un database, e soprattutto ad assegnargli delle responsabilita'
ed a farlo collaborare con altri. Perche' in OO questo e' fondamentale.
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|

 database non possa essere perlomeno pensato in un'ottica OO ;-)
Forse ci stiamo confondendo. Pensare un database in ottica OO equivale a
pensare un sistema OO e usare un database per la persistenza. 
Cio' che io discuto e' l'approccio alla *modellazione* database-oriented,
per cui modelli l'universo con concetti relazionali, file-oriented,
reticolari etc, e costruisci un sistema concettualmente fondato su questi
modelli. 


ed a farlo collaborare con altri. Perche' in OO questo e' fondamentale.
Chiariamo subito che la possibilita' che ho prospettato, non e' quella
che utilizzo abitualmente: il Galileo e' un linguaggio sperimentale
molto interessante, ma confinato, almeno per il momento, a livello di
ricerca, e puo' essere utilizzato in produzione eventualmente solo
come strumento di prototipazione, cose entrambe, che per il momento
non mi interessano. 
Ad ogni modo l'insegnamento piu' interessante che mi ha lasciato lo
studio di questo linguaggio, che integra in un unico ambiente sia
l'aspetto statico che quello dinamico, e' proprio la dimostrazione che
la divisione tra l'aspetto della modellazione dell'aspetto statico dei
dati con quello dinamico, e' probabilmente dovuta solo a ragioni
storiche, ovvero alla mancanza di strumenti tecnologici adeguati a
supportare un approccio integrato. 
Questo insegnamento credo inoltre mi torna comunque utile, perlomeno a
livello inconscio, dato che in genere mi evita di relegare l'aspetto
della modellazione dei dati, che a mio avviso e' invece strettamente
legata a una buona comprensione del dominio del problema, ovvero alla
parte meno soggetta a cambiamenti improvvisi, in ultimo piano. 
ciao, Michele


Lo strumento tecnologico esiste, e si chiama "Object Oriented Paradigm". Si e' dimostrato
pero', nel tempo, che gli aspetti statici (dati) sono molto meno importanti di quello
dinamici che si applicano ad essi.
Inoltre continuo a non capire al database "pensato in un'ottica OO".


modelli. 
Questo e' l'errore esattamente simmetrico di chi costruisce un modello
concettualmente *infondato*, ovvero slegato dalla comprensione del
dominio del problema: equilibrio ci vuole, equilibrio :-))
ciao, Michele

ed a farlo collaborare con altri. Perche' in OO questo e' fondamentale.
Chiariamo subito che la possibilita' che ho prospettato, non e' quella
che utilizzo abitualmente: il Galileo e' un linguaggio sperimentale
molto interessante, ma confinato, almeno per il momento, a livello di
ricerca, e puo' essere utilizzato in produzione eventualmente solo
come strumento di prototipazione, cose entrambe, che per il momento
non mi interessano. 
Ad ogni modo l'insegnamento piu' interessante che mi ha lasciato lo
studio di questo linguaggio, che integra in un unico ambiente sia
l'aspetto statico che quello dinamico, e' proprio la dimostrazione che
la divisione tra l'aspetto della modellazione dell'aspetto statico dei
dati con quello dinamico, e' probabilmente dovuta solo a ragioni
storiche, ovvero alla mancanza di strumenti tecnologici adeguati a
supportare un approccio integrato. 


Inoltre continuo a non capire al database "pensato in un'ottica OO".
Ma l'XP non e' orientata al cambiamento? :-) ... non fossilizzarti nei
soliti schemi mentali, prova a uscire dalla ristretta gabbia in cui le
parole, spesso, costringono le idee :-) 
ciao, Michele

 hai fatto ti scusolo stesso  :-))
LOL no, semplicemente l'approccio database-oriented, se sei abiutato a
ragionare per ruoli, responsabilita' e interazioni ti appare davvero...
limitato. Meglio, per carita', dall'approccio niente-analisi, pero'.. :) 



Soliti schemi mentali, eh? Sicuro che stai parlando di me e invece non lo stai dicendo a
te stesso :-D? Guarda che sei *tu* quello che blandiva il fresco neolaureato programmatore
che partiva dal database per modellare, che so, un sistema di trading online o un sistema
di gestione di finanziamento, non io!
(eh eh, mi e' successo pure questo, fra l'altro)


limitato. Meglio, per carita', dall'approccio niente-analisi, pero'.. :) 
ciao, Michele

(eh eh, mi e' successo pure questo, fra l'altro)
Per far si' che ci siano sempre piu' persone che arrivano
all'illuminazione, questo ed altro :-))
ciao, Michele


Ti invito a leggere i miei post precedenti su questo thread, be focused.


 Programmer?
[sdcarl!lin, Real Programmers Don't Use Pascal, UUCP network, 1983 
], 
http://space.tin.it/computer/csadun/articoli/realprog.html


> specifiche del cliente sono *aperte* (al buon senso:).
Questo spesso non gioca a favore di chi sviluppa. Il buon senso di chi
sviluppa è spesso diverso dal buon senso di chi scrive le specifiche.
Un mio ex-capo un giorno mi disse che il "programmatore non deve avere
fantasia; quando ce l'ha è un guaio". Lungi dal dire la stessa cosa...
Quando avrò un attimo leggo anche il resto del messaggio, perché questo
thread continua ad appassionarmi :). Peccato che questi giorni non riesco a
mantenermi aggiornato, ma sto facendo le notti in ufficio... una nota
metodologia non proprio XP ;-) ma questo è dovuto al buon senso di chi ti
cambia le specifiche il giorno prima di entrare in produzione (naturalmente
di test neanche a parlarne...)

 --Jigi
-- 
Posted from 
adsl-162-177.36-151.net24.it
 [151.36.177.162] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Mai detto questo.
Hai difronte una carriera come politico...
Pensavo che il discorso fosse interessante... in realtà è spaziale... credo
di averci inteso anche la spiegazione dell'entropia.
Jigi

 Grazie per aver scatenato una discussione cosě interessante
Prego :-)
Jigi

Ti invito a leggere i miei post precedenti su questo thread, be focused.
Spero di non aver urtato troppo la tua suscettibilita' :-)
ciao, Michele
p.s. Scusa per il ritardo, ma non c'e' lo fatta prima.

Jigi
Uhm ... da questo devo dedurre che non hai capito nemmeno l'entropia.
Michele

:)
Dal titolo penso di avere un'idea di cosa si tratta, ma bisognera' che
lo legga con attenzione comunque, altrimenti come faro' a diventare
mai un *vero* programmatore? :)
ciao, Michele

Non replico...
uno perché non c'è materia su cui replicare
due perché non c'ho voglia di andare a prendere il dizionario per capire
quello che scrivi... (ti lascio spazio per darmi del troglodita, così ti
sentirai più dotto)
quando la pianti di mischiare Godel, Escher, Bach e le tragedie greche con i
discorsi tecnici forse comincio a chiedermi se davvero sai di ciò che parli.
rgds,
~Jigi

 mai un *vero* programmatore? :)
:-)



Semplicemente hai un modo di discutere che non apprezzo. Capita.


Semplicemente hai un modo di discutere che non apprezzo. Capita.
Anche tu, se permetti un apprezzamento, hai un piccolo difetto quando
ti poni in discussione con qualcun altro: parti sempre dal presupposto
che le cose sono o bianche o nere, e che il modo in cui le descrivi
tu, e' proprio quello bianco ... ;-)
Ad ogni modo apprezzo molto la tua franchezza,
ciao, Michele
p.s. Dato che mi pare la discussione stia diventando un po' sterile io
mi fermo qui.

valida.
Uhm... si, diciamo che comunque dopo di strumenti ne sono nati
parecchietti, forse significa qualcosa che non ci sia stato un analogo
fermento dall'altro lato.
*FINE QUOTE*
[...]
Mi auguro che cio' sia sufficiente come tentativo di spezzare una
lancia in favore del neo-assunto, e che non tentiate ancora di farmi
dire quello che non voglio, e soprattutto non posso esprimere :-)
ciao, Michele