Статья родилась из того, что мне потребовался удобный и простой механизм перехвата для некоторых задач, который легко реализуется техниками АОП. Существует довольно много перехватчиков (Casle.net, Spring.net, LinFu и т.д.), требующих внедрять динамические дочерние классы в IL-код во время исполнения и приводящих практически всегда к одним и тем же ограничениям, накладываемым на перехватываемые классы: не статические, не запечатанные, методы и свойства должны быть виртуальными и т.д…

Другие механизмы перехвата требовали изменения процесс сборки или покупки лицензии. Ни то ни другое я себе позволить не мог…

Я стараюсь не спорить о преимуществах / недостатках ООП или процедурного подхода, безразлично где.

Хочешь — рассматривай программу как множество функций. Хочешь — как множество объектов. Хочешь — вообще заморочься на аспектах. А ещё есть товарищ Шалыто и его конечные автоматы. Дело-то хозяйское.

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

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

После определения, в любом случае, не стоит забывать про рефакторинг (тут выскакивает Мартин Фаулер, и кричит — Нюхай свой код! Определяй запахи!). Больше всего рефакторинга в ООП, но и функции тоже можно рефакторить.

Дальше — больше: вспоминаются паттерны, которые представляют собой шаблонные методы обхода насущных проблем языка и решения архитектурных заморочек. Где паттерны — там GOF и Фаулер с POEAA. Затем всплывает TDD, с его написанием тестов перед написанием кода. Дальше — ещё больше, там будут горы непонятных аббревиатур и леса методологий.

На подобные темы писалось, пишется и будет писаться много.

Но нет серебряной пули.

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

Довольно популярная в мире Java парадигма аспектно-ориентированного программирования (АОП) почему-то слабо освещена в разработке на PHP. В данной статье я хочу представить свой подход к написанию АОП приложений с использованием небольшого фреймворка и модуля.

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

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

Технологии реализации AOP в PHP

Волшебные методы

Самое простое решение — использование «волшебных методов» __call и __callStatic. Эти методы вызываются (если они определены в классе) при обращении к несуществующему методу класса. В качестве аргументов они получают имя несуществующего метода и переданные ему параметры.
В данном случае, приложение строится таким образом, что реальные методы имеют имя отличное от имени указанном в вызывающих их конструкциях. Сквозной функционал реализуется в «волшебных методах», которые, при необходимости, передают управление реальным методам классов.

Плюсы:

• Легко начать использовать;
• Реализация не требует дополнительных модулей (нативный PHP).

Минусы:

• Не удобно использовать при большом количестве сквозного функционала;
• Т.к. имена методов в определении и в вызовах различаются, создаются трудности при использовании автодополнения кода в IDE.

Предварительный разбор кода

Этот способ подразумевает наличие посредника, позволяющего использовать «синтаксический сахар». Необходимый функционал описывается вспомогательным синтаксисом (xml/json конфигурация, дополнительные php-классы или аннотации в коде), который разбирается посредником. На основе разбора генерируется результирующий код, который содержит вставки сквозного функционала в необходимые места.

Плюсы:

• Работает быстро, т.к. на выходе это обычный PHP-код, просто сгенерированный за Вас автоматически.

Минусы:

• Сложно внедрить в большой проект;
• Требуется разбор кода после каждого изменения, для внесения корректировок в результирующий код.

Замена кода приложения во время выполнения

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

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

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

Доброго времени суток, Хабр!

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

Проблема

Итак, суть приложения примерно такова: есть gateway — api, который принимает запрос, а в дальнейшем модифицирует и перенаправляет его соответствующему банку. Вот только запрос для каждого из банков отличался — как и параметры валидации. Поэтому валидировать изначальный запрос не представлялось возможным. Тут было два пути — использовать аннотации из javax.validation, либо писать свой отдельный слой валидации. В первом случае была загвоздка — по умолчанию объекты можно валидировать только в контроллере. Во втором случае так-же были минусы — это лишний слой, большое количество кода, да и в случае изменения моделей, пришлось бы менять и валидаторы.

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

Дергаем валидаторы

Спустя пару часов копания в гугле были найдены пару решений, самое адекватное из которых было заавтовайрить javax.validation.Validator и вызвать у него метод validate, которому в качестве параметра нужно передать валидируемый объект.

Казалось бы, решение найдено, но автовайрить везде валидатор не казалось хорошей идеей, хотелось более элегантного решения.

Добавляем АОП

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

