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

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

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

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

Использование аспектов позволяет значительно облегчить применение шаблонов проектирования, примерно в половине случаев – в 12 из 23 шаблонов – полностью вынести ядро шаблона в отдельный класс, который получается независим от предметной области, от домена применения. Т.е. реализовав шаблон один раз можно его таскать из проекта в проект как отдельную сборку и экономить огромное количество времени и сил. Как на разработку, так и на поддержание.

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

Я вижу несколько основных плюсов от того, что шаблоны будут реализованы с помощью аспектов:

  • Возможность реального повторного использования кода реализации шаблона
  • Проверка корректности использования шаблона
  • Легкость смены\внесения\удаления шаблонов

На мой взгляд это уже большой прогресс и достойная причина к использованию шаблонов в виде аспектов.

Среди минусов мне видится разве только:

  • Чуть менее производительный код

Здесь хочется еще раз сделать ремарку по поводу производительности работы программ. Производительность не характеристика самой модели, а характеристика использования модели в конкретной ситуации. Чаще всего затык в скорости работы программы заключен в неправильном выделении структур данных и неверном построении потока выполнения программы. Грубо говоря плохо спроектированные классы, которые делают много лишних действий. Это основная причина медленной работы программ, а не boxing\unboxing, конкатенация строк и прочие вещи, которые нужны только для реально быстрых программ. В них уже и читаемость и шаблоны, и неповторяемость кода приносится в жертву быстродействию. Мы же говорим об энтерпрайзе, где программы живут дольше, чем разработчики работают в компаниях.

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

gregyoung_cit01

И это именно то, что можно делать с большей частью кода шаблонов с помощью PostSharp.

 

Не могу не назвать источники, откуда я буду брать основные идею по поводу того, как реализованы те или иные шаблоны в Java с помощью AspectJ:

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

 

Так же хочу сказать, что у меня пока что нет плана, в каком я буду реализовывать шаблоны. Буду наверно с самых простых =), чтобы хотя бы с чего-то начать.

 

 

Hard’n’Heavy!

 

 

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

  1. Советую ознакомиться с книгой Александра Шевчука, Дмитрия Охрименко, Андрея Касьянова » Шаблоны проектирования » — itvdn.com/ru/patterns

Оставить комментарий