Архитектура движка.Форум

Паттерны GoF - Facade (лекция) (комментарии)

#0
10:19, 27 янв 2006

Паттерны GoF - Facade (лекция) (комментарии)

Это сообщение сгенерировано автоматически.

#1
10:19, 27 янв 2006

>Применять когда:
...
>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 в условиях многопоточности. Но она мне кажется надуманной.

#2
14:00, 27 янв 2006

Padawan
>>Применять когда:
>...
>>2. Нужно разложить систему на слои, можно упростить зависимости между
>>подсистемами, если разрешить им трогать друг друга только через фасады
>...
>>Участники:
>>2. Классы подсистем - реализуют функциональность системы, выполняют поручения
>>Facade, !не знают о фасаде, не хранят ссылок на него!
>
>Т.е. все-таки некоторые участники знают об интерфейсах соответствующих facade.
Вовсе не обязательно. И из этих пунктов этого не следует. Классы какой-то одной подсистемы знают о фасаде другой, в свою очередь классы другой - знают о фасаде первой. Но врядли классам первой нужно знать о своем фасаде, проще взаимодействовать внутри подсистемы напрямую.
Короче фасад - это обвертка целой подсистемы, классы обворачиваемой подсистемы могут ничего не знать о своем фасаде

>В общем, довольно жестким мне представляется требование односторонней связи
Согласен, может быть когда-то оно и лишнее.

В твоем примере не нашел никаких противоречий - в том что game object из подсистемы Game, знает о фасаде подсистеме рендера, нет ничего особенного (game object участник другого фасада)

Архитектура движка.Форум

Тема в архиве.