Продолжаю описание флэш-фреймворка PureMVC рассказом о центре системы—Фасаде.
Там же мы узнали, что Фасад (Façade) — это участник, предоставляющий членам системы MVC прозрачный взаимный доступ друг к другу.
Наличие Фасада и есть причина отсутствия "Model", "View" и "Controller" в списке членов PureMVC. Дело в том, что Фасад "прячет" за собой эти части фреймворка, обеспечивая им взаимную видимость "сквозь фасад". Это так же прозрачно и для разработчика приложения. Конкретно, для разработчика-пользователя PureMVC это означает, что вы не обязаны явным образом создавать экземпляры этих трех ключевых классов: они строятся автоматически при создании Фасада. Разработчик создает один экземпляр класса Facade, а в дальшейшем все участники системы используют Фасад как централизованную точку доступа друг к другу.
static const NOTE_APP_INIT: String = "noteAppInit"
getInstance
initializeController
Команды же используются как макро-операции, руководящие работой системы в целом. Их деятельность можно уподобить действиям дирижера. Например, команды могут координировать последовательность действий при инициализации или закрытии приложения. Каждая команда — это часть Контроллера. Фасад знает о Контроллере и дает прозрачный доступ к каждой Команде; таким образом, разработчик оперирует не самим Контроллером, а его представителями—Командами.
В следующей части — о том, как обмениваются Оповещениями участники PureMVC.
Вопрос: понятно ли я излагаю? Что следует уточнить, а на что дать ссылки?
Рост, думаю что большое количество читающих твой блог, мало что поняли в этом посте. Признаюсь, сам сообразил не с первого раза о чем тут говориться, хотя GoF перечитывал этим летом. Тема довольно сложная для понимания. ИМХО: нужно более подробно останавливаться на каждом паттерне.
Кроме того, почему выбран для иллюстрации фреймворк PureMVC? ИМХО: его реализация довольно спорная. Взять тот же Фасад, обычно его используют, чтобы поделить программу на структурные блоки, чтобы каждый из этих блоков предоставлял общий интерфейс для элементов, которые в нем находятся, но никак не для того, чтобы обеспечить возможность взаимодействия всех элементов, находящихся в блоке, друг с другом.
Да, фасад тут явно сильно перегружен - много всего на один функциональный элемент повешено.
Классно что взялся за эту тему! Интересно было бы и про другие фреймворки почитать в твоей интерпретации :)
Да, создается впечатление, что Фасад действительно функционально перегружен.
Однако фраза "команды могут координировать последовательность действий при инициализации или закрытии приложения." наталкивает на мысль о типовом решении "Единица работы" по Фаулеру :) Регистрируя такие "единицы работы" в "Реестре" можно попытаться разгрузить фасад, делегировав часть рутины "Единицам работы" (напр. регистрация слушателей, оповещение слушателей, фабричное изготовление компонент)
Плюс можно частично делегировать некоторые операции по инициализации компонент, отлову исключений типовому решению "Intercepting Filter" (Фаулер)
Отличная статья, спасибо, Рост :)
Да я бы не сказал, что просто перегружен функционал Фасада. Тут явный пример непонимания назначения этого паттерна. Вообще Фасад - это, пожалуй, самый часто используемый паттерн, просто мало кто об этом задумывается. Простой пример: делаете вы машинку для игры, определяете классы частей, из которых эта машинка будет состоять, налаживаете взаимодействие между этими частями и объединяете все эти части в единый комплекс, посредством включения этих частей в состав класса Car. Теперь вам не придется взаимодействовать с каждым элементом, из которых состоит машинка, напрямую вы работаете только с интерфейсом класса Car. А уже сам Car, реагируя на ваши действия, заставляет свои составные части что-то делать.
Повторюсь еще раз, основное назначение паттерна Фасад - это предоставление общего интерфейса для какой-нибудь подсистемы (в нашем случае общего интерфейса для составных частей машинки).
Т.е. мы не обращаемся теперь к каждому из четырех колес, повернись-мол на такой-то угол и вращайся с такой-то скоростью, а просто задаем текущее значение скорости и угол поворота для всей машины. И теперь сама машина должна задать нужный угол поворота и скорость вращения для каждого колеса.
Тем более почему Фасад должен быть синглетоном, я не понимаю. Разве в нашем случае имеет смысл запрещать создание 2 и более экземпляром машинки? Конечно же нет. Меня мучают подозрения, что авторы PureMVC недопонимают назначение паттерна Одиночка. Скорее всего разработчики воспользовались этим паттерном только для того, чтобы обеспечить глобальных доступ к Фасаду из любой точки приложения. Но это в корне не правильно. Одиночка нужен совсем не для того. Он нужен только для того, чтобы в программе не создавалось более одного экземпляра какого-либо класса. Обеспечение глобальной точки доступа - это уже второстепенная его задача.
Забыл упомянуть, что Car в предыдущем примере и есть образец паттерна Фасад.
>> Забыл упомянуть, что Car в предыдущем примере и есть образец паттерна Фасад.
Ничего, из контекста это сразу было понятно.
Отличный комментарий, Юр! Да, Фасад в PureMVC - не традиционный. Хотя — как посмотреть. В данном случае этот Фасад является окном видимости - потому и Фасад, и в то же время он глобален для всей системы - потому и Одиночка, так как приложение одно.
Кстати, наколько я помню, Макс Грынив когда-то сильно нарекал на Синглтонность ModelLocator в Cairngorm. Фасад PureMVC - это его тезка, но имеет радикально другой характер.
Побуквоедствую;) Рост, а откуда в слове Facade у буквы "c" появилась cedilla? В английском языке её нема, да и в книгах GoF фасад тоже простым английским словом обзывают.
Max Degtyarev™, я сам задался таким вопросом — откуда хвост у этой буквы ç. В Википедии приводят два варианта - с хвостом и без. Автор PureMVC выбрал хвост. Я ему следую. Хотя это не очень удобно в латинице. Но у нас есть русский язык, в котором Фасад без хвоста как ни крути Ж-)
Юра, кстати, в той же Википедии увидел, что тамошнее определение Фасада вполне подходит под данный случай его иcпользования в PureMVC — с той оговоркой, что в PureMVC его стоит назвать Центральным Фасадом - вчера написал об этом.
Dimchansky™
>> Да, создается впечатление, что Фасад действительно функционально перегружен.
На самом деле - нет. Думаю, многое станет яснее, когда пойдут примеры конкретного приложения (их будет даже два). Прошу дождаться их. Очень хочу изложить суть фреймворка последовательно (Кстати, не так уж много осталось излагать).
По поводу "единицы работы" - очень интересно. К своему стыду, именно этого я у Файлера еще не читал; обещаю наверстать, так как тема очень инетерсная. Мне кажется, что организация Команд (или Оповещений?) внутри PureMVC близка к подходу "Единиц Работы".
>> Кроме того, почему выбран для иллюстрации фреймворк PureMVC?
Юр, причина очень простая: уже два месяца с ним работаю. Доволен. Давно хочу рассказать, но не считал правильным рассказывать о фреймвоке, не сделав на нем хотя бы одного серьезного проекта. И вот - это время пришло.
Что я в ПьюрМВЦ очень полюбил - так это его компактность, простоту и произносимое имя :)
Очень интересная структура, но применима ли она для больших проектов?
Большой проект необходимо разделять на модули, как это сделать сдесь ведь в основе проекта сингелтоны
Не будет ли например View одного модуля конфликтовать с другим? ведь медиаторы по сути добавяться к одному и тому же View?
