Подробнее о схеме посредника и ОО-дизайне

Question

Итак, я вернулся, чтобы еще раз задать вопрос, связанный с паттернами.Это может быть слишком общим, чтобы ответить, но моя проблема заключается в следующем (я программирую и применяю концепции, которые я изучаю по мере продвижения вперед):

У меня есть несколько структур внутри структур (обратите внимание, я использую слово структура в общем смысле, а не в строгом смысле C struct (воу, что за скороговорка)), и происходит довольно сложное взаимодействие.Используя пример одного из моих предыдущих вопросов, у меня есть Unit объекты, UnitStatistics объекты, General объекты, Army объекты, Soldier объекты, Battle объекты, и список можно продолжить, некоторые организованыв древовидной структуре.

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

Но, ну, я думаю, я еще недостаточно изучил дизайн ОО.У меня такой вопрос (наконец, PS, я надеюсь, что это имеет смысл): должен ли я иметь одного центрального посредника, который занимается всеми коммуникациями в рамках программы, и возможно ли это вообще?Или я должен иметь, скажем, абстрактный медиатор и один субклассированный медиатор на тип структуры, который связан с коммуникацией определенного набора классов, например, конкретного медиатора на армию, который помогает армии, ее полководцу, ее подразделениям и т. Д.

Я больше склоняюсь ко второму варианту, но я действительно не эксперт, когда дело доходит до ОО-дизайна.Итак, третий вопрос: что я должен прочитать, чтобы узнать больше об этом предмете (я посмотрел книгу Design Patterns от Head First, и книгу GoF, но они скорее "изучают словарный запас")Это книга, а не книга «научись использовать свой словарь», которая мне в этом случае нужна.

Как всегда, спасибо за любую помощь (включая остроумные комментарии).

Answer 1

Я не думаю, что вы предоставили достаточно информации выше, чтобы иметь возможность принять обоснованное решение о том, какой из них лучше.

Из рассмотрения других ваших вопросов кажется, что большая часть общения происходит междукомпоненты в пределах Army.Вы не упоминаете о большом количестве случаев между одним Army и другим.В этом случае, казалось бы, имеет смысл иметь каждый экземпляр связи Mediator координат между компонентами, составляющими один Army - т.е. Generals, Soldiers и т. Д. Так что, если у вас есть 10 Army, тоу вас будет 10 ArmyMediator.

Если вы действительно хотите изучать OO Design, вам придется попробовать что-то и рискнуть время от времени ошибаться.Я думаю, вы узнаете столько же, если не больше, от необходимости реорганизовать дизайн, который не совсем корректно моделирует проблему, в тот, который делает, как вы это сделаете из правильного проектирования в первый раз.

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

Что касается книг, лично я думаю, что книга GoF болееполезно, если вы меньше сосредотачиваетесь на конкретном наборе шаблонов, которые они описывают, и больше сосредотачиваетесь на общем подходе, разбивающем классы на более мелкие повторно используемые компоненты, каждый из которых обычно инкапсулирует одну единицу функциональности.

Answer 2

Для использования Медиатора необходимо определить: (1) Из чего состоит группа объектов, нуждающихся в посредничестве? (2) Среди них, которые имеют общий интерфейс?

Шаблон проектирования Mediator опирается на группу объектов, которые должны быть опосредованы, чтобы иметь «общий интерфейс»; то есть тот же базовый класс: виджеты в примере книги GoF наследуются от одной и той же базы виджетов и т. д.

Итак, для вашего приложения: (1) Какие структуры (солдат, генерал, армия, подразделение и т. Д.) Нуждаются в посредничестве между собой? (2) Какие из них (солдат, генерал, армия, отряд и т. Д.) Имеют общую базу?

Это должно помочь вам определить, в качестве первого шага, наброски участников шаблона проектирования Посредника. Вы можете обнаружить, что некоторые структуры в (1) выходят за пределы (2). Тогда вам может понадобиться заставить их придерживаться общего интерфейса, если вы можете изменить это или если вы можете позволить внести это изменение ... (может оказаться слишком много работы по изменению дизайна и это нарушает принцип Open-Closed: ваш дизайн должен быть максимально открыт для добавления новых функций, но закрыт для изменения существующих).

Если вы обнаружите, что приведенные выше пункты (1) и (2) приводят к разделению отдельных групп, каждая из которых имеет своего собственного посредника, то число этих разделов диктует количество различных типов посредников. Должны ли эти разные посредники иметь общий интерфейс? Может быть, а может и нет. Полиморфизм - это способ справиться со сложностью, группируя различные объекты под общим интерфейсом, так что они могут обрабатываться как группа, а не по отдельности. Итак, будет ли какая-то польза от группировки всех этих предположительно различных типов медиаторов под общим интерфейсом (например, DialogDirector в примере книги GoF)? Возможно, если: (а) Возможно, вам придется использовать гетерогенную коллекцию медиаторов; или же (б) Вы предполагаете в будущем, что эти посредники будут развиваться (и они, вероятно, будут). Следовательно, предоставление абстрактного интерфейса позволяет вам получать более развитые версии посредников, не затрагивая существующих или их коллег (клиентов посредников).

Так что, не зная больше, я должен был бы предположить, что, да, вероятно, лучше использовать абстрактные посредники и подклассировать их, для каждого группового раздела , просто чтобы подготовиться к будущим изменениям без необходимость перепроектировать ваших посредников (помните принцип Open-Closed).

Надеюсь, это поможет.

Answer 3

Я не могу ответить на ваш вопрос напрямую, потому что я никогда не использовал этот шаблон проектирования.Однако всякий раз, когда у меня возникает эта проблема передачи сообщений между различными объектами, я использую шаблон сигнального слота.Обычно я использую Qt's , но мой второй вариант - Boost's .Они оба решают проблему, имея единый глобальный обработчик передачи сообщений.Они также безопасны по типу и довольно эффективны, как с точки зрения циклов процессора, так и с точки зрения производительности.Поскольку они настолько гибки, то есть любой объект и излучает любой вид сигнала, и любой другой объект может получить любой сигнал, вы, в конечном счете, решите, что вы описываете.еще хуже, если вы не выберете ни один из двух вариантов, а добавите третий!