Паттерны GoF - Facade (лекция) (комментарии)
Это сообщение сгенерировано автоматически.
>Применять когда:
...
>2. Нужно разложить систему на слои, можно упростить зависимости между подсистемами, если разрешить им трогать друг друга только через фасады
...
>Участники:
>2. Классы подсистем - реализуют функциональность системы, выполняют поручения Facade, !не знают о фасаде, не хранят ссылок на него!
Т.е. все-таки некоторые участники знают об интерфейсах соответствующих facade. В общем, довольно жестким мне представляется требование односторонней связи facade -> actor.
Пример такой:
Application
|
+------------------- MainFacade
| / \
Game Config Render
subsystem subsystem subsystem
| |
{game objects} {renderable objects}
Идея в том, что Facade вместе с subsystem'ами представлены с помощью абстрактных интерфейсов и singleton-based accessor'ов. Для приложения (Application), звено MainFacade является как раз тем что описано в оригинале, с соблюдением всех ограничений. Отношение Config subsystem и MainFacade также подпадают под определение.
Далее, Game/Render subsystem (являющиеся также facade) общаются между собой и с другими подсистемами как правило через singleton accessors. Хотя кому-как нравится, можно и через MainFacade.
Интересный для меня вопрос начинается на уровне объектов подсистем. В моей схеме, game object содержит renderable objects. И если game object захочет в очередной раз как-то себя проявить (достать из кармана базуку например), то он без зазрения совести обращается к Render subsystem. (Здесь я утрирую, т.к. происходит сначала запрос к ResourceManager facade для немедленной загрузки ресурсов, из которых создастся renderable object базуки и т.п.)
Т.е. получается что "участник" (game object) знает о Render subsystem facade. Вроде удобно. Делегирование общения game object'ов с render subsystem'ой на уровень facade-facade мне представляется ненужным.
Очевидная проблема - это замена подсистем on-the-fly в условиях многопоточности. Но она мне кажется надуманной.
Padawan
>>Применять когда:
>...
>>2. Нужно разложить систему на слои, можно упростить зависимости между
>>подсистемами, если разрешить им трогать друг друга только через фасады
>...
>>Участники:
>>2. Классы подсистем - реализуют функциональность системы, выполняют поручения
>>Facade, !не знают о фасаде, не хранят ссылок на него!
>
>Т.е. все-таки некоторые участники знают об интерфейсах соответствующих facade.
Вовсе не обязательно. И из этих пунктов этого не следует. Классы какой-то одной подсистемы знают о фасаде другой, в свою очередь классы другой - знают о фасаде первой. Но врядли классам первой нужно знать о своем фасаде, проще взаимодействовать внутри подсистемы напрямую.
Короче фасад - это обвертка целой подсистемы, классы обворачиваемой подсистемы могут ничего не знать о своем фасаде
>В общем, довольно жестким мне представляется требование односторонней связи
Согласен, может быть когда-то оно и лишнее.
В твоем примере не нашел никаких противоречий - в том что game object из подсистемы Game, знает о фасаде подсистеме рендера, нет ничего особенного (game object участник другого фасада)
Тема в архиве.