Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > Dukobpa3

Оценить эту запись

Медиатор, Прокси

Запись от Dukobpa3 размещена 14.11.2013 в 23:02
Обновил(-а) Dukobpa3 16.11.2013 в 16:55

Ссылки на форуме по теме:
Клиентские реализации медиатор-прокси.
Медиатор
Медиатор-прокси, сравнение

Другие источники:
Медиатор
Прокси
Статья в Вики, Медиатор
Статья в вики, прокси (Пример приведен очень крутой, но не сразу понятный. К тому же новичку будет сложно уловить связь между четырьмя сферами применения прокси, расписывать не хочу, это есть в статьях выше, но на вопросы отвечу с удовольствием)
  • Медиатор: организовывает связи между несколькими объектами. Давая возможность им общаться не напрямую, устраивая лапшу из перекрестных ссылок, а через отдельно выделенный менеджер.
  • Прокси: некий уровень абстракции над неким реальным объектом. Вносится в систему для того чтобы дать возможность эмулировать работу с реальным объектом, либо управлять доступом к реальному объекту, либо выдавать наружу универсальный интерфейс для нескольких разных объектов.

Если брать ближе к флешу, то медиатор часто используют именно со стороны вью.
В медиаторе инкапсулируют несколько вьюх. Медиатор является посредником в общении между этими вью. Каждая из вью видит только свой медиатор, и может отдать/получить данные в/из него.
Так же в этом классе обычно реализовывают логику прокси. Т.е. с точки зрения контроллера этот медиатор-прокси будет являеться общей точкой входа в блок вьюх. И будет восприниматься контроллером как одна вьюха.

Чистые варианты либо встречаются не часто, либо же все реализации называют медиаторами. Например известный фреймворк pure-mvc перевернул всё с ног на голову. В нем есть медиатор, и есть прокси. И то и то выполняет одинаковый набор действий, но в логике пюре - прокси это обертка над несколькими моделями, а медиатор над вьюхами. Хотя по сути и то и то является и медиатором и прокси одновременно, только для разных участков системы.

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

Итого что мы можем сделать.
  • Мы можем сделать на каждый попап свой контроллер. Свою модель. Свою вью. Руководствуясь теми соображениями что в каждом попапе ведь уникальный контент. (Самый унылый вариант)
  • Мы можем сделать один контроллер попапов. На каждый попап своя модель и своя вью. (Мы тут вроде как подключили смекалку и решили упростить, но всё-равно еще далеки от идеала)
  • Мы не делаем контроллера попапов, ведь у нас уже есть контроллер гуя. Мы просто делаем медиатор попапов и одну модель попапов. Вью на каждый попап рисовать все-равно придется, если они отличаются внутренним контентом, но в идеале вообще остановиться на динамическом заполнении контента по данным из модели. (Это самый адекватный вариант из всех)

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

В данном варианте наш медиатор будет медиатором только если один попап будет пытаться обращаться к другому попапу, и будет делать это через наш "медиатор". А так эта реализация - это собственно чистой воды прокси. Абстракция для универсализации интерфейса.

Пример два(медиатор+прокси)
У нас есть игровое поле простенькой игры.
На этом поле есть кнопки управления + собственно сама игра.
Кнопок управления достаточно много, там всяко-разные панельки (например дресс-ап какой-нибудь, в котором куча категорий шмоток, плюс в каждой шмотке свой функционал по привязке к кукле и в таком духе). Так вот весь функционал панелек пихать в одну вьюху неудобно. Мы делим этот функционал по панелькам, и каждая панелька это вью, которая что-то умеет. Но вот контроллеру глубоко монопенисуально пять у нас панелек в интерфейсе или одна. Ему просто интересно буквально пять ивентов на тему: сменить куклу, открыть, закрыть игровое окно, натянуть новую шмотку, купить новую шмотку в магазине. При чем ему во всех эжтих действиях достаточно знать только ИД.
Соответственно мы все эти панельки пихаем в медиатор. С точки зрения контроллера - он рулит только одной вью (которая опять же не вью, а медиатор). Которая умеет диспатчить наружу пять вышеописанных событий. Контроллер остается тоненьким и удобненьким, медиатор занимается менеджментом между вьюхами-панельками, скрывает всё мясо коммуникаций за своей абстракцией, и всем в этой ситуации хорошо (это как раз тот вариант, который в статье по ссылке выше нарисован в виде самолетов и диспетчерской вышки, но на картинке в статье нету контроллера, он будет какой-то стрелочкой от башни нарисован если дорисовать).

В данном случае та часть медиатора, которая обрабатывает логику нажатий кнопки в панельке кнопок, и по этому нажатию например откроет панельку причесок - медиатор.
Та часть, с которой общается контроллер - прокси.

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


Пример три(прокси, часто путают с медиатором)
Многомодульная система.
Каждый модуль это какая-то миниигра. У нас есть главная флешка, которая умеет грузить в себя эти модули. Соовтетственно в каждом модуле будет какой-то функционал и они будут очень сильно отличаться.

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

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

Опять же в данной реализации наш медиатор не медиатор, а прокси (но, например, в pure-mvc это будет наследником класса Mediator)

