Newsgroup: it.comp.lang.vo-clipper
Titolo: Programmazione GUI center?

Cari amici, tornando sul discorso della specializzazione delle finestre,
a me sembra, almeno dagli esempi che riportate, che VO incoraggi un tipo
di programmazione OO che ha come punto centrale le finestre con tutti i
loro controlli, eventi e meccanismi vari, dico bene?
Ma questi sono aspetti appartenenti allo spazio della soluzione mentre
la buona OOP prevede che l'astrazione di cui ci si debba occupare sia
quella appartenente allo spazio del problema.
Quindi non dovrei avere, mentre progetto la mia applicazione, tra i
piedi concetti come finestre, pulsanti e checkbox ma concetti come
fattura, cliente, ordine, etc.
Dico bene? E' questa la strada che seguite anche se non lo dite
esplicitamente?
EMG
-----------------------------------
EMAG Software homepage
http://www.emagsoftware.it
The EMG's ZX-Spectrum Software Page
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games
http://www.emagsoftware.it/tbosg

 ha scritto nel
messaggio news:3BD12AC5...@emagsoftware.it...


 pensare nei termini di oggetto cliente, fattura ecc.
Di questo non avevo alcun dubbio (ci mancherebbe!). Mi chiedevo
solamente, visto il contenuto dei messaggi che vedo da queste parti
riguardo VO, se un programmatore VO non sia, per caso, "fuorviato"
dall'impostazione offerta dallo strumento e si trovi a muoversi, suo
malgrado, sempre all'interno dello spazio delle soluzioni invece che in
quello del problema.


 ha scritto nel
messaggio news:3BD1ACD8...@emagsoftware.it...


 ha scritto nel
messaggio news:3BD12AC5...@emagsoftware.it...


 essendo domenica.
Sei stato chiarissimo.
EMG
___________________________________


 Dico bene?
Dipende da chi sviluppa... VO ti mette a disposizione tutti gli strumenti
per fare ciò che hai detto, oppure non farlo !!!
E' questa la strada che seguite anche se non lo dite
 esplicitamente?
Molti di noi provengono da una filosofia di programmazione diversa, quindi
imparare a "ragionare" OO richiede del tempo, credo che diversi sviluppatori
VO non abbiano ancora capito come si ragiona OO (ad esempio io ci sono
arrivato da poco dopo 6 anni di sviluppo con VO!!!) D'altra parte nei corsi
si tende a dare più importanza al linguaggio più che alla filosofia OOP con
la quale sfruttare le sue potenzialità) ma piano piano ci stanno arrivando.
Ciao
Enio


 la quale sfruttare le sue potenzialità) ma piano piano ci stanno arrivando.
Questo vale esattamente anche per me. D'altronde nessuno pensa che la
OOP sia il rimedio a tutti i mali. Può darsi benissimo che per il
gestionale sia preferibile qualche altro paradigma, magari ancora da
inventare...
EMG
PS. Spero senza rancore per le discussioni riguardanti la pubblicità,
discussioni che non vogliono assolutamente essere rivolte alla
particolare persona ma alla situazione.
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum


 ha scritto nel
messaggio news:3BD12AC5...@emagsoftware.it...


 ha scritto nel
messaggio news:3BD12AC5...@emagsoftware.it...

Esattamente; una buona programmazione OOP č anche quella di risolvere i
problemi in modo OOP e non solo utilizzarne la sintassi per risolverli in
maniera tradizionale.
Ciao,
       Fabrizio Malaguti


E' supportato.
Comunque moltissime cose sono facilmente simulabili in VO ( variabili read
only,  variabili di tipo static, Template , ereditarietà multipla ecc.)
Ciao,
       Fabrizio Malaguti

 inventare...
Io personalmente sono arrivato alla conclusione che un programma non debba
essere per forza completamente OOP, trovo piu' comodo un approccio ibrido
come quello di VO, Xbase++, Delphi piuttosto che un approccio rigidamente
OOP come quello di Java.
Ritengo che la OOP sia fondamentale quando si deve costruire un framework
come quello necessario per implementare una GUI, quindi quando si deve
costruire una struttura complessa, ma quando si deve risolvere un problema
semplice che verra' utilizzato in ambito locale senza futuri utilizzi
imprevedibili, sia piu' comodo e veloce scrivere in modo procedurale, ad
esempio, se devo calcolare lo scorporo dell'IVA sto certamente prima a
scrivere:
function scorpora(nVal,nIVA)
return nVal / (1 + nVIA/100)
piuttosto che:
class scorporo
  var nVal, nIVA
  method calcola