Логика была примерно следующей: создаём аннотацию, и вешаем её над методом который преобразует один объект в другой. Дальше в аспекте перехватываем все методы помеченные этой аннотацией и вызываем метод validate для возвращаемого ими значения. Профит.

Введение

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

Многие .NET разработчики знают, что для доступа к объектам чужой сборки можно использовать Reflection. С помощью типов из System.Reflection мы можем получить доступ ко многим объектам .NET сборки, просмотреть их метаданные, и даже использовать те объекты, доступ к которым ограничен (например, private методы чужого класса). Но использование Reflection имеет свои ограничения и главная причина этому — данные, с котороми вы работаете через Reflection, все еще считаются кодом. Таким образом, вы, к примеру, можете получить CodeAccessSecurity exception, если сборка, к которой вы пытаетесь применить Reflection, запрещает это. По этой же причине Reflection работает довольно медленно. Но наиболее важным для данной статьи является то, что стандартный Reflection не позволяет изменять существующие сборки, только генерировать и сохранять новые.

Mono.Cecil

Качественно иной подход предлагает бесплатная библиотека с открытым исходным кодом Mono.Cecil. Главное отличие подхода Mono.Cecil от подхода Reflection в том, что данная библиотка работает с NET сборкой как с потоком байт. При загрузке сборки, Mono.Cecil разбирает PE заголовок, CLR заголовок, MSIL код классов и методов и т.д. работая напрямую с потоком байтов, представляющим сборку. Таким образом, с помощью данной библиотеки можно как угодно (в пределах предусмотренного) изменять имеющуюся сборку.

Аспектно-ориентированное программирование

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

PostSharp

Фреймворк PostSharp — это реализация аспектно-ориентированного подхода для .NET. PostSharp в отличие от многих своих аналогов работает как пост-компилятор, то есть он вносит изменения в MSIL (Microsoft Intermediate Language).
PostSharp позволяет легко создавать атрибуты, которые меняют поведение методов, полей и типов. Для этого нужно унаследовать класс атрибута от одного из предоставляемых библиотекой базовых классов, реализовать его виртуальные методы и применить этот атрибут.

В моем разговоре с Андресом Хейлсбергом о страхах, неуверенности и сомнений относительно Аспектно-Ориентированного программирования я упомянул про общую путаницу и непонимание что АОП и DI – это конкурирующие концепции. В этой статье я попробую объяснить вам обо всех различиях и сходствах в этих двух подходах.Недавно я прекрасно провел время за чтением статьи Дино Эспосито: «Аспектно-ориентированное программирование, interception и unity 2.0», в декабрьском номере MSDN Magazine. Это великолепная статья и я настоятельно советую любому разработчику, вовлеченному в .NET разработку прочитать ее полностью. Как и многие DI фреймворки, и некоторые основные фреймворки (WCF, ASP.NET MVC), Unity предлагает похожую на АОП возможность: interceptors.

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

В реальной жизни мы повсюду сталкиваемся с различными контрактами: при устройстве на работу, при выполнении работ, при подписании взаимных соглашений и многими другими. Юридическая сила контрактов гарантирует нам защиту интересов и не допускает их нарушения без последствий, что дает нам уверенность в том, что те пункты, которые описаны в контракте — будут выполнены. Эта уверенность помогает нам планировать время, планировать расходы, а также планировать необходимые ресурсы. А что если и программный код будет описываться контрактами? Интересно? Тогда добро пожаловать под кат!

Поддавшись общей истерии на хабре,

(а именно «Предупреждаю Недвижимость Изменился» переводит Гуглекс всеми любимый «I Notify Property Changed») по поводу уведомлений об изменении. Я решил посмотреть на сколько далеко продвинулось человечество в изобретении велосипедов.

Всем привет!

Закончили в этом месяце первый набор курса «Backend разработчик на PHP» и трудоустраиваем их вовсю (ну насколько это возможно в пору отпусков). Курс пополнился ещё одним преподавателем — Евгением Волосатовым, которого многие, наверное, знают. Ну, а мы традиционно делимся интересными вещами.

Поехали.

В любом приложении есть части кода, “пересекающие” несколько частей архитектуры одновременно.

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

Аспектно-ориентированное программирование (АОП) — это парадигма программирования являющейся дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Идея АОП заключается в выделении так называемой сквозной функциональности. И так все по порядку, здесь я покажу как это сделать в Java — Spring @AspectJ annotation стиле (есть еще schema-based xml стиль, функциональность аналогичная).

Выделении сквозной функциональности

До



и после



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

Join point