Façade and AOP

Давненько я не писал по теме шаблонов и аспектов. И этот пост будет для разогрева темы снова.

До этого были рассмотрены шаблоны, которые в той или иной степени получают профит от использования Аспектно-Ориентированного программирования. Однако есть один, который не получит никакой пользы от АОП. Сама суть шаблона «Фасад» заключается в том, чтобы выделить отдельный интерфейс для облегчения доступа к некоторой сложной подсистеме.

facade_aop

Википедия дает следующее определение:

Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

С помощью аспектов не выделить отдельный класс для такого функционала.

По сути, исследователи признали, что только «Фасад» никоим образом из классических 23 шаблонов не может быть хотя бы частично реализован с помощью АОП.

Вот такой короткий рассказ.

 

Hard’n’Heavy!

Интервью Гаэля и Скота Хансельмана

Всем привет! Я хочу анонсировать и пригласить резидентов Москвы и Питера посетить бесплатные вечера и мастер-классы с автором одного из наиболее мощных АОП фреймворков для .Net — Гаэлем Фрётэром.
Встречи пройдут 11-13 марта в Москве и 16-17 марта в Питере. Еще раз повторюсь мероприятие бесплатное, но необходимо зарегистрироваться. Более подробно агенда представлена здесь

Далее вы можете почитать весьма занимательное интервью, которое дал Гаэль Скоту, о том, как развивался и вставал на ноги продукт. Какие сложности были в развитии, какие непростые решения пришлось принимать во время перехода от опенсорс проекта к коммерческому.

HM

СКОТТ ХАНСЕЛЬМАН: Всем привет, это Скотт Хансельман (Scott Hanselman) и в эфире новый эпизод Hanselminutes. Сегодня, с помощью магии скайпа, с другого конца мира, мы поговорим с Гаэлем Фрётэром (Gael Fraiteur) из SharpCrafters, создателем PostSharp. Привет!
ГАЭЛЬ ФРЁТЭР: Привет!
СКОТТ ХАНСЕЛЬМАН: Я очень рад, что сегодня могу поговорить с тобой. Я твой поклонник и нам предстоит многое обсудить. Сегодняшняя беседа входит в цикл бесед о стартапах и ты как нельзя лучше подходишь для этого. Ты человек из мира открытого ПО, и создал программу которой я пользовался для своих открытых проектов, но теперь ты построил на этом целую компанию. И я хочу понять почему ты сделал это? Затем мы немного обсудим сам продукт и его будущее. Итак, ты можешь начать с рассказа что за программу ты создал.
ГАЭЛЬ ФРЁТЭР: Мы создали PostSharp – это дополнение к компилятору, которое запускается после сборки проекта или, другими словами Аспектно-Ориентированный фреймворк. Его задача заключается в том, чтобы вы, как программист, создавали меньше тупого повторяющегося кода. Для примера можем рассмотреть такую штуку как реализацию уведомления об изменении свойства. Каждый раз для её использования вам надо написать три строчки кода. Эти три строчки кода – мелочь, но мелочь, которая должна быть реализована для каждого свойства в каждом классе, и они превращаются в тысячи строк кода. Можно обнаружить, что вы пишите реализацию по определенному шаблону и это приводит к лучшей реализации INPC. Наш инструмент позволяет реализовать этот шаблон так, что код будет генерироваться автоматически и не загрязнять исходный код. Это суть подхода PostSharp и аспектно-ориентированного программирования (АОП).
СКОТТ ХАНСЕЛЬМАН: Хм, аспектно-ориентированное программирование. Я слышал про него в рамках решений для сквозного функционала. Можно сказать, что люди думают вертикально при объектно ориентированном подходе: это наследуется от этого, вон то от другого. Но АОП, как например логирование, не вписывается в такую вертикальную иерархию. Оно прошивает эти иерархии через всё приложение. Я в верном ключе описал АОП подход?

Подробнее

Мастер-класс основателя PostSharp в Москве

Gael Fraiteur

В начале марта с 10 по 15, Гаэль приезжает в Россию и хочет провести мастер-классы и вечерние беседы в Москве и Питере. Я ему помогаю в этом деле и фактически организую визит. Мне хотелось бы знать, сколько человек желает с ним побеседовать вечером (это конечно будет не просто сессия вопросов и ответом, а будет практика и лекция часа на 3-4) или посетить мастер-класс. Цена на мероприятия по большей части будет символической для покрытия расходов на аренду.

Если есть желающие, можете сразу писать мне на почту my@violet-tape.net.

Большинство людей которые что-либо слышали о PostSharp думают, что он годен только для логирования и обработки ошибок. Однако те, кто осмелился копнуть глубже, часто меняют свое видение программирования. Навсегда.

Программа курса, представленного ниже, читается основателем и ведущим программистом PostSharp Гаэлем Фрэтером (Gael Fraiteur). В курсе раскрываются концепции аспектно-ориентированного программирования, как автоматизировать реализации шаблонов проектирования, а также как внедрить проверку дизайна кода. В конце дня у вас появится общее понимание того, как PostSharp может облегчить жизнь вашей команде.