endclass
method scorporo:calcola
return ::nVal / (1 + ::nVIA/100)
considerando che la classe da devo istanziare e deallocare 
(con alcuni linguaggi).
Mi sembra essenziale dividere la parte della realizzazione di un 
framework OOP dalla sua utilizzazione anche se magari sono fatti
dalla stessa persona, la parte difficile e' costruire il framework
il suo utilizzo e' decisamente piu' semplice.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 return ::nVal / (1 + ::nVIA/100)
Lo sbaglio qui è che hai erroneamente considerato il concetto di
"scorporare" (evidentemente un verbo e quindi una azione -> un metodo)
come un attore nel tuo spazio del problema. Il metodo ScorporaIVA(),
invece, dovrebbe appartenere, probabilmente, alla classe Fattura o
magari ad una classe superiore (base) Documento. Oppure, volendo
fattorizzare maggiormente, il metodo Scorpora() apparterrebbe alla
classe Iva (che quindi saprebbe come "scorporarsi"). In questo modo il
concetto di scorporare prende il suo posto con naturalezza. Certamente
non ha senso una classe Scorporo.
EMG


Non ti preoccupare ... se dovessi portare rancore per queste cose sarei
finito !!!
Ciao
Enio

INFATTI !!! ciò che dice Enrico è vero. Ricordo quando partecipai al mio
primo corso su VO (1994). Il mio problema non era tanto conoscere il
linguaggio ma riuscire a capire cosa cavolo era questa OOP. In tutti gli
esempi si parlava di cavalli, asini, uccelli ecc... A questo corso capii
finalmente i concetti che stanno alla base e mi fu molto utile. Quando si
cerca di affrontare un problema, bisogna riuscire a capire che cosa vuole
effettivamente il Cliente e scriverlo. Sembra una cavolata ma dicendola in
maniera semplice, bisogna estrapolare i sostantivi da ciò che si è scritto e
queste potrebbero essere le Classi. Estrapolando le azioni che devono
svolgere si individuano quelli che probabilmente saranno i metodi.
Se ad esempio il cliente dice : "io vorrei poter stampare inserire e
modificare una fattura, poi vorrei avere una anagrafica dei clienti e
poterli inserire e modificare ecc...  " da qui si può intuire che
probabilmente le Classi saranno "CLIENTI" e "FATTURE" i loro metodi saranno
le azioni.. quindi "inserire", "modificare" ecc... Le relative finestre non
sono altro che degli strumenti per poter effettuare queste azioni.  Lo so
non è facile da capire al volo, ma bisogna usare carta e penna per
pianificare. E poi sicuramente viene sempre un buon lavoro.
Ciao Enio

 finito !!!
Mi fa molto piacere sentirtelo dire. E' segno che sei una persona
razionale. Mi domando come, un programmatore, potrebbe non esserlo...
:-)
EMG


 pianificare. E poi sicuramente viene sempre un buon lavoro.
Beh, tutto il resto lo condivido ma questo non è detto. Dipende sempre
dall'abilità del programmatore.
EMG


 non ha senso una classe Scorporo.
Nel contesto sono d'accordo, ma era solo un esempio, quello che intendo
dire e' che trovo la OOP prolissa per i problemi semplici, forse e' un
problema di punti di vista.
Pero se vogliamo spingere la OOP agli estremi, ci scontriamo con la
rappresentazione dei dati nel database, ad esempi come memorizzi il
tuo oggetto fattura?
Resta il fatto che se gli oggetti sono i mattoni con cui costruisco
la casa/applicazione, io che sono muratore uso i mattoni ma non li
fabbrico, questo per distinguere i ruoli tra la costruzione di un
framework ed il suo utilizzo, chi usa VO oppure Delphi basa il proprio
lavoro GUI su un framework esistente.


 lavoro GUI su un framework esistente.
Chiaro. Altro aspetto ancora. In effetti la OOP ha fra le sue tante
caratteristiche interessanti quella di favorire la programmazione per
"componenti". Quindi, almeno intenzionalmente (i risultati però, secondo
me, non hanno mantenuto del tutto le promesse), così come nell'hardware
si utilizzano i chips che qualche industria ha progettato e costruito,
così nel software si userebbero i "software chips" che qualche software
houses ha sviluppato.


 houses ha sviluppato.
In effetti, viene proposto questo parallellismo, ma i risultati non sono
stati esaltanti, gli OCX sono molto usati perche' vengono usati da VB, ma
sono una soluzione piuttosto sporca e richiedono una procedura di installazione
su ogni macchina, CORBA non ha avuto successo soprattutto perche non e'
targato MS, alla fine la strada piu' usata e' quella classica di linkare
staticamente o dinamicamente una libreria monolitica all'applicazione,
forse .NET potrebbe essere una situazione unificate che porta ad un 
effettivo riutilizzo degli oggetti, ma ha un grosso difetto... appartiene
a MS


 su ogni macchina,
Non me ne parlare... :-(
