Newsgroup: it.comp.lang.visual-basic
Titolo: OOP e VB6... alcune domande...

Ciao a tutti,
sto preparando un applicativo che, nelle mie intenzioni, dovrebbe essere il
framework su cui costruire altri software...
Tra le ose che questo sw gestisce c'è la possibilità di essere
multidocumento e mi piacerebbe anche multiutente.
Sapete dove posso trovare dei riferimenti sullo sviluppo di questo tipo di
funzionalità in un software?
Grazie
Davide

 tipo di funzionalità in un software?
Beh, questo genere di funzionalità non è molto complesso, posto che
ti organizzi bene dall'inizio.
Dipende anche da cosa intendi tu per "utente": un utente può anche essere
un altro software che usa il framework( hai presente la GDI di Win? ).
Quindi se magari ci specifichi un pò meglio quello che hai in mente,
possiamo
anche consigliarti a ragion veduta.
Ciao
Andrea

 Premessa: OOP e VB6 è una contraddizione in termini... :PPPPP
L'OOP sta nella testa di chi sviluppa. Si può fare OOP in assembly o in C (e
sicuramente lo si fa in VHDL), mentre si può non farlo pur usando Java o C#.
Che poi una piattaforma di sviluppo faciliti la programmazione orientata
agli oggetti ed un'altra non, siamo tutti d'accordo, ma sicuramente ci sono
strumenti molto meno indicati del VB6 per fare OOP..
-- 
Ale
La RFD originale per it.comp.dotnet su
http://www.sen.it/stoa/articles.asp?id=10
Se vuoi discuterne, vai su it.news.gruppi

 anche consigliarti a ragion veduta.
hai perfettamente ragione.. scendo nei dettagli...
premessa, io sviluppo software cad/cam, fino ad ora abbiamo fatto un riuso
del codice del tipo copia/incolla oppure suddividendo il sorgente in moduli
strategici.
Ora l'applicativo ha raggiunto la vetusta età di quasi 15anni e abbiamo
deciso di investire tempo e risorse nella sua "ristrutturazione". A questo
scopo sto preparando
una "base" con gli strumenti minimi per la visualizzazione grafica,
input/output da file, memorizzazione di info geometriche etc etc
questo in pratica è il nocciolo comune al 90% del sw che sviluppiamo.
Le personalizzazioni, oppure le aggiunte per cliente al software verrebbero
realizzate come addin di questo applicativo.
quindi in sintesi ho il mio bel applicativo base che espone delle
interfaccie con implements. Gli addin aggiungono menu e toolbar al base e
gestiscono le varie problematiche
sfruttando parte del codice comune (per esempio le funzioni di matematica e
geometria saranno interne al programma base) aggiungendo le funzioanlità
necessarie...
questo è quanto.
Multidocumento: perchè ho la necessità di avere + doc aperti
contemporaneamente
Multiutente: perchè posso avere più addin, e diveri profili di utenti
"umani".. il secondo problema non è grave.. alla partenza mi scelgonoil
profilo e finisce li... il 1° credo sia un falso problema
basta fare attenzione a non fare troppi "pastrocchi"  con variabili
publiche....
cosa ne pensi? sono stato abbastanza chiaro?
grazie
Davide

 L'OOP sta nella testa di chi sviluppa. Si può fare OOP in assembly o in C
.......
beh dai.. stava facendo dell'ironia... un pochino di umorismo ;)
Davide

 Davide
Andrea

 Credo di si, e tu che ne pensi di quello che ti ho detto io?
beh mi hai fatto venire un paio di dubbi e chiarito altri.. vedi le mie
contro-domande :)
e grazie!
Davide

 Davide
Andrea

 Secondo me ogni categoria di settaggi deve avere la propria classe.
non ho poi troppo codice? non diventa dispersivo?
ora le varie classi dell'engine prendono la configurazione da un file ini...
quindi variando il file ini io ho diverse configurazioni... se io la lettura
la faccio fare da una cUser e poi uso "currentUser" (metodo della classe che
gestisce gli user) per passare al motore la config non è più "incapsulato"?
alla prossima
Davide

 Davide
Andrea

 Il codice, naturalmente, alla fine c'è sempre.
ma in pratica non la programmo in Vb giusto?
Ciao
Davide

 Davide
