Если единственная мысль, которую вы когда-либо планируете связать с 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
обеспечивает функциональность добавления элемента к себе, а не добавление элемента для управления внутренним представлением собрания.