Newsgroup: it.comp.dotnet
Titolo: Parametri "ricorsivi" classi

Salve a tutti, sto progettando delle classi, e volevo sapere se un legame
doppio di questo tipo può dar problemi o è "deprecato".
 
Public Class Cliente
 
   Public Class ClienteNote
      Cliente as Cliente
      Descrizione as string
      Data as date
   End Class
 
   Property Cognome as String
   ....
   Property Note as ClienteNote
EndIf
 
In pratica nelle note risalgo all'oggetto cliente, e viceversa.
 
 
Grazie a tutti

 doppio di questo tipo può dar problemi o è "deprecato".
No, stai solo stabilendo una relazione one-to-one tra le entità...
one question: perchè hai messo ClienteNote come sotto-classe pubblica di
cliente?
 
Ciao.

 In pratica nelle note risalgo
 
risali in che modo ? Passi dei parametri in esplicito alle 
funzioni, o riferimenti al container ?
Nel senso, da dentro la innermost class, come accedi alle 
variabili DI ISTANZA della outermost ?
Poi non so se sia deprecato o meno ... quantomeno mi pare 
rischiosissimo per uan ragione :
siccome la classe è public, se ha ANCHE un costruttore 
pubblico (se non lo ha, come non detto), in teoria potresti 
istanziarla da fuori. A quel punto dovresti aggiungere dei 
flag interni per capire come tale classe (ClienteNote) è 
stata istanziata : se risiede o meno dentro un oggetto 
CLiente, e stare attento che una istanza indipendente non 
cerchi di accedere a variabili di istanza di un contenitore 
che non ha.
Se proprio non ti serve per altri scopi, considererei di 
dichiararla private, oppure dichiarare friend tutti i suoi 
costruttori (friend del container), di modo che possa essere 
istanziata solo dal container stesso, che deve poterlo fare 
contenendone una.
ciao
Soviet


 cliente?
 
Per quel che si intuisce dall'esempio, concordo che non dovrebbe essere una 
nested class:  ClienteNote rappresenta un aggregato di proprieta' di 
Cliente, la best practice per le nested class e' di usarle per incapsulare 
logica non pubblica.
 
-LV
 
 

 ClienteNote rappresenta un aggregato di proprieta' di Cliente
 
Ripensandoci, visto che la classe si chiama ClienteNote, al plurale, magari 
qualcosa non torna?
 
-LV
 
 

 stare attenti a non creare loop infiniti
 
In .NET, nello specifico, i riferimenti circolari non esistono.

 cliente?
 
L'esempio reale rappresenta una tabella clienti, e due tabelle correlate
(contatti e un'altra), in relazione 1:1.
 
Nella "mappatura" manuale avevo separato in classi fatte allo stesso modo.
Il fatto di riportare il cliente dentro la classe mi veniva comodo per
validarne la FK del db, e comunque di avere a disposizione del cliente in
una possibile futura ruotine, o comunque far si che da qualche parte la
classe ClienteContatto potesse anche vivere di vita propria (il suo metodo
Save ecc.)

 logica non pubblica.
 
Il mio intento era di far si che la classe ClienteNote (o ClienteContatti)
potesse vivere anche di vita propria.
Nel mio esempio, al metodo Save di un cliente la classe cliente va anche ad
invocare i metodi Save delle due classi correlate.
 
Allo stato attuale non c'è una necessità che queste classi siano
utilizzabili anche singolarmente e fuori dal contesto del cliente. In tal
caso sarebbe meglio far diversamente?

 che non ha.
 
A me per far funzionare quella classe mi serve che la proprietà
Cliente.Codice sia stata valorizzata, questo per l'unico metodo "salva" che
ora implementa la classe.
Il mio era più un discorso per capire come mappare a livello di classi una
struttura su db del tipo
Tab. CLIENTE, Tab. CLIENTEContatto, Tab CLIENTENote
tutte in relazione 1:1
 
Semplicemente a livello di logica del db ho separato i campi del cliente in
più tabelle, lasciando nella tabella principale solo i dati appunto
principali.
 
Però mi sembrava utile la possibilità di avere le classi più autonome,
anche se non c'è una necessità reale in questo specifico caso.

 wrote in message 
news:jikjhi$vi9$1...@dont-email.me...

Se intendi i riferimenti circolari fra i progetti, non e' solo in .Net che 
non sono consentiti:  ma non vedo il nesso con il problema presente.  In 
generale, "riferimento circolare" e' un termine che indica semplicemente 
situazioni del tipo A->B->...->C, dove A, B, C sono componenti a qualunque 
livello di strazione.  Ma se e' altro che intendevi, magari prova a 
spiegare...
 
-LV
 
 

 caso sarebbe meglio far diversamente?
 
Assunto che lo scenario e' una classe "master" e una o piu' classi collegate 
che ne aggregano alcuni attributi:
 
La prima cosa che noterei e' che, in generale, la struttura delle classi non 
deve corrispondere strettamente alla struttura dei dati:  magari nel db hai 
tabelle separate per un po' di denormalizzazione e gestione piu' efficiente 
dei dati e dei pattern di accesso ai dati;  al livello di classi/oggetti le 
esigenze sono piuttosto diverse e la struttura puo' e spesso deve essere 
diversa.
 
Assumendo che classi separata sia la strada da percorrere, allora anch'io 
penso che cose tipo il costruttore e il metodo Save dovrebbero essere 
friend, ovvero che sia la classe "master" e solo quella ad esporre 
un'interfaccia per la gestione del ciclo di vita dell'entita' 
corrispondente.
 
Comunque a questo livello non esistono regole scritte con il fuoco, solo 
indicazioni di massima...
 
-LV
 
 

 componenti a qualunque livello di [a]strazione.
 
Pardon, ovviamente intendevo A->B->...->A, dove A, B, ecc. sono...
 
-LV
 
 

 i riferimenti circolari in un grafo di oggetti
 
Ho solo puntualizzato che in ambiente .NET è un problema superato perché
il GC è sempre in grado di risolverli.

 corrispondente.
Cioè metti il metodo che persiste l'istanza come messaggio dell'istanza
stessa? (per essere più chiaro, progetti cliente in modo che puoi
invocare il metodo Cliente.Save che persiste l'istanza, per esempio, su db?)

 corrispondente.
 
Quindi il metodo Save interno solo alla classe master, per il resto tutto
invisibile?
 
Io pensavo nell'ottica che se avrò un utente che mi può modificare un
sottogruppo di dati, salva solo i suoi senza salvare tutto il cliente (dove
magari non ha diritti nemmeno per leggere informazioni o modificare).
Per questo avere il salvataggio della tabella correlata disponibile
singolarmente.
 
Il mio comunque era anche un discorso teorico, come avrete capito
l'esperienza non è moltissima.

 l'esperienza non è moltissima.
 
Ovviamente intanto vi ringrazio :)

 il GC è sempre in grado di risolverli.
 
Spero sopra di aver a questo punto chiarito, altrimenti davvero vuol dire 
che mi spiego malissimo (altrimenti il problema sei tu che hai deciso di 
contraddirmi a tutti i costi).  In particolare, anche GC e problematiche 
connesse mi pare abbiano zero a che fare con il quesito presente.
 
-LV
 
 

 db?)
 