Ciao
Andrea

 
http://archive.eiffel.com/doc/manuals/technology/contract/
 .
sto giusto leggendo :)
ciao
Davide

 ed il 3°??
1)Strutture dati e definizione operazioni elementari
2) Elaborazioni varie
3) GUI
Ho capito va.
Spetta qui.
Andrea

Leggiti il post di su, così ti fai un'idea di quello che intendo :))))
Ciao
Andrea

 Leggiti il post di su, così ti fai un'idea di quello che intendo :))))
fatto e quello che mi hai detto è chiaro..
diciamo che dal punto di vista del concetto non ci sono dubbi.. è il
trasformare in pratica il concetto che fa sorgre dubbi...
vediamo un altro aspetto dell'applicazione: i plugin.
allora io voglio che lo sviluppatore del plugin possa creare delle toolbar
personalizzate all'interno del mio sw.
Ho una classe cAddin che in pratica è l'interfaccia (per ora in stile Vb...)
che tramite "implements" mi fornisce i metodi:
-connect
-disconnect
connect passa dal sw host al sw plugin il riferimento alla classe cApp che è
la classe principale dell'applicazione host, l'oggetto root (non credoisa il
termine giusto.. )
bene ora cApp deve permettere allo sviluppatore di plugin di aggiungere una
toolbar.
e lo fa tramite il metodo "addtoolbar"...
e qui vengono le note "dolenti"... per caricare a runtime una toolbar Vb mi
obbliga a partire con una toolbar (0)..
quindi addtoolbar  farà il load di toolbar.count e memorizzerà i
riferimenti...... ok?
Ma.. come fa cApp a fare il load se non conosce la GUI? e se la conosce
quanta ne conosce?
cApp è operazione di base, GUI o elaborazione? credo op. di base quindi non
dovrebbe conscere la Gui... cosa mi perdo?
io risolverei passando in fase di inizializzazione dell'applicazione host
(sub main....) il rif alla toolbar (0) a cApp... ma è lecito?
ciao
Davide

 Davide
Ciao
Andrea

> cApp è elaborazione.
Per essere precisi, cApp viene DEFINITA nel livello elaborazione, ma CREATA
nella form, per capirci. E poi passata ai vari plug-in in fase di
inizializzazione degli stessi
( cApp avrà una classe interna che legge il registry e fa il load dei
plug-in ).
Ciao
Andrea

 inizializzazione degli stessi
Ok questo è chiarissimo
ho capito.. ;)
bene bene
Davide

 la toolbar secondo i parametri presenti nell'evento scatenato da cAPP.
ma quindi alzo un evento di cApp e la GUI in ascolto di quell evento mi crea
la toolbar
oppure
capp alza un evento della GUI?
l'evento è della GUi giusto?
quindi cApp deve conoscere la GUI?
Davide

 definire solo le interfacce e poi usare "implements" in delle classi
specifiche > per implementare le interfacce.
Al di la del fatto che possa essere piu' o meno bello usare classi "vuote"
come definizione di interfacce, nota che in VB enterprise esiste un opzione
nelle proprieta' del progetto: "Remote server files" (in italiano "Crea file
per esecuzione come server remoto") che a rigore serve per componenti DCOM;
in ogni caso attivandola e compilando il componente ottieni, tra gli altri,
la tua bella type library...
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Ciao
Ciao
Andrea

 Davide
Andrea

 fà: "ok, ok, ti creo la toolbar!!!!!".
allora è la gui a dover conoscere il motore.. ok ci sono :)
ciao
Davide

Davide
Ciao
Andrea
-------------------------------
Message Posted by  <dedGateway>
http://www.dedonline.com/forump

 Sa solo che esiste il motore.
si si ora è chiaro...
quello che mi incasinava era proprio capire chi sa cosa di chi.. :)
 ora nuovi orizzonti si sono aperti davanti ai miei sorgenti ;)
vado a frugare in cerca di nuovi mirabolanti  dubbi :D
Davide

Davide


 Che io ti dovrò chiarire? :PPPPPPPPP
beh... finora nel thread vi siete fatti vivi tu e deerbear (che siete la
stessa persona...)
quindi :D......
Davide

 Davide
Ciao
Andrea

 consigliato per il meglio, se vuoi, te lo mando in anteprima :)))))
