Существует ли шаблон проектирования для управления глубокими отношениями «многие ко многим»?

У меня проблемы с определением шаблона данных, с которым я столкнулся, работая над несколькими приложениями.

Это состоит из:

1. Тип объекта, который состоит из множества объектов.
2. Второй тип объекта, где каждый экземпляр имеет «много» первого объекта
3. И каждый из подобъектов первого объекта является модифицируемым для каждой ассоциации со вторым типом объекта.

Простой пример может быть:

1. Курс программирования, состоящий из набора уроков
2. Уроки состоят из набора заданий.
3. Курс может быть назначен студенту.
4. Однако после того, как курс назначен студенту, каждый урок и / или задание могут быть адаптированы для этого студента с удалениями и добавлениями до такой степени, что первоначальный курс может быть неузнаваем.

В моих решениях это приводит к следующему:

При назначении курса студенту курс загружается в память. Затем для каждого подобъекта генерируется объект отношения ученик / подобъект с соответствующими метаданными. По сути, я использую исходный объект в качестве шаблона для создания необходимых настраиваемых объектов.

Это приводит к огромному количеству данных, поскольку подобъекты становятся более сложными и пронумерованными. Мне интересно, есть ли какая-то оптимизация или шаблон, чтобы уменьшить количество логики / сложности, необходимых для манипулирования этим шаблоном данных.

Я вижу несколько вариантов в зависимости от того, что вам нужно: (1) если есть много уникальных экземпляров, которые следуют общему алгоритму, (2) если есть много похожих объектов или вы будете генерировать объекты во время выполнения, и (3) если Вы хотите динамически изменять поведение объекта во время работы. Примечание: при необходимости вы можете объединить все шаблоны, которые я здесь упомянул.

1. Если каждый «второй тип объекта» уникален, но следует сходному шаблону поведения, вы можете использовать Шаблон шаблона . Похоже, вы делаете это. Но чтобы сделать это явным, ваш абстрактный базовый класс запрограммировал общий алгоритм; определенные шаги этого алгоритма реализованы в производных классах.

2. Если вы создадите много объектов или если создание объектов во время выполнения важно для вас, вы можете использовать Factory Pattern .

3. И если вы хотите динамически изменить поведение, Stategy Pattern может сработать. Например, если учащийся в обычной учебной программе решает, что у него особые потребности или он должен пройти ускоренную программу. Это работает путем составления «ученика» объекта, который представлял бы базовый класс учебного плана. Учебный план будет приписан производному учебному плану при создании ученика (это звучит странно) и может быть переназначен другому производному учебному плану позже.

(Просто к сведению, если вы используете (3) шаблон стратегии с C ++, вам понадобится Rvalues ​​для композиции.)

Чтобы хранить ваши объекты и вторые объекты, возможно, стоит рассмотреть шаблон итератора (циклически проходить по ним, добавлять, удалять, сортировать и т. Д.).

Хорошим справочником является Head First Design Patterns , который охватывает шаблоны, которые я упомянул, и их реализацию. Они работают на Java.

Мне трудно поверить, что при наличии хранилища данных или постоянства вам понадобятся объекты с такой глубиной в любой заданный момент времени выполнения. Это для CRUD GUI? Если так, то я бы предложил изменить ваш подход с самого начала. IE:

Определить подструктуры , необходимые для студента , чтобы показать, и statefully хранить его указательное происхождение обратно в БД, и statelessly обновления , что происходит или с точки зрения и серверной БД.

Индивидуальный курс для каждого учащегося до такой степени, что первоначальный курс до неузнаваемости предполагает, что исходный курс - это просто «ссылка по умолчанию». Я хотел бы создать класс CustomizedCourse (или список их) и иметь его (или список) в качестве свойства студента. CustomizedCourse может иметь ссылку на исходный курс для «ссылочного» использования, но основная работа и данные будут в самом CustomizedCourse.