Parametri "ricorsivi" classi

[Andrea [Work]]

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

[pasquale [:dedalus]]

On 28/02/2012 16:00, Andrea [Work] wrote:
> Salve a tutti, sto progettando delle classi, e volevo sapere se un legame
> 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.

[Soviet_Mario]

Il 28/02/2012 16:00, Andrea [Work] ha scritto:
> 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

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

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> wrote in message
news:jiiqtu$fob$1...@dont-email.me...

> On 28/02/2012 16:00, Andrea [Work] wrote:

>> Salve a tutti, sto progettando delle classi, e volevo sapere se un legame
>> doppio di questo tipo può dar problemi o è "deprecato".

> No, stai solo stabilendo una relazione one-to-one tra le entità...

Concordo sulla relazione 1-a-1, anche se non necessariamente viene
implementata in entrambe le direzioni. In generale, con i riferimenti
circolari in un grafo di oggetti occorre stare attenti a non creare loop
infiniti. Ma il caso di cui sopra, anche se la relazione e' circolare, e'
molto semplice, al punto che non penso ci siano particolari avvertenze
d'uso: al limite, per esempio, il rilascio delle risorse converrebbe
centralizzarlo nella classe "master", e cose simili, nel senso che a crearsi
dei problemi li' bisogna farlo apposta. (Per quel che si intuisce
dall'esempio.)

> one question: perchè hai messo ClienteNote come sotto-classe pubblica di
> 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

[LudovicoVan]

"LudovicoVan" <ju...@diegidio.name> wrote in message
news:jik1j7$p3i$1...@speranza.aioe.org...

> "pasquale [:dedalus]" <eurya...@gmail.com> wrote in message
> news:jiiqtu$fob$1...@dont-email.me...
>> On 28/02/2012 16:00, Andrea [Work] wrote:
>
>>> Salve a tutti, sto progettando delle classi, e volevo sapere se un
>>> legame
>>> doppio di questo tipo può dar problemi o è "deprecato".
>
>> No, stai solo stabilendo una relazione one-to-one tra le entità...
>
> Concordo sulla relazione 1-a-1

<snip>

> ClienteNote rappresenta un aggregato di proprieta' di Cliente

Ripensandoci, visto che la classe si chiama ClienteNote, al plurale, magari
qualcosa non torna?

-LV

[pasquale [:dedalus]]

On 29/02/2012 03:12, LudovicoVan wrote:
> In generale, con i riferimenti circolari in un grafo di oggetti occorre
> stare attenti a non creare loop infiniti

In .NET, nello specifico, i riferimenti circolari non esistono.

[Andrea [Work]]

Il Tue, 28 Feb 2012 16:11:23 +0100, pasquale [:dedalus] ha scritto:

>> Salve a tutti, sto progettando delle classi, e volevo sapere se un legame
>> 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?

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.)

[Andrea [Work]]

Il Wed, 29 Feb 2012 02:12:50 -0000, LudovicoVan ha scritto:

>> one question: perchè hai messo ClienteNote come sotto-classe pubblica di
>> 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.

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?

[Andrea [Work]]

Il Tue, 28 Feb 2012 16:53:45 +0100, Soviet_Mario ha scritto:

> 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.

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.

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> 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

[LudovicoVan]

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in message
news:1jr19nx64k17q.2n3c3w6vq0kf$.dlg@40tude.net...

> Il Wed, 29 Feb 2012 02:12:50 -0000, LudovicoVan ha scritto:
>
>>> one question: perchè hai messo ClienteNote come sotto-classe pubblica di
>>> 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.
>
> 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.

Quelle due affermazioni suonano contraddittorie: o la classe "vive di vita
propria", o il suo ciclo di vita e' controllato dalla classe "master".

> 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?

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

[LudovicoVan]

"LudovicoVan" <ju...@diegidio.name> wrote in message

news:jim75q$4fm$1...@speranza.aioe.org...

> 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 [a]strazione.

Pardon, ovviamente intendevo A->B->...->A, dove A, B, ecc. sono...

-LV

[pasquale [:dedalus]]

On 29/02/2012 23:00, LudovicoVan wrote:
> Se intendi i riferimenti circolari fra i progetti

No intendo i riferimenti circolari tra oggetti, anzi per essere più
preciso intendo quello che hai detto tu

> 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.

[pasquale [:dedalus]]

On 29/02/2012 23:09, LudovicoVan wrote:
> 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.

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?)

[Andrea [Work]]

Il Wed, 29 Feb 2012 22:09:24 -0000, LudovicoVan ha scritto:

> 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.

Esattamente, nel mio caso devo avere diversi record, quindi nella tabella
principale ho messo solo i dati base, per avere meno campi possibili e
tutto più snello.

