Il modo migliore per gestire la relazione di classe

Immagino che tu stia solo memorizzando i profili per gli utenti.

Questa è una decisione facile. L'utente ha una relazione "ha una" con il profilo e quindi il profilo dovrebbe essere incapsulato nella propria classe ed esposto come componente della classe User (ad esempio una proprietà). Quindi il tuo secondo approccio è quello più pulito.

L'opzione 1 viola il principio della responsabilità unica. Questa è solo un'opzione se ci sono pochi dati raccolti nei profili e quasi nessun comportamento.

L'opzione 2 è la strada da percorrere.

L'opzione 3 è troppo complessa. Inoltre viola il principio di responsabilità individuale.

L'opzione 4 suona come un orribile design. Sarà soggetto a errori e non è orientato agli oggetti. Perché vorresti intersecarli tramite ID? Questo è interamente basato su un effetto collaterale (ovvero l'ID corrispondente del profilo e dell'utente). Avrai comunque bisogno di una sorta di riferimento da utente a profilo. Quindi, perché non avere quel riferimento in una proprietà e lasciare che un ORM lo mappi (vedi Opzione 2)?

It would be most useful to capture ther more abstract case of such a profile than the specifics of a financial protfolio - or so it seems to me. The doctor and the financial advisor both need your personal data (profile) to have the best chance to do the right thing.

È sempre possibile estendere da Profile-BaseClass e memorizzarlo in User-Aggregate. E se non vuoi essere dipendente dall'implementazione, crea un'interfaccia di base per tutto ciò che ti serve da tutti i casi di profili che puoi immaginare.

Write the code for the profile into the User class. I am dismissing this right away.

Perché? Questa è la soluzione più semplice. Lo farei fino alla comparsa del dolore. Quel momento potrebbe arrivare molto presto. Quindi cosa succede se lo fa? Basta estrarre i dati del profilo in una classe separata.

Anche se sembrerebbe che l'opzione 2 sia la risposta sensata, tutto dipende dal contesto. Gli oggetti non sono principalmente per il mantenimento dei dati, ma per il comportamento di modellazione. Ciò significa che per rispondere correttamente alla domanda dobbiamo sapere molto di più su quale comportamento il sistema dovrebbe supportare. Ad esempio, potrebbe essere che il Profilo sia in realtà il concetto più importante di questo sistema e che l'utente debba esserne impiccato. O forse non dovrebbe esserci nemmeno una classe Profile (o una classe User), ma alcune altre classi basate su quali azioni l'utente deve eseguire.

Quindi la risposta è: non c'è risposta!

1.Write the code for the profile into the User class. I am dismissing this right away.

Elimina il principio Single Responsibility . Ogni classe dovrebbe fornire un'unica responsabilità.

2.Create a Profile class and make it a property of the User class.

Sembra l'opzione migliore per due motivi.

1.soddisfies Principio della singola responsabilità.

2.queste due classi sono accoppiate liberamente .

3.Write a User class (with the boiler-plate name, address stuff), write a Profile class, and write a UserProfile class - UserProfile is the union of User and Profile.

Questa non è una buona opzione perché User e UserProfile, Profile e UserProfile sono strettamente accoppiati. L'accoppiamento stretto non è un buon progetto.

4.Write a User class and a Profile class that each have an ID property and let the ID act as the intersection. This way the User and Profile are independent and another class, possibly an abstract class with nothing but static methods handles the logic that describes the connection.

questo è molto complesso, sento strongmente che questa complessità non è richiesta.

infine potresti voler leggere Headfirst Object Oriented analysis and design