Муфта в дизайне OO - PullRequest
       27

Муфта в дизайне OO

3 голосов
/ 27 декабря 2010

У меня есть два объекта. Объект Meeting и объект Action (действие, инициированное на собрании). Действие также может существовать независимо от собрания. У меня есть два способа связать действие, поднятое с собранием:

  1. есть метод на собрании, где я передать объект Action, такой как msgstr "addToMeeting (Действие действия)". Внутри собрания Затем я связываю действие с встреча. Для этого подхода, хотя Объект встречи должен знать о и использовать методы в действии объект так становится связанным.
  2. есть метод на Встрече, где я просто прохожу номер действия, который будет связан таким как "addToMeeting (int actionID)". Отличный сейчас объект встречи не нужно знать что-нибудь о действии но ...... теперь код, добавляющий действие на встречу нужно знать как получить идентификатор действия так отвернулся от этого "meeting.addToMeeting (action)" для этот "Meeting.addToMeeting (action.getID ())".

Какой подход следует использовать для хорошего дизайна ОО? Или есть третий путь ....

Ответы [ 4 ]

5 голосов
/ 27 декабря 2010

Если единственная мысль, которую вы когда-либо планируете связать с Meeting экземплярами, - это действия, то было бы наиболее целесообразным информировать Meeting о Action, а не наоборот.

Наличие класса Actions для манипулирования внутренними объектами Meeting нарушает инкапсуляцию и, как правило, усложняет поддержку такого кода. Итак, я бы выставил метод addAction(Action a) на Meeting в этом случае.

Однако, если есть и другие вещи, которые могут быть связаны с собранием, вы можете рассмотреть возможность абстрагирования понятия «предметы собрания».

Вместо того, чтобы Meeting знать о Action или наоборот, вы могли бы определить интерфейс, такой как IMeetingItem, который предоставляет необходимую информацию, которую Meeting потребуется для ссылки на такие элементы. Action будет реализовывать IMeetingItem, что позволит сделать что-то вроде:

meeting.addItem( action );  // action treated as an IMeetingItem in this context

Обратите внимание, что в обоих подходах именно класс Meeting обеспечивает функциональность добавления элемента к себе, а не добавление элемента для управления внутренним представлением собрания.

1 голос
/ 27 декабря 2010

Я бы посоветовал вам создать интерфейс «Идентифицируемый» с методом getID (), который реализуется действием

Затем вы можете сделать следующее:внутри метода сделать

this.actionId = action.getID();
0 голосов
/ 27 декабря 2010

Я бы выбрал вариант № 1 - в вашем случае соединение не так уж и плохо, поскольку между объектами существует четкая связь.Я бы пошел с вариантом № 1.Это дает вам возможность для собрания иметь свойство MeetingActions[] или нечто подобное.

0 голосов
/ 27 декабря 2010

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

...