Даже если вы думаете, что PostSharp не для вас, посетив курс вы навсегда измените свой взгляд на разработку ПО.

Ключевые моменты тренинга

  • Получите совершенно новый и захватывающий взгляд на процесс программирования, шаблоны проектирования и на то, что компилятор может сделать для вас. Это будет как глоток свежего воздуха, даже если вы не собираетесь использовать PostSharp.
  • Изучите использование готовых решения из PostSharp Pattern Libraries (threading design patterns и INotifyPropertyChanged).
  • Поймете, как автоматизировать ваши собственные шаблоны используя АОП.
  • Узнаете о построении автоматической проверки архитектурных решений в вашем коде.
  • Получите ответы напрямую от создателя PostSharp!

Подробнее

Определение места ошибки в исходном файле

Относительно недавно я писал про Singleton и там была у меня не решенная проблема с тем, что не выводилось точное место возникновения ошибки. Анализ ошибки проходил как надо, информация дополнительная выводилась, но это было мало. Привычный шаблон работы, когда двойной клик по тексту ошибки приводил к навигации на место ошибки не работал. Это безмерно огорчало.

После плодотворного общения с программистами PostSharp, оказалось, что это была ошибка в последней сборке и новый релиз, начиная с 4.0.41, ее исправляет. Дальше я хочу отдельно обратить внимание на то, что надо делать и рассказать немного о том, как вообще можно получить эту информацию в C#: до версии 4.5, с версии 4.5 и старше.

PostSharp

Эта часть статьи в целом задумана как обновление и привлечение внимания к статье про шаблон Singleton. Я ее обновил, но тем не менее.

Использование Архитектурного фреймворка из состава PostSharp рано или поздно приведет вас к тому, что надо будет уведомлять программистов об ошибках/недочетах. Лучше всего это делать с помощью специализированных классов, которые построены с учетом специфики работы PostSharp на этапе сборке проекта. К таким специализированным классам относятся:

  • MessageLocation – статический класс, который позволяет узнать место ошибки (строка, файл) на основе служебной информации о составной части класса (MethodInfo, ConstructorInfo и так далее).
  • Message – класс со статическими и динамическими методами, который помогает сформировать сообщение для отображения для конечного пользователя – программиста.

Общий шаблон работы с этими классами выглядит так:

Подробнее

Шаблон Хранитель в АОП реализации

Вторым на очереди в описании оказался шаблон проектирования Хранитель (Memento). На мой взгляд этот шаблон достаточно просто реализовать, по крайней мере его идеологическая суть ясна многим без детальных объяснений.

Для реализации шаблона в АОП стиле я буду использовать коммерческий продукт PostSharp. Скорее всего описанные подходы вы сможете использовать и с другими АОП фреймворками, просто это будет чуть более многословное и не столь удобное в вопросе продолжительного использования решение.

Для этого шаблона я не вижу каких-либо особенностей реализации, которые должны быть специально упомянуты с самого начала, поэтому перечисление всяческих бонусов от АОП, как в случае с Одиночкой, будет опущено.

Общая информация

Для полноты картины, я считаю, что надо все так же привести основные характеристики и назначение шаблона.

Хранитель относится к категории Поведенческих шаблонов.

Намерение

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

Суть

Сохранить состояние объекта, и иметь возможность вернуться к исходному состоянию, не раскрывая своего содержимого внешнему миру.

Очень важным моментом является — «не раскрывая своего содержимого внешнему миру» — это суть инкапсуляции и ООП. В качестве быстрого примера, могу привести пример с объектом, который получает при конструировании уникальный номер. Этот номер нельзя никак задать с помощью публичного API. При восстановлении объекта из Memento есть доступ к внутренним полям и эта операция пройдет абсолютно честно и просто.

Реализация

Классическая реализация говорит о следующих особенностях реализации шаблона:

  • Необходимо создать класс-хранитель «мгновенных снимков» целевого класса
  • Целевой класс должен уметь сохранять и принимать свои «мгновенные снимки»

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

memento

Подробнее

Шаблон Одиночка в реализации AOP

Любое больше дело лучше начинать с чего-то простого, чтобы простой войти во вкус. Я считаю, что рассмотрение реализации всех шаблонов с помощью Аспектно-Ориентированного Подхода (АОП) лучше всего начать с шаблона Singleton – как самого простого в понимании. В этой статье я не буду затрагивать вопросы в чем хорош шаблон, в чем плох, почему некоторые считают, что это уже анти-шаблон, который уже совсем не стоит использовать в чистом виде как есть. Всю эту информацию можно сравнительно легко найти на просторах интернета. Я же хочу посмотреть, как будет отличаться реализация шаблона в АОП стиле от, скажем так, классической.

