Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] Capire e applicare la programmazione ad oggetti

Salve a tutti,
vorrei che mi aiutaste a capire come potrebbe essere utilizzata
la programmazione ad oggetti nella semplice gestione di un
db Access.
Mi sono letto pagine e pagine, e fatto esempi su esempi su
cosa sia una classe un oggetto etc.. etc.. ma ho grandi difficoltà
ad entrare nella parte e capire come utilizzarli all'atto pratico.
Al momento, per esempio, vorrei creare una mini applicazione
che mi permetta di accedere ad un db Access e monitorare
l'andamento degli acquisti mese mese...
quandi avrei delle tabelle con i movimenti e delle interrogazioni
semplici che mi suddividono gli acquisti mese mese,  acquisti
per fornitore, dettaglio delle bolle ecc...
Ovviamente potrei fare la stessa cosa con Access, ma vorrei
sfruttare la cosa come  un bell'esercizio di VB6 e soprattutto
vorrei provare a programmare ad oggetti, e non come l'ultima
applicazione in cui andavo avanti a braccio e riga dopo riga
fino a trovarmi un qualcosa di ingestibile e problemi ripetuti.
Praticamente vorrei un input, uno start, perchè sento che
la soluzione è vicina ma non riesco a sbloccarmi.
Grazie per ogni eventuale consigli
WS

 la soluzione è vicina ma non riesco a sbloccarmi.
E' vero, libri e libri con chili e chili di teoria, tutta vera e giusta, ma 
poi all'inizio e' difficile entrare nell'ottica, perche' di questo si tratta 
semplicemente, entrare nell'ottica.
Io ho capito l'utilita' della programmazione ad oggetti quando ho sentito 
l'esigenza e mi sono fatto il mio primo oggetto com, era un dll mi pare.
Esempio pratico, quando tu ti connetti ad un database, access ad esempio, 
usi Ado mettiamo. Ecco tu stai gia beneficiando della programmazione ad 
oggetti, perche' qualcuno ha fatto per te un oggetto gia pronto che si 
chiama ado, che espone metodi proprieta' ed eventi e che tu puoi usare, su 
ogni programma.
Tu puoi fare la stessa cosa, crearti tutti gli oggetti che vuoi che facciano 
quello che vuoi e una volta creati risparmiarti righe e righe di codice.
La parte difficile che si acquisisce solo col tempoe e l'esperienza e' 
proprio riuscire a vedere gli oggetti e a programmare in base a questi, 
quindi cambiare il modo di strutturare il programma in modo di beneficiare 
il piu possibile di tale filosofia.
Esempio banale sull'uso della programmazione ad oggetti.
Vuoi avere un textbox che accetta solo caratteri numerici?
hai 2 possibilita'.
1
In ogni form o programma in cui ti serve questa cosa scriverti ogni volta il 
codice che lo fa.
2
Creare un controllo Ocx (un oggetto) chen implementa tale funzione (ed altre 
che ti possono essere utili) e che importi in ogni programma.
Da quel momento non dovrai piu preoccuparti di scrivere di volta in volta il 
codice necessario, beneficiando di un discreto risparmio di tempo, energie e 
migliorando decisamente sia l'ordine che la mantenibilita'.
Poniamo l'esempio infatti che trovi il modo di migliorare tale funzione del 
tuo textbox, oppure il codice iniziale ha un bug che non avevi identificato 
inizialmente.
In una programmazione non ad oggetti dovresti andare in tutti i programmi e 
in tutti i form dove c'e' tale codice ed apportare le dovute modifiche. In 
una programmazione ad oggetti ti bastera' modificare l'oggetto "Miotextbox" 
una volta sola e tutti i programmi e form che lo utlizzano beneficeranno 
automaticamente della modifica.(in realta' ci sono alcune complessita', ad 
esempio i conflitti di versione, che ora tralascio)
Spero di esserti stato utile.
Ciao 

 ogni programma.
Tutte cose giuste, ma VB6 non è un vero e proprio linguaggio orientato 
agli oggetti, direi che possiede una certa dose di incapsulamento ma è 
decisamente carente nei concetti di ereditarietà e polimorfismo.
Purtroppo temo non basti poter costruire i propri "oggetti" per definire 
un linguaggio orientato agli oggetti.
ciao
stefano

 un linguaggio orientato agli oggetti.
