Правильная иерархия классов

Рейтинг: 1Ответов: 1Опубликовано: 27.11.2014

Никак не получается придумать логически непротиворечивую модель классов. В общем случае имеются следующие виды документов:

  • Документ, состоящий только из заголовочной части (сlass DocumentHeader).
  • Документ, состоящий не только из заголовка, но еще и табличной части (сlass DocumentDetail).

Классы, представляющие данные документы, являются абстрактными. Т.е. от них необходимо наследовать потомков, реализующих конкретную функциональность:

  • сlass DocumentHeader {}
  • class DocumentDetail : DocumentHeader {}

Теперь представим, что у нас есть конкретные документы:

  • Итоговая заявка на товар. Содержит консолидированную информацию о заказе (class Order).
  • Детальная заявка на товар. Помимо итогов, содержит табличную часть с заказом (class OrderDetail).

Имеем противоречие:

Детальная заявка должна наследовать функционал, реализованный в итоговой заявке, т.е.

  • class OrderDetail : Order {}

Детальная и итоговая заявки должны наследовать функционал абстрактных классов DocumentHeader и DocumentDetail. Т.е.

  • class Order : DocumentHeader {}
  • class OrderDetail : DocumentDetail {}

Подскажите, пожалуйста, какой подход использовать в данной ситуации?

ооп шаблоны-проектирования
Источник: Stack Overflow на русском

Ответы

▲ 1Принят

хм... Помидорами просьба не кидаться

Если взять 1С, то там дается такое определение: Документ предназначен для описания информации о свершенных хозяйственных операциях в жизни организации вообще. (Проведенный документ - реально факт свершился, не проведенный - не более чем черновик - можно и удалить.)

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

При проектировании класса я бы взял за основу один класс, который включает в себя заранее известные реквизиты документа (дата создания, дата документа, наименование, сотрудник - чтоб было с кого спрашивать), плюсом сразу бы реализовал табличную часть (сохранение, изменения, удаления), а также некий флаг на то, что есть ли табл часть или нет (кстати, их может быть несколько). При этом при создании конкретного объекта (документа) - указываем доп. реквизиты, и флаг - есть лит у нас табл. часть или нет, если присутствуем - конкретизируем ее реквизиты.

P.S. 1С, конечно, не любят программисты других языков (сам испытываю некоторый дискомфорт при работе с ней) - но при обучении многое в голове разложилось по полкам, в книгах много полезного материала для проектирования серьезных систем (не сайтов визиток, даже не каталогов).

Как-то так.