Для реализации шаблона в АОП стиле я буду использовать коммерческий продукт PostSharp. Скорее всего описанные подходы вы сможете использовать и с другими АОП фреймворками, просто это будет чуть более многословное и не столь удобное в вопросе продолжительного использования.

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

  • Проверка правильности шаблона с точки зрения дизайна. За это отвечает архитектурный фреймворк в составе PostSharp.
  • Легкая работа с многопоточными моделями. Это важно в контексте создания объекта Одиночки.
  • Легкая навигация и подсветка используемых аспектов в самой Visual Studio.

 

Общая информация

Для полноты картины, я считаю, что надо снова привести основные характеристики и назначение шаблона.

Намерение

Лучше, когда некоторые объекты представлены только в одном экземпляре, для того, чтобы избежать путаницы и хаоса. Например, единая бухгалтерская книга, правительство, спулер принтеров. Когда таких объектов больше одного, то могут и часто возникают неприятные ситуации, которые ведут к нарушению целостности данных, трудностям с понимании логики работы в run-time.

Суть

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

Реализация

Каноническая реализация говорит о следующих особенностях реализации шаблона:

  • Все конструкторы должны быть приватными.
  • Доступ к объекту осуществляется через статическое поле.
  • Объект создается в момент первого обращения и в дальнейшем отдается один и тот же объект.

Вот в целом и все нехитрые особенности реализации. В UML нотации шаблон выглядит следующим образом:

singleton

Подробнее

АОП и шаблоны проектирования GoF

Давно меня занимает тема аспектно-ориентированного программирования в виду моей исключительной профессиональной лени. Мне не нравится писать тупой и повторяющийся код. Однако это словно родовое проклятье, когда дело касается разных инфраструктурных вещей при написании кода. Начиная с банального и уже набившего оскомину при упоминании АОП – логировния и заканчивая кэшировнием и реализацией особенного процесса по перехвату исключений. Аспекты могут быть применены к гораздо большему спектру задач. К неочевидному на первый взгляд спектру задач, о котором большинство даже не задумывается. Например, шаблоны проектирования «банды четырех».

Конкретная реализация с помощью аспектов сильно зависит от АОП фреймворка. Например, к какому типу он относится: прокси или внедрения в код. Я свой выбор остановил на PostSharp, с которым знаком с версии 1.2 или 1.3, мне кажется было что-то около этого. И то, что было тогда и есть сейчас — значительно отличается по функционалу и простоте использования. Не в малой степени благодаря эволюции самого языка C#.

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

Подробнее

SoftLab.NET 2014

20 Декабря была веб-конференция SoftLab.NET 2014 компании Luxoft на которой я рассказывал про Threading Pattern Library из комплекта поставки PostSharp. Эта библиотека шаблонов действительно упрощает работу с многопоточностью. В следующем году я хочу подробно про это написать, так как там много нюансов обнаруживается, но сейчас краткий обзор доступен в презентации.

Hard’n’Heavy!

Цикл статей про PostSharp

Всем привет!

Хочу всех успокоить и сказать, что статьи будут. Но пока что не могу ими занятся, так как занят подготовкой к web-конференции SoftLab.NET, которая совершенно бесплатная, но надо зарегистрироваться заранее, чтобы заказать нужный пул подключений на площадке. Там я буду рассказывать про модели многопоточности и как их можно контролировать/валидировать с помощью PostSharp.

Обещаю, что еще до нового года появятся статьи про шаблоны проектирования.

До скорой встречи!

Hard’n’Heavy!

PostSharp v3

 

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

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

Начиная с третьей версии, существует 3 набора подписок: community, professional и ultimate. Самая продвинутая стоит сейчас со всеми скидками, с учетом RC версии и раннего заказа 800$. При этом ранее бесплатные тулкиты по INPC и управлению потоками перешли в Ultimate версию, а даже не в Professional. Ранее полная версия стоила 150-200$, что было в целом более-менее адекватно с учетом предоставляемых возможностей. Но сейчас цена, на мой взгляд несколько неадекватна тому, что предлагается за нее.

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

С выходом Roslyn многие вещи из Ultimate пакета стали доступны бесплатно, разве что стоит приложить чуть больше усилий для их реализации. Но написав однажды несколько методов помощников, можно многие вещи делать быстро, так что опять же цена и включение возможностей многих только в Ulitmate версию сомнительны весьма.

Далее, есть проблемы при использовании PostSharp и MEF, которые пока что никак не решаются в RC версии и не думаю, что они будут разрешены позднее. MEF не может в своем контексте загрузить сборки PostSharp и аспекты не распознаются.

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

Professional версия, которая включает все аспекты и подходит для существующих платформ требует от вас раскошелится на 500$, что тоже не вот какая маленькая стоимость, честно сказать. Я наверно мог бы заплатить 200$ за полную версию, но…

Еще меня поразило, что удалили или же закрыли от публики форум! Т.е. теперь нельзя свободно задать вопросы и найти ответы от других пользователей.

В общем развитие PostSharp меня несколько разочаровало. Очень печально, что столь многообещающий и интересный продукт пошел по такому пути.