sono d'accordo su tutto, ma la domanda non era "VB6 E' AD CONSIDERABILE 
OBJECT ORIENTED?" ma bensi' "SONO CONFUSO, COME POSSO CAPIRE E COMINCIARE AD 
AVERE CONFIDENZA CON GLI OGGETTI?"
E io ho dato una risposta il piu' semplice possibile per aprire la mente ad 
una persona confusa che si trova al primo appoccio con tali tematiche, di 
conseguenza ho evitato argomenti come l'ereditarieta' o il polimorfismo, che 
sono importanti ma possono generare un ulteriore di confusione ad una 
persona al primo approccio.
Ad esempio si potrebbe aggiungere che la delga e' un sistema utilizzabile 
per soccombere in parte alla mancanza dell'ereditarieta', ma questo 
ovviamente non farebbe altro confondere ulteriormente Wiston.
Comunque si', concordo, vb6 e' ok per sviluppare ottime applicazioni, ma non 
e' decisamente object oriented, direi che e' solamente object based 
pittosto.
Ciao 

 E io ho dato una risposta il piu' semplice possibile per aprire la mente ad 
[CUT]
Non volevo farti una critica, se ho dato quest'impressione mi dispiace.
Volevo semplicemente puntualizzare un concetto, dato che mi sembrava che 
il nostro amico mischiasse un po' il concetto di programmazione ad 
oggetti con gli oggetti (o componenti) presenti nel linguaggio
infatti dice:
"ma vorrei sfruttare la cosa come  un bell'esercizio di VB6 e 
soprattutto vorrei provare a programmare ad oggetti"
cmq, nessun problema, ci mancherebbe :-)
ciao
stefano


Comincia a impostare uno scheletro cosi':
Piu' sopra hai indicato alcuni elementi della tua applicazione; il
"fornitore" e l'"acquisto" e il "prodotto" acquistato
Quello che ti interessa conoscere del fornitore l'avrai certamente
gia' individuato quando hai disegnato il DB, quindi comincia a
modellare una classe aggiungendo le proprieta' minime.
Fai la stessa cosa per l'acquisto e prodotto, per ora solo le cose
piu' banali che puoi trattare con tipi di dato semplice (date,
descrizioni, importo ecc..)
Arrivato qui ti renderai conto che, come avviene per le tabelle, gli
oggetti sono relazionati; per esempio nella classe Acquisto ti
servira' il riferimento al fornitore, aggiungi una unlteriore
proprieta' di tipo Fornitore, ovvero l'altra classe che hai creato;
allo stesso modo avrai bisogno dei prodotti, e dato che qui parliamo
al plurale in questo caso ti serve non un valore ma una lista, un
insieme, aggiungi quindi una proprieta' di tipo Collection, dove ogni
elemento conterra' un'istanza della classe Prodotto
Ora prendi le funzioni con cui normalmente aggiorni queste
informazioni; per esempio l'inserimento di un nuovo fornitore, e prova
a sposta il codice all'interno di un metodo della classe Fornitore;
probabilmenbte dovrai adattarlo per fare in modo che prenda in
considerazione per quanto possibile soltanto membri appartenenti a
questa classe, e non oggetti esterni (per esempio controlli
dell'interfaccia, variabili globali ecc ecc.)
Prova anche con l'inserimento dell'acquisto, che in questo caso dovra'
riferirsi ai membri dell'oggetto stesso e degli oggetti figli che
contiene (fornitore, prodotti)
Infine crea una ulteriore classe che fa da punto di ingresso (potresti
chiamarla Factory, oppure Main, o BaseArchivio, vedi tu) la quale
avra' i metodi per eseguire le query con le ricerche di partenza
(dammi tutti i Fornitori, tutti gli Acquisti a partire da uno o piu'
parametri ecc.), queste funzioni internamente leggeranno dal DB,
istanzieranno gli oggetti corrispondenti caricando i dati dai tuoi
dataset alle ispettive proprieta' e restituiranno Collection o oggetti
singoli a seconda del caso
La conseguenza di tutto cio' e' che la tua interfaccia grafica avra'
sempre meno bisogno di riferirsi direttamente agli oggetti del DB, e
sempre piu' invece di riferirsi ai tuoi, e quindi anche quella andra'
adattata secondo necessita'
In tutte queste fase non necessariamente ti deve uscire fuori codice
gia' funzionante, e' giusto uno spunto che ti serve per capire come
potresti strutturare la cosa

 cmq, nessun problema, ci mancherebbe :-)
idem...
Ciao