Existe-t-il un modèle de conception pour gérer de profondes relations plusieurs-à-plusieurs?

J'ai du mal à définir ce modèle de données que j'ai rencontré en travaillant sur plusieurs applications.

Cela consiste en:

1. Un type d'objet composé de nombreux objets lui-même
2. Un deuxième type d'objet, où chaque instance «a plusieurs» du premier objet
3. Et, chacun des sous-objets du premier objet est modifiable pour chaque association au deuxième type d'objet.

Un exemple simple pourrait être:

1. Un cours de programmation composé d'un ensemble de leçons
2. Les leçons sont composées d'un ensemble de devoirs.
3. Un cours peut être attribué à un étudiant.
4. Cependant, une fois qu'un cours est attribué à un étudiant, chaque leçon et / ou devoir peut être personnalisé pour cet étudiant, avec des suppressions et des ajouts, au point où le cours d'origine peut être méconnaissable.

Dans mes solutions, cela se traduit par:

Lors de l'attribution d'un cours à un étudiant, le cours est chargé en mémoire. Ensuite, pour chaque sous-objet, un objet de relation élève / sous-objet est généré avec les métadonnées appropriées. Essentiellement, j'utilise l'objet d'origine comme modèle pour générer les objets personnalisables requis.

Il en résulte une énorme quantité de données à mesure que les sous-objets deviennent plus complexes et numérotés. Je me demande s'il y a une optimisation ou un modèle pour réduire la quantité de logique / complexité requise pour manipuler ce modèle de données.

Je vois quelques options en fonction de ce dont vous avez besoin: (1) s'il existe de nombreuses instances uniques qui suivent un algorithme commun, (2) s'il existe de nombreux objets similaires ou si vous générez des objets au moment de l'exécution, et (3) si vous souhaitez modifier dynamiquement le comportement de l'objet lors de l'exécution. Remarque: vous pouvez combiner tous les modèles que je mentionne ici, si nécessaire.

1. Si chaque "deuxième type d'objet" est unique mais suit un modèle de comportement similaire, vous pouvez utiliser le modèle de modèle . Il semble que vous fassiez cela. Mais pour le rendre explicite, votre classe de base abstraite a un algorithme général programmé; certaines étapes de cet algorithme sont implémentées dans les classes dérivées.

2. Si vous créez de nombreux objets ou si la création d'objets au moment de l'exécution est importante pour vous, vous pouvez utiliser Factory Pattern .

3. Et si vous souhaitez modifier dynamiquement le comportement, le modèle de stratégie peut fonctionner. Par exemple, si un étudiant dans un programme régulier est décidé pour des besoins spéciaux ou pour suivre un programme accéléré. Cela fonctionne en composant «l'étudiant» d'un objet qui représenterait une classe de base du programme. Le programme serait attribué à un programme dérivé lors de la construction de l'étudiant (cela semble étrange) et pourrait être réaffecté à un autre programme dérivé plus tard.

(Juste pour info, si vous utilisez (3) Strategy Pattern avec C ++, vous devrez Rvalues ​​pour la composition.)

Pour stocker vos objets et vos seconds objets, il peut être utile d'envisager le modèle d'itérateur (pour les parcourir, les ajouter, les supprimer, les trier, etc.).

Une bonne référence est Head First Design Patterns , qui couvre les modèles que je mentionne et leur mise en œuvre. Ils travaillent en Java.

J'ai du mal à croire, sous la présence d'un magasin de données ou d'une persistance, que vous auriez besoin d'avoir des objets avec ce type de profondeur à un moment donné dans un run-time. Est-ce pour les GUI CRUD? Si oui, je suggérerais de changer votre approche dès le départ. C'EST À DIRE:

Identifiez la sous-structure nécessaire pour que l'étudiant affiche, et stockez avec état son index d'origine dans la base de données, et mettez-le à jour sans état , en allant vers ou depuis la vue et la base de données principale.

Un cours personnalisé pour chaque étudiant au point où le cours d'origine est méconnaissable suggère que le cours d'origine est simplement une référence «par défaut». Ce que je ferais, c'est créer une classe appelée CustomizedCourse (ou une liste d'entre eux) et avoir cela (ou une liste de cela) comme propriété d'un étudiant. Le cours personnalisé peut avoir une référence au cours d'origine pour une utilisation «référentielle», mais le travail et les données principaux se trouveraient dans le cours personnalisé lui-même.