Легкая задачка по ООП для архитектора. Как поступить?

Question

[Alksar]

Дорогой мой, Архитектор, если ты потратишь 5 минут своего времени и взглянешь на этот пример, то будешь удачлив весь год, обещаю ;). p.s.: а так же я буду очень рад.

Дело в том, что у меня с трудом получается спроектировать структуру для приложения, но я все же сделал это, пока требования не изменились. Ниже я покажу самую краткую выжимку и скажу что поменялось..помоги!


Вроде как картинка не работает, если так, то вот ссылка на яндекс.диск -"https://yadi.sk/i/wo4vavo8g7iuT"

Была заданна задача, которая реализована в схеме выше:

Заказчик делает заказ(CustomerOrder). В заказ входит следующая информация: заказчик(customer), дата заказа(date), задача - которую необходимо выполнить (task), примечание к заказу (note).
Этот заказ, в общем случае, разделяют на "подзаказы" (EmployeeOrder), которые раздают сотрудникам. Эти "подзаказы" так же содержат date и task, а так же сотрудника, кто делает (employee).
Должна быть возможность добавления "подзаказов" к заказу, удаления.
Задача - Task - это один из множество классов наследующий общий интерфейс.

Все получилось может быть и криво, но рабочим.

Теперь появилось дополнительное требование - к одному из видов задач, а именно "InterpretationTask", нужно добавить возможность указывать сверхурочную работу по этому заказу. Сверхурочная работа представляет собой очередной вид задачи - "OverWorkInterpretationTask".
Но вот вопрос: Куда положить и как связать эту сверхурочную работу с основным заказом. Получается сверхурочная работа имеет предпосылки стать отдельным заказом - основана на отдельном OverWorkInterpretationTask, и должна обрабатываться в программе как отдельная единица, но так же она содержит много общего да и вообще строится на основе первичного заказа - заказчик тот же, дата та же, исполнитель тот же но task другая.

Архитектор, жду твоего отклика!

Comments

[Alksar]

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

Answer 1

[sim3x]

Заказчик:
   ...

ЗапросЗаказчика:
  заказчик = FK(Заказчик)  
  // заказчик = М2М(Заказчик) - если заказчики могут обьединяться для запроса
  текст_заказа = текст  // raw запрос
  ...

Проект:
  запрос_заказчика = М2М(ЗапросЗаказчика)
  // менеджер разбивает raw запрос на таски
  
ТипТаска:
  название = текст //  интерпритация, сверхурочность, обучение, 

Таск
  проект = FK(Проект)
  // а можно привязать напрямую к ЗапросЗаказчика и убрать сушность Проект
  // проект = FK(ЗапросЗаказчика)
  тип_таска = М2М(ТипТаска) // сверурочное обучение
  исполнитель = FK(исполнитель)
  ...

Исполнитель:
  ...

Comments

[Alksar]

Спасибо за сверхзвуковую реакцию! Поясните, пож, что тут значат FK и M2M? На ум для FK приходит foreign key, это не из той оперы?)

[sim3x]

Alksar: many to many; foreign key

[Alksar]

получается в Вашем примере каждый "Таск" знает какому ЗапросуЗаказчика он пренадлежит, а надо, чтобы каждый ЗапросЗаказчика знал из каких Тасков он состоит

[sim3x]

Alksar: связь двунаправлена
FK тут для того чтоб можно было повесить на ЗапросЗаказчика несколько тасков

[Alksar]

sim3x: "тип_таска = М2М(ТипТаска) // сверурочное обучение". Это не опечатка? Получается что тут создается смешанный тип таска "сверхурочность"+"обучение"? я, к сожалению, не понимаю тут использование терминов M2M и FK, они к БД имеют отношение? или говорят о связи классов в данном случае?

[Alksar]

sim3x: Не опускайте руки так рано! Вот вот и я пойму!)

[sim3x]

Alksar: и к бд, и к ооп
в терминах UML
FK ~ многие к одному (в данном случае)
M2M ~ многие ко многим

Если создавать класс на базе UML, то в классе ЗаказЗаказчика инициализируем поле список_тасков, а в классе Таск список_тип_таска

Для дальнейшей конкретизации скажи язик реализации

[sim3x]

ЗаказЗаказчика = ЗапросЗаказчика

[Alksar]

sim3x: c#

[sim3x]

Alksar: orm?

