Newsgroup: it.comp.lang.visual-basic
Titolo: Simulazione dei costruttori di classe: ripasso. (come stassi ancora al liceo)


Il fatto è che a me tale codice non pare sia un vero e proprio metodo
costruttore quanto piuttosto un *puntatore* ad un metodo costruttore.
Infatti nel testo è definita la seg. funzione, vero metodo pseudocostruttore
(d'esempio) nella classe d'esempio CPerson :
Friend Sub Init ( FirstName As String, LastName As String, Optional ID As
Variant, Optional BirthDate As Variant)
    Me.FirstName = FirstName
    Me.LastName = LastName
    If Not IsMissing(ID) Then Me.ID = ID
    If Not IsMissing(BirthDate) Me.BirthDate = BirthDate
End Function
Quindi io penso che nel modulo BAS vada messo del codice che istanzi una
nuova classe del tipo della classe che contiene la funzione, poi la si crei,
e si richiami la funzione Init, interna a CPerson, passandole dei parametri
dal modulo BAS, tramite la nuova classe istanziata. Ho capito bene? Tuttavia
tali parametri al modulo BAS come si passano? Ed il motivo pratico di un
approccio del genere quale è?
Scusate la lunghezza del post e non vogliatene male, ma le comunità virtuali
servono anche per questo, no?
Buon lavoro e good coding :)

 approccio del genere quale è?
Qui non capisco io, i parametri li passi semplicemente come parametri della
funzione...
L'intenzione pratica credo sia semplicemente questa: sostituire questo
codice
Dim Persona As CPerson
Set Persona = New CPerson
con questo, quasi equivalente dal punto "visivo"
Dim Persona As CPerson
Set Persona = New_CPerson("Luca", "Dormio", 123, "06/06/73")
che, se vogliamo, ti evita il fastidio di doverti ricordare del metodo .Init
tutte le volte che istanzi la classe; la controindicazione sono pero'
1) la classe resta comunque istanziabile con il solito 'New', cosa che
potrebbe generare confuzione
2) il programmatore deve comunque fare riferimento ad un ulteriore modulo
BAS da portarsi dietro insieme alle classi
IMHO un compromesso piu' pulito puo' essere quello di rendere le classi non
creabili e definire un'unica classe pubblica (tipo l'esempio sul "pool
manager") nella quale creare i metodi costruttori da usare per ottenere le
istanze delle classi figlie
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

Stassi come d'inverno su gli alberi le foglie?
Ciaotutti,
*

Stassi come d'inverno su gli alberi le foglie?
Si sta come
D'autunno
sugli alberi
le foglie
ahi ahi ahi... meno male che i cani di solito a quest'ora fanno il loro
riposino pomeridiano... :-PPP
Ciao,
Moreno
#sirri#@#
morenosoft.com#
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.msvbsite.net
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.it-lang-vb.net
---------------------------------------------------------------------------

BAS da portarsi dietro insieme alle classi
3) se la classe ha 50 proprietà, buon divertimento => livello di
comprensibilità prossimo allo 0, maiday! maiday!
Io a volte preferisco delegare la creazione del nuovo oggetto ad un
metodo di una classe che funge da interfaccia per il componente, il
quale espone l'oggetto stesso affinché il consumatore imposti
manualmente le proprietà. Poi un eventuale secondo metodo (update)
verifica che eventuali proprietà richieste siano state impostate ed
eventualmente lo aggiunge ad una eventuale collection. Tale oggetto è
pubblico ma non creabile, quindi la creazione spetta al componente e di
conseguenza non è possibile bypassare le regole di creazione e
validazione fissate dal componente stesso.
Questa comunque è solo un'alternativa e non sempre applicabile (dipende
da come hai strutturato il progetto), ma in ogni caso, indipendentemente
da come, chi istanzia, salva l'oggetto, preferisco esporlo piuttosto che
utilizzare un costruttore; ho detto "preferisco" e all'inizio "a volte"
poiché in talune circostanze tutto questo ambaradan non è necessario,
non porterebbe chissà che miglioramenti funzionali ed il costruttore si
rivela essere la scelta più veloce. Dipende sempre dalla struttura del
progetto, non c'è quasi mai un'unica strada...



Ops e' vero che era autunno :P
A me vien sempre inverno chissa' perche', cmq leggi il topic e capirai
l'origine del mio stassi :P
Ciaotutti,
*

l'origine del mio stassi :P
Ah... non c'ero arrivato, sorry... :-)


 degli altri programmatori. [...]