Se intendi che all'invocazione di Cliente.Save, Cliente.Save a sua volta 
invoca ClienteNote.Save (che e' friend), si', e' quello che suggerivo, come 
base di partenza.
 
-LV
 
 

 singolarmente.
 
Va bene anche, ovviamente sono i requisiti che devono guidare.  Il setup che 
ti suggerivo e' quello base, ma certamente puoi rendere anche il 
ClienteNote.Save pubblico (e magari anche qualcos'altro, non saprei...).  A 
quel punto pero' penso che ti sorgera' l'esigenza di un po' di logica di 
controllo incrociato, ma, di nuovo, sono i requisiti che guidano, per cui 
non posso essere piu' dettagliato di cosi'...  In generale l'unica 
indicazione e' quella di chiarirsi le idee su come le classi idealmente 
dovrebbero usate, e poi disegnare e implementare di conseguenza.
 
-LV
 
 

 a tutti i costi)
 
??? non c'è niente di personale, esprimo solo il mio parere, in maniera,
mi pare, più che tranquilla.
 
 

 mi pare, più che tranquilla.
 
OK, mi era sembrato, ma tutto e' bene quello che finisce bene.
 
-LV
 
 

 Penso che semplicemente stai prendendo un abbaglio:
Io invece penso che l'abbaglio lo stai prendendo tu... ma non è
importante, può andar bene così.
 
Comunque no problem (niente di personale ;-) ).
 
Ciao,
Pasquale.

 Comunque no problem (niente di personale ;-) ).
 
Sei un imbecille e un ipocrita.
 
Passo e chiudo.
 
-LV
 
 

 Sei un imbecille e un ipocrita.
ti commenti da solo... sei ridicolmente insicuro.
 
Passo e chiudo.

"pasquale [:dedalus]"  wrote in message news:jiq5n6$lm0$1...@dont-email.me...

Sono 25 anni che faccio questo mestiere, e almeno 15 che bazzico i 
newsgroup:  i tuoi attacchi personali mi fanno un baffo, e che sei un altro 
dei tanti ipocriti imbecilli non e' ridicolo ma neanche sconvolgente.
 
Baciami i coglioni, dedalus Pasquale.
 
-LV
 

 i tuoi attacchi personali mi fanno un baffo
 
i miei attacchi personali... dove, quando? Oppure sei così abituato
all'auto-referenzialità da andare in bambola appena uno dice qualcosa di
contrario alle tue idee? Da come reagisci, non si direbbe che hai tutta
questa esperienza... e comunque, se vuoi, ti mando l'indirizzo di un
medico bravo...
 
ps: non ho più intenzione di proseguire oltre in questa discussione;
ti lascio così il tempo per studiarti qualcosa di utile! Sei un
grandissimo LV... miticoooooooooooooooo

 grandissimo LV... miticoooooooooooooooo
 
E tu sei un'altro dei tanti aspiranti venditori di videoregistratori col 
mattone dentro:  mitico...
 
-LV