Пример четыре(прокси, часто путают с медиатором)
Система с возможностью смены интерактивных скинов.
У нас есть некий интерфейс игры. Что-то типа героев третьих, но чуть сложнее и веселее. Например выбираем рассу которой играем, нежить, орки, рыцари.
И в зависимости от выбранной расы у нас меняется весь интерактив интерфейса, звуки, анимации, выезжания окошек, гэги и прочие пасхальные яйца.
Так вот с таким вариантом у нас практически едиснтвенный вариант делать интерфейс в форме медиатора, или даже дерева из нескольких медиаторов, в которые будут инжектиться вью-свф-ассеты, каждая вью будет уметь анимировать, открывать, прятать окошки, и прочие плюшки, но все отличия инкапсулируем за медиаторами. Если мы попытаемся сделать это вьюхами без такой прослойки-абстракции - огребем оверхеда на полтора-три срока разработки интерфейса. Плюс это всё будет расти с добавлением каждого нового интерфейса. С медиатором же мы один раз настроим связи между медиатором и контроллером с моделью, а потом внутрь медиатора будем подгружать уникальные ассеты интерфейса.

Тут опять прокси. Абстракция над разнородными сущностями.

UPD: Поправка к примеру 3 и 4
Немного не очевидно расписал.
Пример три: тут можно сделать некий интерфейс модуля, каждый модуль будет предоставлять тот же интерфейс, и мы просто будем грузить эти модули с одинаковым интерфейсом и пользоваться.
Но в приведенном примере прокси всегда находится в системе. Контроллер его всегда видит. Может спросить пустой/не_пустой. Система даже сможет отрисовать пустой, не загруженный модуль, это просто не нужно. А вот прокси уже по требованию будет грузить в себя модуль, и когда загружен будет предоставлять под своим АПИ - АПИ модуля. Просто пока модуля нет он будет выдавать либо какие-то значения по-умолчанию, либо некие пустые значения (null, false, ""), но они есть.

Пример четыре примерно то же самое. Можем сделать в системе какой-то один скин по-учмолчанию, который всегда будет в системе, тогда прокси всегда будет инициализироваться с этим скином, но позже сможем загрузить какой-то внешний. Или как-то аналогично.
Вцелом такому скину можно выдать его интерфейс и расписать его АПИ для системы. Это тоже правильный вариант. Просто другой.

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

//**********************************

Собственно всё
Выводы расписывать нее буду, это предлагается сделать в комментариях.
Напомню только про еще одну отвертку в ящике с инструментами, и важно уметь пользоваться своим инструментарием

//**********************************
UPD:
Свел описание медиатора и прокси в одно, в связи с особенностями клиентской разработки и реализации этих паттернов.
Всего комментариев 9

Комментарии

Старый 15.11.2013 00:04 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Добавил еще хороших ссылок, с которыми согласен. Чуть позже добавлю текста и примеров, но уже не копипасты.
Старый 15.11.2013 18:13 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Исправил ошибки в описании по части медиатор-прокси. Свел два паттерна в одну статью.
Постарался сгладить путаницу которая в мозгах флешеров сидит достаточно глубоко
Старый 16.11.2013 16:56 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
UPD: Поправка к примеру 3 и 4
Немного не очевидно расписал.

Внес в статью.
Старый 16.11.2013 18:21 Akopalipsis вне форума
Akopalipsis
У меня есть предложение - форум о флеше, вставляйте статьи о флеше.
Вот например о статьи о прокси.
Старый 16.11.2013 18:33 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Твою ссылку антивирус блочит.
С предложением согласен, но я руководствовался выбором статей не с точки зрения языка, а с точки зрения понятности и прозрачности описания. На мой взгляд лучше чем по ссылкам суть паттерна объяснить сложно.

На будущее учту, постараюсь гуглить именно флешовые примеры и описания. Или могу свои добавлять по запросу. А то я так сам посмотрел на свои труды - нифига без кода не понятно. Если знаешь - поймешь. Если не знаешь только больше запутаешься... Короче, не оч как-то результат получается(((
Поработаю над форматом изложения.
Старый 16.11.2013 19:04 Akopalipsis вне форума
Akopalipsis
Цитата:
Твою ссылку антивирус блочит.
Странно, у меня нет. Мне вообще кажется, что этот сайт William B. Sanders, по тому, что он там отвечает..
И личности, известные по RL, то же там то и дело проскальзывают.
Старый 16.11.2013 19:44 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Patterncraft
Тут видео с примерами. А ссылку на репозиторий с ас3 исходниками я уже кидал в какой-то статье.
Старый 16.11.2013 19:52 Akopalipsis вне форума
Akopalipsis
Цитата:
Тут видео с примерами. А ссылку на репозиторий с ас3 исходниками я уже кидал в какой-то статье.
Спасибо! Отправляется в закладки
Старый 16.11.2013 20:05 Dukobpa3 вне форума
Dukobpa3
 
Аватар для Dukobpa3
Уделю дополнительно время, соберу адекватно ссылки по этим своим постам. Пока что только на комментарии получается оторваться)))
 

 


Часовой пояс GMT +4, время: 06:55.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2022, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.