Полезно ли аспектно-ориентированное программирование для обеспечения реализаций интерфейсного программирования?

Question

Мне было просто любопытно на эту тему. Я никогда не использовал аспектно-ориентированное программирование (намеренно), и у меня мало знаний об этом.

Вот мой вопрос (используя регистрацию как типичный вариант использования):

Если у меня есть существующая парадигма интерфейса, например, рассмотрим псевдокод

class MyClass implements Loggable {

  // Logable Implementation
  string Log() { return somelogstring;}
}

Может ли аспектно-ориентированное программирование использоваться вместе с этим, как

class MyClass implements Loggable with LoggingAspect {

  // No explicit Loggable implemenation
}

Это то, что будет считаться АОП? Если так, то это правильный способ его использования?

Answer 1

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

Обычно это реализуется путем вставки поведения вокруг существующего кода. В ОО такие аспекты могут быть применены посредством шаблона прокси. Большинство платформ C # и Java AOP генерируют прокси-класс во время выполнения на основе метаданных в целевом классе и вызывают выполнение некоторого кода до и после указанных методов.

Многие контейнеры IoC предоставляют функциональные возможности для присоединения этих аспектов, и концепции аспектов, перехвата методов и внедрения зависимостей сложнее различить, чем когда-то.

Answer 2

AOP был создан для реализации сквозных задач (таких как ведение журнала), проблем, которые «прорезают» различные модули вашего приложения. Например, если вы реализуете Logging с AspectJ, у вас будет такой аспект:

public aspect Logging(){

    pointcut traceMethods()  : (execution(* *.*(..)) && !within(Logging);

    before(): traceMethods() {
         // Perform log here!
    }

}

Этот код реализует функциональность журнала перед выполнением всех классов вашего приложения. Таким образом, он вставит поведение входа в некоторые классы, которые вы хотите. Чтобы указать, какие классы будут затронуты журналированием, вы должны определить pointcut (или набор pointcus). В этом примере pointcut - это traceMethods ().

Думая об интерфейсах, вы должны посмотреть на эту ссылку, которая объясняет объявления между типами . Эти объявления могут быть использованы для «реализации» чего-то вроде интерфейсов с использованием AspectJ.

Answer 3

На каком языке вы здесь говорите?

И нет, это не так, как обычно выполняется AOP, и, вероятно, невозможно в языках с такими платформами (C #, .NET).

То, о чем вы здесь говорите, - это этап перед сборкой, т. Е. У вас есть код, который сейчас не компилируется, и вам нужно его скомпилировать перед отправкой фактическому компилятору ... AKA для генерации кода. генерация кода - это хорошая вещь, и для нее есть фреймворки на разных языках (опять же, скажите нам, на каком языке).

Но это АОП? Нет.

AOP - это внедрение функциональности в уже существующие методы. То есть «зацепка» функций / действий и т. д.

Answer 4

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

AOP работает, перехватывая вызовы методов на объектах и ​​выполняя некоторые действия в дополнение или вместо действий, выполняемых перехваченным методом. Точки перехвата известны как pointcuts, а метод перехвата является рекомендуемым методом, а код, рекомендованный для перехваченного метода, называется советом.

Я знаком с AOP только через AOP Framework Spring.Net, который позволяет вам задавать и применять pointcuts и советы как через файлы конфигурации, так и программно. Spring.Net AOP имеет четыре типа рекомендаций: до, после, вокруг и броски, которые вызываются при перехвате рекомендованного метода до вызова рекомендованного метода, после его вызова, как до, так и после его вызова, и когда выбрасывается исключение соответственно. Применяется ли это с помощью конфигурации или программно, рекомендуемый метод не знает о Spring.Net AOP или даже о том, что он был рекомендован. Однако рекомендуемый метод должен иметь какую-то реализацию для перехвата, чтобы ваш пример не работал.

Документация Spring.Net очень удобочитаема и хорошо объясняет AOP в целом и реализацию AOP Spring.Net в частности и содержит много примеров. Это стоит посмотреть, даже если немного лучше понять АОП.