Façade and AOP

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

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

facade_aop

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

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

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

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

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

 

Hard’n’Heavy!

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

Вторым на очереди в описании оказался шаблон проектирования Хранитель (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!

Async\Await методы и PostSharp

Сложность 300-400

Описание проблемы

Уже много чего написал насчет PostSharp, конкретных решений, кастом компонентов, общие принципы работы. Однако с выходом .Net 4.5 появилась новая фича со специальными словами async\await которые позволяют более просто и компактно описывать асинхронное поведение методов. Новый функционал хорош, но добавляет головной боли при использовании PostSharp, с методами помеченными async, использование классических аспектов не пройдет. Методы с маркером async разворачиваются в машину состояний, что не очень хорошо с точки зрения применения аспектов. Т.е. возьмем стандартную реализацию аспекта трассировщика с помощью  PostSharp:

И применим его к тестовому примеру с вызовом синхронных и асинхронных методов с исключениями и без:

Результат выполнения программы представлен ниже, и для большей наглядности я разукрасил выводы для каждого метода.

Подробнее

Notification Bar Overview

Сложность 100-200

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

Идея создания

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

Архитектура приложения была построена так, что с долгой операцией (расчетами) связанной с базой данных был связан Id, который переписывался для каждого такого действия с базой, получается что в один момент можно было делать только одно большое действие и не переходить с экрана, для того, чтобы в конце концов узнать результат работы.

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

Получается, что есть два желания, которые коррелируют друг с другом очень хорошо, по крайней мере лучше, чем идеи в фильме Super 8. А так как идеи достаточно давно вынашивались и могла появится конкретная польза, то я решил реализовать всё не отдавая себя прокрастинации.

Итак, основная идея:

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

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

Подробнее

Notification Bar Overview Video

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

Notification Bar Overview

Валидация свойств с помощью атрибутов в WPF

Сложность 200-300

Уже очень давно меня не оставляет мысль о глобальной несправедливости для WPF в плане валидации свойств по сравнению с ASP.NET. Какое-то время хотелось даже самому взяться за это дело, но внутренне я понимал, что это не у меня одного такое ощущение и должны быть где-то уже реализации данного функционала в удобной и доступной форме, когда не нужно писать самому кучу кода, дополнительных свойств приаттаченых, или еще чего-нибудь в таком духе. Большинство статей на CodeProject по теме валидации свойств в WPF очень стары и предлагают написать очень много кода самому, но хочется ведь чтобы почти все стандартные простые проверки ввода уже работали из коробки.

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

Традиционный способ валидации

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

Подробнее

PostSharp Thread\Dispatcher Toolkit

Сложность 100

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

Итак, сегодня в программе тулкит, который позволяет с помощью атрибутов указать выполнение метода в отдельном потоке, а так же указать какие методы вызывать в потоке UI. Собственно вот и весь функционал.

О том как решаются эти проблемы в «традиционном» стиле, я рассказывал в статье про эволюцию сервисных методов, там же описана библиотека MakeMeAsync, которой я с удовольствием и активно пользуюсь на данный момент. Не буду повторятся какие альтернативы существуют. Сейчас уже официально выпущен .Net Framework 4.5 c поддержкой конструкции async\await, так что я надеюсь что использование монструозных конструкций для выполнения кода асинхронно будет сходить на нет.

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

Подробнее