volentieri :)...
un'altra cosa ce esula un poco dal discorso OOP... ma riguarda più che altro
l'implementazione del codice...
è possibile in qualche modo passare ad una funzione una stringa che contiene
il nome del metodo della classe da lanciare?
Ciao
Davide

il nome del metodo della classe da lanciare?
Puoi farlo con la reflection  ma non conosco VB6 e quindi non so se
possiede tali features
--
Rhymes
news://it.comp.lang
The italian Python (and other languages) NG

 specifiche per implementare le interfacce.
Anche in C++ non hai delle vere interfacce, ma solo classi
astratte... ma questo non è certo un problema.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 mentre si può non farlo pur usando Java o C#. 
Su questo ancora meno. Java, C#, come tutti i linguaggi OO
"puri" non permettono di utilizzare altri paradigmi. Puoi fare
sicuramente della pessima OOP...


 corretta pianificazione..
Buona, corretta e soprattutto difficile...
perché purtroppo il VB *non* ti viene incontro.


sicuramente della pessima OOP...
Mmm non sono daccordo con la definizione di linguaggio OO puro o
meno... e Java di certo non lo è. Tra l'altro viene definito ibrido su
praticamente tutti i testi
Ecco le mie motivazioni:
Ipotizzo che tu per linguaggio puro intenda un linguaggio in cui tutto
è oggetto...giusto? Bene il tipo int in Java (come gli altri
primitivi) non lo è. Non deriva da Object (ciò non vale per il C#).
Linguaggi "puri" possono essere Ruby (anche troppo), Smalltalk, C#
stesso ma non Java


 troppo), Smalltalk, C# stesso ma non Java
Tralasciando le definizioni che, purtroppo, sono sempre in parte
opinabili, il fatto che non tutto sia un oggetto non ha
implicazioni in questo discorso, in Java *non* puoi scrivere un
programma che non sia OO, visto che non esiste una main che non
faccia parte (per quanto statica) di una classe.


faccia parte (per quanto statica) di una classe.
Su questo sono daccordo...ma è proprio su queste definizioni che il
mondo si muove :)
Vediamo di chiarire in modo semplice semplice
Java non _pure_ OO, ma non puoi scrivere codice non OO per il semplice
fatto che tutto è inglobato in classi


 in Java *non* puoi scrivere un programma che non sia OO
Non vorrei aprire un flame, ma non sono d'accordo. I linguaggi di
programmazione, ed in generale le piattaforme per lo sviluppo, non sono
altro che strumenti che possiamo usare utilizzando determinate metodologie o
meno. La piattaforma di sviluppo Java facilita la programmazione ad oggetti,
e su questo non ci piove, ma non è assolutamente detto, se uno vuole, che
non ci si possa programmare in maniera procedurale, pur essendo all'interno
di una classe ed utilizzando soltanto istanze di classi. Un piccolo esempio:
l'HelloWorld che si vede in tutti i tutorial, quello con solo un main ed una
riga, è un programmino procedurale. Dentro una classe, ma sempre procedurale
è. E mentre d'altra parte è vero che non è il fatto che non ci sono
funzionalità per creare creare classi ed interfacce nel C, è pure vero che
se uno vuole può tranquillamente programmare ad oggetti in C: è una
questione di forma mentale, non di strumenti. Il C non facilita la cosa,
ovviamente, Java sì, VB anche (un po' di meno di Java, d'accordo).
-- 
Ale
La RFD originale per it.comp.dotnet su
http://www.sen.it/stoa/articles.asp?id=10
Se vuoi discuterne, vai su it.news.gruppi

 semplice fatto che tutto č inglobato in classi
Sě, ok. Infatti il "puro" era scritto tra virgolette, e mi
riferivo appunto non al fatto che tutto fosse un oggetto ma al
fatto che *non* puoi non utilizzare gli oggetti...


 non di strumenti. 
Come ho detto non sono del tutto d'accordo... Per volere essere
precisi gli "oggetti" del C *non* sono (secondo la definizione)
*veri* oggetti. Se non sono veri oggetti accetto anche con
difficoltà che possa essere *vera* programmazione orientata agli
oggetti...


 Ciao.
Ciao
Andrea