[sim3x]

Лучшая ORM для C#
www.codeproject.com/Articles/21122/NHibernate-Made...

[Alksar]

sim3x: нет, дело в том, что архитектура программы построена на "списке транзакций". Есть рабочая модель данных, которая ничего не знает о БД. Заказы умеют добавлять подзаказы, и.т.д., а на каждую операцию есть отдельный класс, который работает с реляционной БД. Поэтому при составлении связей классов я не думаю про базу, как они хранятся и т. д. Нужна гибкая модель, которая позволит добавлять сверхурочную работу по заказу.

[sim3x]

Alksar: тогда хз

[Alksar]

sim3x: Вы и так очень помогли)

[sim3x]

Alksar:
часто пользуюсь орм, потому практически всегда нормализую данные по НФ Бойса-Кодда и 3 НФ. Потому классы практически всегда есть отображением данных в бд.

[Alksar]

sim3x: а я начитался, что к вопросу хранения данных надо подходить в самый последний момент, мол релиционная база, объектная или файл обычный - потом выберешь. На практике особо не переживают по этому поводу?

[sim3x]

Alksar: парится по поводу хранения, конечно не стоит, но и оставлять на авось не самая лучша стратегия

На практике, я начинаю с того что формализую ТЗ в структуры для хранения, а вокруг структур строю механизмы для их обработки

Обьектные бд мало кому подходят и при скачкообразном росте обьемов данных, чаще всего становятся бутылочным горлышком

Answer 2

[Freeman]

Если сверхурочный заказ отрабатывается так же, как основной, он относится к сущности "подзаказ". Тогда получается, что метазаказы агрегируют задачи, при этом метазаказ может быть заказом или подзаказом, который разделяет с родительским заказом ключевые свойства.

А с учетом вашего комментария получается, что заказ агрегирует не только задачи, но и подзаказы. Тогда у него два агрегирующих атрибута: задачи и подзаказы.

Comments

[Alksar]

Наверно я не точно объяснил. Есть два вида заказов - заказ который делает заказчик (CustomerOrder), и заказ, который дают сотруднику (EmployeeOrder) - я назвал последние - подзаказами. На основе заказа от заказчика - сотрудникам выделяют подзаказы, и они их выполняют. Возможные ситуации: 1) У заказа есть один подзаказ который совпадает с заказом (Заказчик попросил 10 апельсинов, а мы попросили у Васи-сотрудника 10 апельсинов). 2) Заказ дробят (6 апельсинов Вася и 4 Сережа). 3) Заказу соответствует 1 но другой подзаказ.

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

Но в одном "модуле" программы, в так сказать инициализирующем - заказам ставятся в соответсвие подзаказы. Надо уметь их добавлять, удалять, обновлять. Если заказ удалить то надо стереть и его подзаказы.

Теперь про сверхурочность. Это требование добавили для одного вида Taska. Т.е. есть заказ основанный на этом типе Taska. (заказ на 10 апельсинов). У Этого заказа есть подзаказ - с совпадающим Task'ом - Вася - 10 апельсинов. Далее в программе добавляют к этому заказу сверхурочную работу (еще 2 апельсина сверхурочно), эти два апельсина должны быть обработаны отдельно от тех 10, потому что имеют свою цену, свое описание, и т д, они имеют и свой подзаказ - (тот же сотрудник сверхурочно 2 апельсина). Но удаляя заказ мы должны удалить и сверхурочный заказ на него.

[Freeman]

Alksar: И в чем проблема?

[Alksar]

Vapaamies: Была такая архитектура: Заказ хранит свои подзаказы в себе. Теперь добавилось новая возможность, указывать сверхурочную работу по одному из тасков, на котором строится заказ. Для программы нужно, чтобы эту сверхурочность можно было бы обработать так же как и заказ со своим подзаказом. Но сверхурочность не может быть совсем отдельным заказом, потому что связанна на прямую с заказом (указывается, что это сверхурочная работа для конкретного заказа, при удалении, изменении его она тоже удаляется, изменяться.). Получается что заказ теперь должен хранить в себе и заказ на сверх урочность отдельно? Или откуда заказ будет вообще знать что с ним связана сверхурочная работа?

[Freeman]

Alksar: Ну тогда да, в заказе должны агрегироваться или сами сверхурочные заказы, или горизонтальные ссылки на них.