[cut]
Se il progetto in questione è quello di un semplice EXE il discorso è
analogo a quello sopra. Nulla impedisce di utilizzare la classe nel consueto
modo, e quindi senza richiamare il metodo New_CPerson e di conseguenza Init.
Questo è invece un metodo valido (anche se si tratta sempre di un
trucchetto) nel caso si tratti di un progetto Active-X (exe o dll) perché è
possibile impedire di creare la classe (Instancing = PublicNotCreatable), e
quindi rendere obbligatorio (per quanto sempre scomodo) l'utilizzo della
funzione New_clsPersona.
Ciao.

 utilizzare un costruttore;
Puoi spiegarmi cosa intendi esattamente e perchè?
Ciao e buon lavoro.

Puoi spiegarmi cosa intendi esattamente e perchè?
Intendo dire che non sempre puoi utilizzare questa strada, o comunque
non esattamente come te l'ho esposta:
- hai bisogno che appena istanzi l'oggetto siano già definite tutte le
proprietà -> come ghai detto tu, costruttore
- non puoi implementare in una classe un metodo che istanzi un oggetto
appartenente a se stessa, né puoi implementare nella stessa classe un
metodo che aggiunga un oggetto appartenente alla stessa classe ad una
collection: in questo caso i due metodi devono esser implementati ad un
livello superiore, come a esempio la classe collection.
- poi dipende se si tratta di un componente ActiveX o di un Exe, poiché
i consumatori sono diversi e di conseguenza non è sempre detto che puoi
esporre sempre tutti i metodi e tutte le proprietà dell'oggetto: ad
esempio quando vuoi creare un'oggetto Persona per poi semplicemente
memorizzarlo in un record di un db, una soluzione potrebbe esser quella
di invocare un metodo clsAnagrafica.NewPersona, che ti ritorna una
classe clsPersona, con tutte le proprietà (in sola letture) ed un metodo
Update che memorizza nel db i valori di tutti gli attributi. Però quando
vuoi leggere le info riguardanti quella (o un altra) persona, sarebbe
bene che il metodo Update non sia visibile e che tutte le proprietà
siano accessibili in sola lettura. Quindi in questo caso l'approcio è
diverso, la soluzione di prima non applicabile e devi vedere se vale la
pena utilizzare una nuova classe clsNewPersona con le prorietà in sola
scrittura ed il metodo Update, oppure, senza duplicare parte del codice,
utilizzare un'unica classe che eredita due interfacce diverse...
Comunque queste sono solo alcune ipotesi per dirti che la soluzione non
è una sola, ma ci sono molte alternative: non esiste un approcio, una
soluzione migliore, ma si sceglie sempre la "migliore del caso", ovvero
quella che in quel momento, in quesl contesto di quella det.
applicazione è la più conveniente.
Comunque pian pianino, con un po' di esperienza le scoprirai da te quali
sono, ne troverai di nuove quasi ad ogni applicazione: intanto impara
quello che dice il testo, ricordandoti però sempre che non è la Bibbia,
ma solo la spiegazione di una delle molteplici strade da seguire.


 Questo intendevo.
Più che difficile da leggere è una porcata immensa. Nel senso che secondo me
se devi fare un costruttore che prende in ingresso 50 parametri hai
sbagliato qualcosa a livello di progetto e di come hai pensato la classe
O usi il costruttore per applicare una serie di default a tutte le proprietà
non fondamentali o usi un qualche meccanismo di ereditarietà da una classe
istanziata già esistente che passi al costruttore, ma usare una cosa del
genere mi sembra veramente inutile, nel senso che preferisco un
Set Oggetto = New ClasseOggetto
With Oggetto
    .p1 = "aaaa"
    .p2 = "bbbb"
    ' eccetera eccetera eccetera
End With
Che sicuramente pesa di più ma viene più leggibile.
Saluti
Massimo

Che sicuramente pesa di più ma viene più leggibile.
Infatti, è quello che dicevo io.
Sul fatto che pesa di più non sono d'accordo... in che senso?
(mmm... come faccio a non essere d'accordo se non ho capito in che
senso?? Va beh, sono d'accordo... però in che senso? :-P)


 senso?? Va beh, sono d'accordo... però in che senso? :-P)
E comunque siamo entrambi d'accordo che un costruttore grosso fa schifo.
Quello che non capisco è perchè ci facciamo queste domande quando con VB i
costruttori non li abbiamo....
Saluti
Massimo

>Stassi come d'inverno su gli alberi le foglie?
Forse una rinorragia senza epi ...
hal.CorpusHippocraticum

di piů.
K, ora chiaro... concordo.


 ha scritto nel messaggio
news:ms2mrt0pv0igd77of...@4ax.com...
[cuttone]
ehmmm... Moreno... non so come la prenderete tu (da un verso) e
qualcun'altro (dall'opposto) ma...
"Sono perfettamente d'accordo con te e uso anch'io la stessa logica"...
...ecco l'ho detto... adesso ti ho "coccolato"...     ;-PPP
ciao
ugo