che conta è il risultato che si ottiene:
Ah! Se ti sentisse gente come Meyer, Booch ecc ecc :-)


 del C *non* sono *veri* oggetti.
Secondo me la discordanza su questi argomenti tra di noi deriva dal fatto
che tu la vedi dal lato pratico, ed ovviamente in C non c'è una qualche cosa
chiamata oggetto che si istanzi da una classe e via di seguito, mentre io
sto parlando in generale, come approccio alla soluzione dei problemi. Per me
un'approccio OO si può usare, con alterni successi, non solo nella
programmazione di software, ma anche in ben altri settori (non
dimentichiamoci che il termine design pattern viene dall'architettura, ad
esempio).


 implementazione cosa che in VB non è vera.
Anche in VB, basta non scriverla (come d'altra parte in C++).


 problemi.
La differenza *fondamentale* fra la programmazione procedurale e
quella OO è che nella prima ci sono i dati e ci sono funzioni
che li manipolano (e li usano), mentre nella seconda i
dati "prendono vita", e diventano oggetti. Le caratteristiche
*cardine* degli oggetti (e di conseguenza della OOP stessa) sono
l'astrazione, l'incapsulamento, per cui *non* è possibile
conoscere, modificare, alterare, la struttura interna e/o lo
stato di un oggetto se non chiedendo all'oggetto stesso di
farlo, le classi, l'ereditarietà ed il polimorfismo. 
Questi concetti sono *le basi* della OOP, venendo a mancare loro
viene a mancare l'OOP stessa (ed i suoi vantaggi).
In C (e pure in altri linguaggi senza supporto per l'OOP) viene
a mancare l'incapsulamento, che è forse il concetto più
importante, perché èla sua mancanza fa venire meno (quasi) tutti
i vantaggi della OOP stessa. Questo perché, pur dando una
diversa impostazione al programma, avrai sempre dati e funzioni
che li manipolano(come nella più banale programmazione
procedurale). Scrivere (solo sintassi VB per chiarezza): Dim
main_window as New Window
main_window.Show()
è ben diverso dallo scrivere:
Dim main_window as Window
ShowWindow(main_window)
come saresti costretto a scrivere in C.


 No, non è così. Il supporto del linguaggio è *fondamentale*
Questo è un tipico caso di clash of opinions. La questione è che secondo me
abbiamo le stesse idee, ma le applichiamo in domini di differente
estensione: per me cambiare le lampadine del lampadario può essere fatto
utilizzando tecniche OO oppure in maniera procedurale o magari funzionale o
anche usando qualche altra metodologia, i design pattern possono essere
applicati da un pizzaiolo come da un calzolaio, e via di seguito. Tu
probabilmente invece non vedresti incapsulazione o polimorfismo nella
maniera in cui io cambio le lampadine fulminate, tutto qui :-)


 fulminate, tutto qui :-)
No, più che altro, e la tua citazione dei design patterns mi
accresce il dubbio, inizio a credere che tu stia parlando di OOD
più che di OOP... 


 OOD più che di OOP...
Anzi, rileggendo ora senza la stanchezza della sera ne ho la
certezza...
Sono d'accordo con te quando dici che il paradigma OO può essere
applicato in vari campi (anche se il cambio di lampadine è un
esempio decisamente fuori luogo), ricordando sempre, però, che il
mondo reale *non* è ad oggetti...
Però il subject del thread parla chiaro: OOP, ovvero
*programmazione* OO, ed il termine *programmazione* è ben chiaro e
specifico, ed è della OOP, programmazione e *solo* programmazione
che io parlavo. E la "famosa" riga System.out.println("Hello World")
*è* programmazione OO e non procedurale, per quanto possa non
appartenere, nella sua banalità, ad un *design* OO.
Ed ancora, la OOP applicata, per esempio, al C, *non* porta gli
stessi vantaggi (anzi, non ne porta affatto) di quando è applicata
al C++ (od allo stesso VB).
E basta pensare (vedi GTK) a codice (pseudo, secondo me) OO in C per
rendersene conto.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 al C++ (od allo stesso VB).
Qui un po' meno, ma non credo sia il caso di sottilizzare..


 Qui un po' meno, ma non credo sia il caso di sottilizzare..
Oh, beh... Dimostrare questo con un po' di codice è come sparare
sulla Croce Rossa...
Ciao.
-- 