> 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.

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.

[Andrea [Work]]

Il Thu, 1 Mar 2012 11:52:34 +0100, Andrea [Work] ha scritto:

> Il mio comunque era anche un discorso teorico, come avrete capito
> l'esperienza non è moltissima.

Ovviamente intanto vi ringrazio :)

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> wrote in message

news:jin8co$d42$1...@dont-email.me...

> On 29/02/2012 23:00, LudovicoVan wrote:

>> Se intendi i riferimenti circolari fra i progetti
>
> No intendo i riferimenti circolari tra oggetti, anzi per essere più
> preciso intendo quello che hai detto tu

Precisione per precisione, quello semmai e' cio' che tu pensi che io abbia
detto.

>> i riferimenti circolari in un grafo di oggetti

Di nuovo: hai un "riferimento circolare" ogni volta che A->B->...->A, cioe'
si tratta di un concetto generale. Dopodiche' i problemi a cui alludevo
sono problemi di logica, cioe' del codice che uno scrive: mi riferivo ad
algoritmi di ricerca et similia, user code, il codice che uno scrive, non mi
riferivo a niente del dietro le quinte.

> Ho solo puntualizzato che in ambiente .NET è un problema superato perché
> 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

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> wrote in message

news:jin8i7$e33$1...@dont-email.me...

> On 29/02/2012 23:09, LudovicoVan wrote:
>> 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.
> Cioè metti il metodo che persiste l'istanza come messaggio dell'istanza
> stessa?

Quale istanza, qui in questione ne abbiamo due di classi.

> (per essere più chiaro, progetti cliente in modo che puoi
> invocare il metodo Cliente.Save che persiste l'istanza, per esempio, su
> 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

[LudovicoVan]

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in message

news:s6b1133srg0u.8...@40tude.net...

> 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.

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

[pasquale [:dedalus]]

On 01/03/2012 14:42, LudovicoVan wrote:
> 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.

penso che questo debba essere considerato un approccio deprecato (anche
come base di partenza) per via del fatto che la classe cliente dovrebbe
ignorare i dettagli del dominio di persistenza... ma è una mia opinione...

> altrimenti il problema sei tu che hai deciso di contraddirmi
> a tutti i costi)

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

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> wrote in message

news:jio04f$7ai$1...@dont-email.me...

> On 01/03/2012 14:42, LudovicoVan wrote:

>> 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.
>
> penso che questo debba essere considerato un approccio deprecato (anche
> come base di partenza) per via del fatto che la classe cliente dovrebbe
> ignorare i dettagli del dominio di persistenza... ma è una mia opinione...

Penso che semplicemente stai prendendo un abbaglio: qui eravamo interessati
ai flussi di cio' che succede a monte, non di cio' che succede a valle. In
particolare, il "dominio di persistenza" e' un'altra cosa che ha poco o
nulla a che fare con il quesito presente... Ma e' una mia opinione...

>> altrimenti il problema sei tu che hai deciso di contraddirmi
>> a tutti i costi)
>
> ??? non c'è niente di personale, esprimo solo il mio parere, in maniera,
> mi pare, più che tranquilla.

OK, mi era sembrato, ma tutto e' bene quello che finisce bene.

-LV

[pasquale [:dedalus]]

On 01/03/2012 20:39, LudovicoVan wrote:
> 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.

[LudovicoVan]

"pasquale [:dedalus]" <eurya...@gmail.com> wrote in message

news:jiptv8$i4c$1...@dont-email.me...

> On 01/03/2012 20:39, LudovicoVan wrote:

>> Penso che semplicemente stai prendendo un abbaglio:
>
> Io invece penso che l'abbaglio lo stai prendendo tu... ma non è
> importante, può andar bene così.

Gia', con la differenza che le tue motivazioni sono a dir poco
inconsistenti.

> Comunque no problem (niente di personale ;-) ).

Sei un imbecille e un ipocrita.

Passo e chiudo.

-LV

[pasquale [:dedalus]]

On 02/03/2012 10:38, LudovicoVan wrote:
> Sei un imbecille e un ipocrita.

ti commenti da solo... sei ridicolmente insicuro.

Passo e chiudo.

[LudovicoVan]

"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

[pasquale [:dedalus]]

On 02/03/2012 11:51, LudovicoVan wrote:
> 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

[LudovicoVan]

"pasquale [:dedalus]" wrote in message news:jiq9bj$823$1...@dont-email.me...

> On 02/03/2012 11:51, LudovicoVan wrote:

> > 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...

Baciami i coglioni, dedalus Pasquale, e il medico tienitelo per i tuoi
post-sbornia.

> 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

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

-LV