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

В вычислительной технике аспектно -ориентированное программирование ( АОП ) — это парадигма программирования , целью которой является повышение модульности за счет разделения сквозных задач . Это делается путем добавления поведения к существующему коду ( рекомендация ) без изменения кода, вместо этого отдельно указывая, какой код изменяется, с помощью спецификации « pointcut », например «регистрировать все вызовы функций, когда имя функции начинается с 'set ' ». Это позволяет добавлять в программу поведение, которое не является центральным для бизнес-логики (например, ведение журнала), не загромождая код основных функций.

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

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

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

Все реализации АОП имеют несколько сквозных выражений, которые инкапсулируют каждую задачу в одном месте. Разница между реализациями заключается в мощности, безопасности и удобстве использования предоставляемых конструкций. Например, перехватчики, которые определяют методы для выражения ограниченной формы сквозного взаимодействия без особой поддержки безопасности типов или отладки. AspectJ имеет ряд таких выражений и инкапсулирует их в специальный класс, называемый аспектом . Например, аспект может изменить поведение базового кода (неаспектной части программы), применяя рекомендации (дополнительное поведение) в различных точках соединения (точках программы), указанных в количественной оценке или запросе, называемом pointcut ( который определяет, соответствует ли данная точка соединения). Аспект также может вносить структурные изменения, совместимые с двоичным кодом, в другие классы, например добавлять членов или родителей.

История [ править ]

АОП имеет несколько прямых предшественников A1 и A2: ^[1] отражения и метаобъектов протоколы , предметно-ориентированное программирование , композиционные фильтры и адаптивное программирование. ^[2]

Грегор Кичалес и его коллеги из Xerox PARC разработали явную концепцию АОП и последовали ее примеру, выпустив расширение AspectJ AOP для Java. Исследовательская группа IBM предпочла инструментальный подход подходу к языковому проектированию и в 2001 году предложила Hyper/J и Concern Manipulation Environment , которые не нашли широкого применения.

В примерах в этой статье используется AspectJ.

Сервер транзакций Microsoft считается первым крупным приложением АОП, за которым следует Enterprise JavaBeans . ^[3]^[4]

Мотивация и основные понятия [ править ]

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

Например, рассмотрим банковское приложение с концептуально очень простым методом перевода суммы с одного счета на другой: ^[5]

недействительный   перевод  (  Account   fromAcc  ,   Account   toAcc  ,   int   sum  )   выдает   исключение   { 
   if   (  fromAcc  .  getBalance  ()   <   сумма  ) 
       выбрасывает   новое   InsufficientFundsException  (); 

    из Акк  .  снятия  )   Сумма  ; 
    toAccc  .  вклада  )   сумма  ; 
  }

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

Версия со всеми этими новыми проблемами может выглядеть так:

void   Transfer  (  Учетная запись   fromAcc  ,   Учетная запись   toAcc  ,   int   сумма  ,   Пользователь-пользователь   ,  Регистратор 
     журнала   ,  База   базы данных   данных  )   выдает   исключение   { 
   logger  .   info  (  "Перевод денег..."  ); 
  
    если   (  !  isUserAuthorized  (  пользователь  ,   fromAcc  ))   { 
     logger  .   info  (  "У пользователя нет разрешения."  ); 
      выбросить   новое   исключение UnauthorizedUserException  (); 
    } 
  
   Если   (  fromAcc  .  getBalance  ()   <   сумма  )   { 
     logger  .   info  (  "Недостаточно средств."  ); 
      выбросить   новое   исключение InsufficientFundsException  (); 
    } 

   из Акк  .  снятия  )   Сумма  ; 
    toAccc  .  вклада  )   сумма  ; 

    база данных  .   совершитьИзменения  ();     // Атомная операция. 

    регистратор  .   info  (  "Транзакция успешна."  ); 
  }

В этом примере другие интересы переплелись с базовой функциональностью (иногда называемой проблемой бизнес-логики ). Транзакции, безопасность и ведение журналов — все это примеры сквозных проблем .

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

АОП пытается решить эту проблему, позволяя программисту выражать сквозные задачи в автономных модулях, называемых аспектами . Аспекты могут содержать советы (код, присоединенный к указанным точкам программы) и объявления межтиповых типов (структурные элементы, добавляемые к другим классам). Например, модуль безопасности может включать в себя рекомендации, выполняющие проверку безопасности перед доступом к банковскому счету. Pointcut . определяет время ( точки соединения ), когда можно получить доступ к банковскому счету, а код в теле рекомендации определяет, как реализуется проверка безопасности Таким образом, и чек, и места могут храниться в одном месте. Кроме того, хороший pointcut может предвидеть последующие изменения в программе, поэтому, если другой разработчик создаст новый метод доступа к банковскому счету, совет будет применен к новому методу при его выполнении.

Итак, для примера выше, реализующего ведение журнала в аспекте:

аспект   Logger   { 
   void   Bank  .   Transfer  (  Учетная запись   fromAcc  ,   Учетная запись   toAcc  ,   int   sum  ,   Пользователь-   пользователь  ,   Logger   logger  )    { 
     logger  .   info  (  "Перевод денег..."  ); 
    } 

   Недействительный   банк  .   getMoneyBack  (  пользователя   Пользователь  ,   inttransactionId    ,   Logger   logger  )    { 
     logger  .   info  (  "Пользователь запросил возврат денег."  ); 
    } 

   // Другой сквозной код. 
  }

Можно думать об АОП как об инструменте отладки или инструменте пользовательского уровня. Рекомендации следует оставить для случаев, когда невозможно изменить функцию (уровень пользователя). ^[6] или не хотите менять функцию в рабочем коде (отладка).

Модели точек соединения [ править ]

Компонент аспектно-ориентированного языка, связанный с рекомендациями, определяет модель точки соединения (JPM). JPM определяет три вещи:

Когда совет может работать. Они называются точками соединения , потому что это точки в работающей программе, к которым можно с пользой присоединить дополнительное поведение. Чтобы быть полезной, точка соединения должна быть адресуемой и понятной обычному программисту. Он также должен быть стабильным при незначительных изменениях программы, чтобы поддерживать стабильность аспектов. Многие реализации АОП поддерживают выполнение методов и ссылки на поля в качестве точек соединения.
Способ указания (или количественной оценки ) точек соединения, называемый pointcuts . Pointcuts определяют, соответствует ли данная точка соединения. Большинство полезных языков pointcut используют синтаксис, подобный базовому языку (например, AspectJ использует сигнатуры Java) и допускают повторное использование посредством именования и комбинации.
Средство указания кода для запуска в точке соединения. AspectJ вызывает этот совет и может запускать его до, после и вокруг точек соединения. Некоторые реализации также поддерживают определение метода в аспекте другого класса.

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

Модель точек соединения AspectJ [ править ]

Точки соединения в AspectJ включают вызов или выполнение метода или конструктора, инициализацию класса или объекта, доступ для чтения и записи полей, а также обработчики исключений. Они не включают циклы, супервызовы, предложения throw или несколько операторов.
Срезы задаются комбинацией примитивных указателей срезов (PCD).
«Родственные» PCD соответствуют определенному типу точки соединения (например, выполнению метода) и часто принимают в качестве входных данных Java-подобную сигнатуру. Одна из таких точек выглядит так:
```
выполнение  (  *   набор  *  (  *  )) 
```
Этот pointcut соответствует точке соединения выполнения метода, если имя метода начинается с « set" и существует ровно один аргумент любого типа.
«Динамические» PCD проверяют типы времени выполнения и переменные привязки. Например,
```
эта  точка   ) 
```
Этот pointcut соответствует тому, когда выполняющийся в данный момент объект является экземпляром класса. Point. Обратите внимание, что неполное имя класса можно использовать при обычном поиске типов в Java.
«Область» PCD ограничивает лексическую область действия точки соединения. Например:
```
в пределах  (  com  .  компания  .  *  ) 
```
Этот вырез соответствует любой точке соединения любого типа в com.companyупаковка. * — это одна из форм подстановочных знаков, которую можно использовать для сопоставления множества вещей с одной подписью.
Pointcuts можно составлять и называть для повторного использования. Например:
```
pointcut   set  )   :   выполнение  (  *   set  *  (  *  )   )   &&   this  (  Point  )   &&   внутри  (  com.company  .  (  *  )  ; 
```
Этот pointcut соответствует точке соединения выполнения метода, если имя метода начинается с « set" и this является экземпляром типа Point в com.companyупаковка. На него можно ссылаться, используя имя " set()".
Совет указывает на запуск (до, после или вокруг) точки соединения (указанной с помощью точки) определенного кода (указанного как код в методе). Среда выполнения AOP автоматически вызывает Advice, когда pointcut соответствует точке соединения. Например:
```
after  ()   :   set  ()   { 
   Display  .   обновлять  (); 
  } 
```
Это фактически указывает: «если set() pointcut соответствует точке соединения, запустите код Display.update() после завершения точки соединения».

точек соединения модели Другие потенциальные

Существуют и другие виды JPM. Все языки рекомендаций можно определить с точки зрения их JPM. Например, гипотетический аспектный язык для UML может иметь следующий JPM:

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

Межтиповые объявления [ править ]

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

  аспект   DisplayUpdate   { 
     void   Point  .   AcceptVisitor  (  Посетитель   v  )   { 
       v  .   посетить  (  это  ); 
      } 
     // другой пересекающийся код... 
   }

Этот фрагмент кода добавляет acceptVisitor метод к Point сорт.

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

Реализация [ править ]

Программы АОП могут влиять на другие программы двумя разными способами, в зависимости от базовых языков и сред:

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

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

Системы могут реализовать переплетение на уровне исходного кода с использованием препроцессоров (поскольку C++ изначально был реализован в CFront ), которые требуют доступа к исходным файлам программы. Однако четко определенная двоичная форма Java позволяет разработчикам байт-кода работать с любой программой Java в форме файла .class. Ткачи байт-кода могут быть развернуты во время процесса сборки или, если модель переплетения является поклассовой, во время загрузки классов. AspectJ начал с плетения на уровне исходного кода в 2001 году, в 2002 году представил ткач байт-кода для каждого класса и предложил расширенную поддержку во время загрузки после интеграции AspectWerkz в 2005 году.

Любое решение, которое объединяет программы во время выполнения, должно предоставлять представления, которые правильно их разделяют, чтобы поддерживать разделенную модель программиста. Поддержка байт-кода Java для нескольких исходных файлов позволяет любому отладчику пройти через правильно составленный файл .class в редакторе исходного кода. Однако некоторые сторонние декомпиляторы не могут обрабатывать плетеный код, поскольку они ожидают кода, созданного Javac, а не всех поддерживаемых форм байт-кода (см. также § Критика ниже).

Переплетение во время развертывания предлагает другой подход. ^[7]По сути, это подразумевает постобработку, но вместо исправления сгенерированного кода этот подход создает подклассы существующих классов, так что изменения вносятся путем переопределения метода. Существующие классы остаются нетронутыми даже во время выполнения, а все существующие инструменты, такие как отладчики и профилировщики, можно использовать во время разработки. Подобный подход уже зарекомендовал себя при реализации многих серверов приложений Java EE , таких IBM WebSphere как .

Терминология [ править ]

Стандартная терминология, используемая в аспектно-ориентированном программировании, может включать:

Сквозные проблемы: Основная статья: Сквозная проблема
Несмотря на то, что большинство классов в объектно-ориентированной модели выполняют одну конкретную функцию, они часто имеют общие второстепенные требования с другими классами. Например, мы можем захотеть добавить ведение журнала в классы на уровне доступа к данным, а также в классы на уровне пользовательского интерфейса всякий раз, когда поток входит в метод или выходит из него. Дополнительные проблемы могут быть связаны с безопасностью, например контролем доступа. ^[8] или управление информационными потоками . ^[9] Несмотря на то, что каждый класс имеет совершенно разные основные функции, код, необходимый для выполнения второстепенных функций, часто идентичен.

Совет: Основная статья: Советы (программирование)
Это дополнительный код, который вы хотите применить к существующей модели. В нашем примере это код протоколирования, который мы хотим применять всякий раз, когда поток входит в метод или выходит из него:
Пойнткат: Основная статья: Pointcut
Это относится к моменту исполнения приложения, на котором необходимо применить сквозные аспекты. В нашем примере точка среза достигается, когда поток входит в метод, а другая точка достигается, когда поток выходит из метода.

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

Сравнение с другими парадигмами программирования [ править ]

Аспекты возникли из объектно-ориентированного программирования и рефлексивного программирования . Языки АОП имеют функциональность, аналогичную метаобъектным протоколам , но более ограниченную . Аспекты тесно связаны с такими концепциями программирования, как темы , примеси и делегирование . Другие способы использования парадигм аспектно-ориентированного программирования включают композиционные фильтры и подход гиперсрезов . По крайней мере, с 1970-х годов разработчики использовали формы перехвата и диспетчеризации исправлений, которые напоминают некоторые методы реализации АОП, но они никогда не имели той семантики, которую обеспечивают сквозные спецификации в одном месте. ^{[ нужна цитата ]}

Разработчики рассмотрели альтернативные способы разделения кода, такие как частичные типы C# , но в таких подходах отсутствует механизм количественной оценки, который позволяет достичь нескольких точек соединения кода с помощью одного декларативного оператора. ^{[ нужна цитата ]}

Хотя это может показаться несвязанным, при тестировании использование макетов или заглушек требует использования методов АОП, например, рекомендаций. Здесь взаимодействующие объекты представляют собой сквозную задачу с целью проверки. Таким образом, различные платформы Mock Object предоставляют эти функции. Например, процесс вызывает службу для получения суммы баланса. При тестировании процесса неважно, откуда берется сумма, а лишь то, что процесс использует баланс согласно требованиям. ^{[ нужна цитата ]}

Проблемы усыновления [ править ]

Программистам необходимо уметь читать и понимать код, чтобы предотвратить ошибки. ^[10] Даже при наличии надлежащего образования понимание сквозных проблем может быть затруднено без надлежащей поддержки для визуализации как статической структуры, так и динамического потока программы. ^[11]Начиная с 2002 года, AspectJ начала предоставлять плагины IDE для поддержки визуализации сквозных задач. Эти функции, а также поддержка аспектного кода и рефакторинг теперь стали обычным явлением.

Учитывая мощь АОП, логическая ошибка в выражении сквозных элементов может привести к повсеместному сбою программы. И наоборот, другой программист может изменить точки соединения в программе, например, переименовав или переместив методы, способами, которые автор аспекта не предвидел, и с непредвиденными последствиями . Одним из преимуществ модульной организации сквозных задач является возможность одному программисту легко влиять на всю систему. В результате такие проблемы проявляются в виде конфликта ответственности двух или более разработчиков за тот или иной сбой. АОП может ускорить решение этих проблем, поскольку необходимо изменить только аспект. Без АОП соответствующие проблемы могут быть гораздо более распространенными. ^{[ нужна цитата ]}

Критика [ править ]

Самая основная критика эффекта АОП заключается в том, что поток управления скрыт и что он не только хуже, чем широко критикуемый оператор GOTO , но и очень похож на шуточный оператор COME FROM . ^[11] Игнорирование application , которое является фундаментальным для многих определений АОП (в рассматриваемом коде нет указания на то, что будет применен совет, который вместо этого указан в pointcut), означает, что совет не виден, в отличие от явного вызов метода. ^[11]^[12] Например, сравните программу COME FROM: ^[11]

 5   INPUT   X 
 10   PRINT   'Результат:' 
 15   PRINT   X 
 20   COME   FROM   10 
 25        X   =   X   *   X 
 30   RETURN

с фрагментом АОП с аналогичной семантикой:

main  ()   { 
     input   x 
     print  (  result  (  x  )) 
 } 
 input   result  (  int   x  )   {   return   x   } 
 вокруг  (  int   x  ):   call  (  result  (  int  ))   &&   args  (  x  )   { 
     int   temp   =   continue  (  x  ) 
     возвращаемая   температура   *   температура 
 }

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

Общая критика заключается в том, что АОП претендует на улучшение «как модульности, так и структуры кода», но некоторые возражают, что вместо этого он подрывает эти цели и препятствует «независимой разработке и понятности программ». ^[13] В частности, количественная оценка с помощью точечных разрезов нарушает модульность: «как правило, необходимо обладать знаниями всей программы, чтобы рассуждать о динамическом выполнении аспектно-ориентированной программы». ^[14] Более того, хотя его цели (модуляция сквозных задач) хорошо понятны, его фактическое определение неясно и не отличается четко от других устоявшихся методов. ^[13] Сквозные проблемы потенциально пересекаются друг с другом, требуя определенного механизма разрешения, например упорядочивания. ^[13] Действительно, аспекты могут применяться к самим себе, что приводит к таким проблемам, как парадокс лжеца . ^[15]

Техническая критика включает в себя то, что количественная оценка точек (определяющая, где выполняются советы) «чрезвычайно чувствительна к изменениям в программе», что известно как проблема хрупкой точки . ^[13]Проблемы с точечными разрезами считаются неразрешимыми. Если заменить количественную оценку вырезов явными аннотациями, вместо этого получится атрибутно-ориентированное программирование , которое представляет собой просто явный вызов подпрограммы и сталкивается с той же проблемой рассеяния, для решения которой был разработан АОП. ^[13]

Реализации [ править ]

Многие языки программирования реализовали АОП внутри языка или в виде внешней библиотеки , в том числе:

Языки платформы .NET ( C# , Visual Basic (.NET) (VB.NET)) ^[16]
- PostSharp — это коммерческая реализация АОП с бесплатной, но ограниченной версией.
- Unity предоставляет API для упрощения проверенных методов в основных областях программирования, включая доступ к данным, безопасность, ведение журналов, обработку исключений и другие.
- AspectDN — это реализация АОП, позволяющая объединять аспекты непосредственно с исполняемыми файлами .NET.
ActionScript ^[17]
Есть ^[18]
Автогорячая клавиша ^[19]
С , С++ ^[20]
КОБОЛ ^[21]
Cocoa C Objective- Фреймворки ^[22]
Холодный синтез ^[23]
Общий Лисп ^[24]
Дельфи ^[25]^[26]^[27]
Делфи Призма ^[28]
е (IEEE 1647)
Эмакс Лисп ^[29]
классный
Хаскелл ^[30]
Джава ^[31]
- АспектJ
JavaScript ^[32]
Логток ^[33]
Два ^[34]
делать ^[35]
Матлаб ^[36]
МЛ ^[37]
Немерль ^[38]
Перл ^[39]
PHP ^[40]
Пролог ^[41]
Питон ^[42]
Ракетка ^[43]
Рубин ^[44]^[45]^[46]
Писк ^[47]^[48]
УМЛ 2.0 ^[49]
XML ^[50]

См. также [ править ]

Распределенный АОП
Грамматика атрибутов — формализм, который можно использовать для аспектно-ориентированного программирования на функционального программирования . языках
Парадигмы программирования
Предметно-ориентированное программирование , альтернатива аспектно-ориентированному программированию.
Ролевое программирование , альтернатива аспектно-ориентированному программированию.
Диспетчеризация предикатов , старая альтернатива аспектно-ориентированному программированию.
Исполняемый UML
Шаблон декоратора
Доменно-ориентированный дизайн

Примечания и ссылки [ править ]

^ Кицалес, Г. ; Лампинг, Дж.; Мендекар, А.; Маэда, К.; Лопес, К.; Лойнтье, Дж. М.; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF) . ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию . Конспекты лекций по информатике (LNCS). Том. 1241. С. 220–242. CiteSeerX 10.1.1.115.8660 . дои : 10.1007/BFb0053381 . ISBN 3-540-63089-9 . Архивировано (PDF) из оригинала 12 января 2016 г.
^ «Адаптивное объектно-ориентированное программирование: подход Деметры с шаблонами распространения» Карл Либхерр , 1996 г. ISBN 0-534-94602-X представляет собой хорошо проработанную версию, по сути, того же самого (Либерхерр впоследствии осознал это и переосмыслил свой подход).
^ Дон Бокс; Крис Селлс (4 ноября 2002 г.). Essential.NET: общеязыковая среда выполнения . Аддисон-Уэсли Профессионал. п. 206 . ISBN 978-0-201-73411-9 . Проверено 4 октября 2011 г.
^ Роман, Эд; Шриганеш, Рима Патель; Броуз, Джеральд (1 января 2005 г.). Освоение корпоративных JavaBeans . Джон Уайли и сыновья. п. 285. ИСБН 978-0-7645-8492-3 . Проверено 4 октября 2011 г.
^ Примечание. Синтаксис примеров в этой статье напоминает синтаксис языка Java .
^ «gnu.org» . Проект ГНУ. Архивировано из оригинала 24 декабря 2017 года . Проверено 5 мая 2018 г.
^ «Архивная копия» (PDF) . Архивировано из оригинала (PDF) 8 октября 2005 года . Проверено 19 июня 2005 г. {{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )
^ Б. Де Вин, Б. Ванот и Б. Де Декер. «Безопасность посредством аспектно-ориентированного программирования». В книге «Достижения в области безопасности сетей и распределенных систем» (2002 г.).
^ Т. Паскье, Дж. Бэкон и Б. Шанд. «FlowR: аспектно-ориентированное программирование для управления информационными потоками в Ruby». В материалах ACM 13-й международной конференции по модульности (аспектно-ориентированной разработке программного обеспечения) (2014).
^ Эдсгер Дейкстра , Заметки по структурированному программированию, заархивированные 12 октября 2006 г. в Wayback Machine , стр. 1-2
^ Перейти обратно: ^а ^б ^с ^д Константинидес, Константинос; Скотиниотис, Терапон; Штерцер, Максимилиан (сентябрь 2004 г.). АОП считается вредным (PDF) . Европейский интерактивный семинар по аспектам программного обеспечения (EIWAS). Берлин, Германия. Архивировано (PDF) из оригинала 23 марта 2016 г. Проверено 5 мая 2018 г.
^ C2: ComeFrom
^ Перейти обратно: ^а ^б ^с ^д ^Это Стейманн, Ф. (2006). «Парадоксальный успех аспектно-ориентированного программирования». Уведомления ACM SIGPLAN . 41 (10): 481–497. CiteSeerX 10.1.1.457.2210 . дои : 10.1145/1167515.1167514 . , ( слайды заархивированы 4 марта 2016 г. в Wayback Machine , слайды 2 заархивированы 23 сентября 2015 г. в Wayback Machine , реферат заархивирован 24 сентября 2015 г. в Wayback Machine ), Фридрих Стейманн, Гэри Т. Ливенс, OOPSLA 2006
^ «Более модульное рассуждение для аспектно-ориентированных программ» . Архивировано из оригинала 12 августа 2015 года . Проверено 11 августа 2015 г.
^ «АОП и антиномия лжеца» (PDF) . Fernuni-hagen.de . Архивировано (PDF) из оригинала 9 августа 2017 года . Проверено 5 мая 2018 г.
^ Многочисленные: Запоздалая мысль. Архивировано 15 марта 2016 г. на Wayback Machine , LOOM.NET. Архивировано 27 августа 2008 г. на Wayback Machine , Enterprise Library 3.0. Блок приложения внедрения политики. Архивировано 19 января 2007 г. на Wayback Machine , AspectDNG. Архивировано 9 сентября 2004 г. 29 в Wayback Machine , DynamicProxy. Архивировано 5 декабря 2015 г. в Wayback Machine , Compose*. Архивировано 21 августа 2005 г. в Wikiwix, PostSharp . Архивировано 3 мая 2016 г. в Wayback Machine , Seasar.NET. Архивировано 25 июля 2006 г. в Wayback Machine , DotSpect (.SPECT). Архивировано 31 марта 2006 г. в Wayback Machine , Spring.NET. Архивировано 2 апреля 2006 г. в Wayback Machine (как часть его функциональности), Wicca и Phx.Morph. Архивировано в 2006 г. 7 июля 2008 г. в Wayback Machine , SetPoint. Архивировано 7 октября 2008 г. в Wayback Machine.
^ «Добро пожаловать в as3-commons-bytecode» . as3commons.org . Архивировано из оригинала 3 октября 2014 года . Проверено 5 мая 2018 г.
^ «Обоснование Ada2012» (PDF) . adacore.com . Архивировано (PDF) из оригинала 18 апреля 2016 года . Проверено 5 мая 2018 г.
^ «Функциональные крючки» . autohotkey.com . Архивировано из оригинала 17 января 2013 года . Проверено 5 мая 2018 г.
^ Несколько: AspectC++ , FeatureC++ , AspectC. Архивировано 21 августа 2006 г. на Wayback Machine , AspeCt-ориентированный C. Архивировано 20 ноября 2008 г. на Wayback Machine , Aspicere.
^ «Булыжник» . vub.ac.be . Проверено 5 мая 2018 г. ^{[ постоянная мертвая ссылка ]}
^ «АспектКакао» . neu.edu . Архивировано из оригинала 26 октября 2007 года . Проверено 5 мая 2018 г.
^ «ColdSpring Framework: Добро пожаловать» . 5 ноября 2005 г. Архивировано из оригинала 5 ноября 2005 г. Проверено 5 мая 2018 г. {{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
^ «Проект Ближе: АспектЛ» . Архивировано из оригинала 23 февраля 2011 года . Проверено 11 августа 2015 г.
^ «Инфра – Интегрированные платформы для Delphi – Хостинг проектов Google» . Архивировано из оригинала 9 сентября 2015 года . Проверено 11 августа 2015 г.
^ «meaop — MeSDK: MeObjects, MeRTTI, MeAOP — Delphi AOP (аспектно-ориентированное программирование), MeRemote, MeService… — Хостинг проектов Google» . Архивировано из оригинала 10 сентября 2015 года . Проверено 11 августа 2015 г.
^ «Хостинг проектов Google» . Архивировано из оригинала 25 декабря 2014 года . Проверено 11 августа 2015 г.
^ «РемОбъекты Циррус» . codegear.com . Архивировано из оригинала 23 января 2012 года . Проверено 5 мая 2018 г.
^ «Консультационные функции Emacs» . Проект ГНУ. Архивировано из оригинала 24 октября 2011 года . Проверено 5 мая 2018 г.
^ Монады позволяют изменять семантику программы путем изменения типа программы без изменения ее кода: Де Мойтер, Вольфганг (1997). «Монады как теоретическая основа АОП». Международный семинар по аспектно-ориентированному программированию в ЭКООП : 25. CiteSeerX 10.1.1.25.8262 . Табаро, Николя; Фигероа, Исмаэль; Тантер, Эрик (март 2013 г.). «Типизированное монадическое вложение аспектов» . Материалы 12-й ежегодной международной конференции по аспектно-ориентированной разработке программного обеспечения (PDF) . Аосд '13. стр. 171–184. дои : 10.1145/2451436.2451457 . ISBN 9781450317665 . S2CID 27256161 . Классы типов позволяют добавлять к типу дополнительные возможности: Сульцманн, Мартин; Ван, Мэн (март 2007 г.). «Аспектно-ориентированное программирование с классами типов» . Материалы 6-го семинара по основам аспектно-ориентированных языков (PDF) . стр. 65–74. дои : 10.1145/1233833.1233842 . ISBN 978-1595936615 . S2CID 3253858 . .
^ Многие другие: CaesarJ. Архивировано 19 декабря 2008 г. в Wayback Machine , Compose*. Архивировано 21 августа 2005 г. в Wikiwix, Dynaop. Архивировано 24 июля 2007 г. в Wayback Machine . JAC. Архивировано 19 июня 2004 г. в Wayback Machine. , Google Guice (как часть его функциональности), Javassist. Архивировано 1 сентября 2004 г. на Wayback Machine . JAsCo (и AWED). Архивировано 11 апреля 2005 г. на Wayback Machine . JAML Архивировано 15 апреля 2005 г. на Wayback Machine. , JBoss AOP. Архивировано 17 октября 2006 г. в Wayback Machine . LogicAJ. Архивировано 4 мая 2006 г. в Wayback Machine . Объектные группы . Архивировано 31 августа 2005 г. в Wayback Machine . PROSE Архивировано 24 января 2007 г. в Wayback Machine. , Компилятор AspectBench для AspectJ (abc), Архивировано 16 декабря 2014 г. в Wayback Machine , Spring framework (как часть его функциональности), Seasar , Проект JMangler . Архивировано 28 октября 2005 г. в Wayback Machine , InjectJ. Архивировано в 2005 г. 05 апреля в Wayback Machine , GluonJ. Архивировано 6 февраля 2007 г. в Wayback Machine , Steamloom. Архивировано 18 августа 2007 г. в Wayback Machine.
^ Многие: желательно. Архивировано 4 июля 2008 г. на Wayback Machine , Ajaxpect. Архивировано 9 июля 2016 г. на Wayback Machine . Плагин jQuery AOP . Архивировано 13 января 2008 г. на Wayback Machine . Аспекты. Архивировано 8 мая 2006 г. на Wikiwix. , AspectJS. Архивировано 16 декабря 2008 г. в Wayback Machine . Cerny.js. Архивировано 27 июня 2007 г. в Wayback Machine . Dojo Toolkit. Архивировано 21 февраля 2006 г. в Wayback Machine . Humax Web Framework . Архивировано 9 декабря 2008 г. в the Wayback Machine , Joose. Архивировано 18 марта 2015 г. в Wayback Machine . Прототип – Функция прототипа #wrap. Архивировано 5 мая 2009 г. в Wayback Machine . YUI 3 (Y.Do). Архивировано 25 января 2011 г. в Wayback Machine.
^ Использование встроенной поддержки категорий (которая позволяет инкапсулировать аспектный код) и событийно-ориентированного программирования (что позволяет определять до и после обработчики событий ).
^ «АспектЛуа» . Архивировано из оригинала 17 июля 2015 года . Проверено 11 августа 2015 г.
^ «МАКАО, реверс-инжиниринг систем сборки» . Архивировано из оригинала 24 июля 2012 года . Проверено 11 августа 2015 г.
^ «МакЛаб» . Архивировано из оригинала 24 сентября 2015 года . Проверено 11 августа 2015 г.
^ «AspectML – исследование аспектно-ориентированного языка функционального программирования» . Архивировано из оригинала 5 декабря 2010 года . Проверено 11 августа 2015 г.
^ «nemerle/README.md в мастере · rsdn/nemerle» . Гитхаб . Проверено 22 марта 2018 г.
^ Адам Кеннеди. «Аспект – Аспектно-ориентированное программирование (АОП) для Perl – Metacpan.org» . Архивировано из оригинала 31 августа 2013 года . Проверено 11 августа 2015 г.
^ Несколько: PHP-AOP (AOP.io). Архивировано 18 августа 2014 г. на Wikiwix, Go! Фреймворк AOP. Архивировано 1 марта 2013 г. на Wayback Machine , PHPaspect. Архивировано 22 августа 2016 г. на Wayback Machine , Seasar.PHP. Архивировано 26 декабря 2005 г. на Wayback Machine , PHP-AOP , Flow. Архивировано 4 января 2018 г. на Wayback Machine , расширение AOP PECL. Архивировано 11 апреля 2017 г. на Wayback Machine.
^ «bigzaphod.org скоро появится» . bigzaphod.org . Архивировано из оригинала 20 апреля 2016 года . Проверено 5 мая 2018 г.
^ Несколько: PEAK. Архивировано 9 апреля 2005 г. на Wayback Machine , Aspyct AOP , Lightweight Python AOP. Архивировано 9 октября 2004 г. на Wayback Machine , аспектный модуль Logilab . Архивировано 9 марта 2005 г. на Wayback Machine , Pythius. Архивировано в 2005 г. - 08 апреля в Wayback Machine , модуль AOP Spring Python. Архивировано 4 марта 2016 г. в Wayback Machine , модуль AOP Pytilities. Архивировано 25 августа 2011 г. в Wayback Machine , spectlib. Архивировано 5 ноября 2014 г. в Wayback Machine.
^ «Репозиторий пакетов PLaneT: PLaneT > dutchyn >spectcheme.plt» . Архивировано из оригинала 5 сентября 2015 года . Проверено 11 августа 2015 г.
^ «AspectR — Простое аспектно-ориентированное программирование на Ruby» . Архивировано из оригинала 12 августа 2015 года . Проверено 11 августа 2015 г.
^ Дин Уэмплер. "Дом" . Архивировано из оригинала 26 октября 2007 года . Проверено 11 августа 2015 г.
^ "gcao/аспектор" . Гитхаб . Архивировано из оригинала 4 января 2015 года . Проверено 11 августа 2015 г.
^ «Аспекты» . tu-ilmenau.de . Архивировано из оригинала 6 января 2006 года . Проверено 5 мая 2018 г.
^ «MetaclassTalk: размышления и метапрограммирование в Smalltalk» . Архивировано из оригинала 29 июля 2015 года . Проверено 11 августа 2015 г.
^ «ВИВР» . iit.edu . Архивировано из оригинала 12 декабря 2008 года . Проверено 5 мая 2018 г.
^ «aspectxml — Аспектно-ориентированный механизм плетения XML (AXLE) — Хостинг проектов Google» . Архивировано из оригинала 12 сентября 2015 года . Проверено 11 августа 2015 г.

Дальнейшее чтение [ править ]

Кицалес, Г. ; Лампинг, Дж.; Мендекар, А.; Маэда, К.; Лопес, К.; Лойнтье, Дж. М.; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF) . ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию . Конспекты лекций по информатике (LNCS). Том. 1241. С. 220–242. CiteSeerX 10.1.1.115.8660 . дои : 10.1007/BFb0053381 . ISBN 3-540-63089-9 . Этот документ обычно считается авторитетным справочником по АОП.
Роберт Э. Филман; Цилла Эльрад; Шивон Кларк; Мехмет Аксит (2004). Аспектно-ориентированная разработка программного обеспечения . Аддисон-Уэсли. ISBN 978-0-321-21976-3 .
Рено Павляк, Лионель Сентюрье и Жан-Филипп Ретайе (2005). Основы АОП для разработки J2EE . Апресс. ISBN 978-1-59059-507-7 .
Ладдад, Рамнивас (2003). AspectJ в действии: практическое аспектно-ориентированное программирование . Мэннинг. ISBN 978-1-930110-93-9 .
Джейкобсон, Ивар ; Пан-Вэй Нг (2005). Аспектно-ориентированная разработка программного обеспечения с вариантами использования . Аддисон-Уэсли. ISBN 978-0-321-26888-4 .
Аспектно-ориентированная разработка программного обеспечения и PHP, Дмитрий Шейко, 2006 г.
Шивон Кларк и Элиза Баниассад (2005). Аспектно-ориентированный анализ и проектирование: тематический подход . Аддисон-Уэсли. ISBN 978-0-321-24674-5 .
Рагху Еддуладодди (2009). Аспектно-ориентированная разработка программного обеспечения: подход к составлению моделей проектирования UML . ISBN 978-3-639-12084-4 .
«Адаптивное объектно-ориентированное программирование с использованием настройки на основе графов» - Либерхерр, Сильва-Лепе и др. – 1994 г.
Самбрано Поло и Ла Борда, Артуро Федерико (5 июня 2013 г.). «Рассмотрение аспектных взаимодействий в промышленных условиях: опыт, проблемы и решения» : 159. doi : 10.35537/10915/35861 . Проверено 30 мая 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
Виджесурия, Вирадж Брайан (30 августа 2016 г.) Аспектно-ориентированная разработка, конспекты лекций, Школа вычислительной техники Университета Коломбо, Шри-Ланка
Гроувс, Мэтью Д. (2013). АОП в .NET . Мэннинг. ISBN 9781617291142 .

Внешние ссылки [ править ]

Эрика Боддена от Список инструментов АОП в .NET Framework
Аспектно-ориентированная разработка программного обеспечения , ежегодная конференция по АОП
Руководство по программированию AspectJ
Компилятор AspectBench для AspectJ , еще одной реализации Java.
Серия статей IBM DeveloperWorks об АОП
Ладдад, Рамнивас (18 января 2002 г.). «Хочу свой АОП! Часть 1» . JavaWorld . Проверено 20 июля 2020 г. Подробный цикл статей по основам аспектно-ориентированного программирования и AspectJ.
Что такое аспектно-ориентированное программирование? , знакомство с RemObjects Taco
Аспект спецификации ограничений Weaver
Аспектное и объектно-ориентированное программирование: какой метод и когда? Архивировано 15 апреля 2021 года в Wayback Machine.
Грегор Кицалес, профессор компьютерных наук, объясняет АОП , видео 57 мин.
Аспектно-ориентированное программирование на COBOL. Архивировано 17 декабря 2008 г. в Wayback Machine.
Аспектно-ориентированное программирование на Java с помощью Spring Framework
Wiki, посвященная методам АОП в .NET.
Ранние аспекты моделирования бизнес-процессов (аспектно-ориентированный язык для BPMN)
Spring AOP и AspectJ Введение
Аспирантура AOSD в Университете Билкента
Введение в АОП — радиоподкаст по программной инженерии, эпизод 106
Реализация АОП в Objective-C от Сильвестера Мольнара
Аспектно-ориентированное программирование для iOS и OS X Мануэля Гебеле
DevExpress MVVM Framework. Введение в модели представления POCO

[1] Кицалес, Г. ; Лампинг, Дж.; Мендекар, А.; Маэда, К.; Лопес, К.; Лойнтье, Дж. М.; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF) . ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию . Конспекты лекций по информатике (LNCS). Том. 1241. С. 220–242. CiteSeerX 10.1.1.115.8660 . дои : 10.1007/BFb0053381 . ISBN 3-540-63089-9 . Архивировано (PDF) из оригинала 12 января 2016 г.

[2] «Адаптивное объектно-ориентированное программирование: подход Деметры с шаблонами распространения» Карл Либхерр , 1996 г. ISBN 0-534-94602-X представляет собой хорошо проработанную версию, по сути, того же самого (Либерхерр впоследствии осознал это и переосмыслил свой подход).

[BoxSells2002-3] Дон Бокс; Крис Селлс (4 ноября 2002 г.). Essential.NET: общеязыковая среда выполнения . Аддисон-Уэсли Профессионал. п. 206 . ISBN 978-0-201-73411-9 . Проверено 4 октября 2011 г.

[RomanSriganesh2005-4] Роман, Эд; Шриганеш, Рима Патель; Броуз, Джеральд (1 января 2005 г.). Освоение корпоративных JavaBeans . Джон Уайли и сыновья. п. 285. ИСБН 978-0-7645-8492-3 . Проверено 4 октября 2011 г.

[5] Примечание. Синтаксис примеров в этой статье напоминает синтаксис языка Java .

[6] «gnu.org» . Проект ГНУ. Архивировано из оригинала 24 декабря 2017 года . Проверено 5 мая 2018 г.

[7] «Архивная копия» (PDF) . Архивировано из оригинала (PDF) 8 октября 2005 года . Проверено 19 июня 2005 г. {{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )

[dewin2002-8] Б. Де Вин, Б. Ванот и Б. Де Декер. «Безопасность посредством аспектно-ориентированного программирования». В книге «Достижения в области безопасности сетей и распределенных систем» (2002 г.).

[pasquier2014-9] Т. Паскье, Дж. Бэкон и Б. Шанд. «FlowR: аспектно-ориентированное программирование для управления информационными потоками в Ruby». В материалах ACM 13-й международной конференции по модульности (аспектно-ориентированной разработке программного обеспечения) (2014).

[10] Эдсгер Дейкстра , Заметки по структурированному программированию, заархивированные 12 октября 2006 г. в Wayback Machine , стр. 1-2

[harmful-11] Перейти обратно: ^а ^б ^с ^д Константинидес, Константинос; Скотиниотис, Терапон; Штерцер, Максимилиан (сентябрь 2004 г.). АОП считается вредным (PDF) . Европейский интерактивный семинар по аспектам программного обеспечения (EIWAS). Берлин, Германия. Архивировано (PDF) из оригинала 23 марта 2016 г. Проверено 5 мая 2018 г.

[12] C2: ComeFrom

[steimann-13] Перейти обратно: ^а ^б ^с ^д ^Это Стейманн, Ф. (2006). «Парадоксальный успех аспектно-ориентированного программирования». Уведомления ACM SIGPLAN . 41 (10): 481–497. CiteSeerX 10.1.1.457.2210 . дои : 10.1145/1167515.1167514 . , ( слайды заархивированы 4 марта 2016 г. в Wayback Machine , слайды 2 заархивированы 23 сентября 2015 г. в Wayback Machine , реферат заархивирован 24 сентября 2015 г. в Wayback Machine ), Фридрих Стейманн, Гэри Т. Ливенс, OOPSLA 2006

[14] «Более модульное рассуждение для аспектно-ориентированных программ» . Архивировано из оригинала 12 августа 2015 года . Проверено 11 августа 2015 г.

[15] «АОП и антиномия лжеца» (PDF) . Fernuni-hagen.de . Архивировано (PDF) из оригинала 9 августа 2017 года . Проверено 5 мая 2018 г.

[16] Многочисленные: Запоздалая мысль. Архивировано 15 марта 2016 г. на Wayback Machine , LOOM.NET. Архивировано 27 августа 2008 г. на Wayback Machine , Enterprise Library 3.0. Блок приложения внедрения политики. Архивировано 19 января 2007 г. на Wayback Machine , AspectDNG. Архивировано 9 сентября 2004 г. 29 в Wayback Machine , DynamicProxy. Архивировано 5 декабря 2015 г. в Wayback Machine , Compose*. Архивировано 21 августа 2005 г. в Wikiwix, PostSharp . Архивировано 3 мая 2016 г. в Wayback Machine , Seasar.NET. Архивировано 25 июля 2006 г. в Wayback Machine , DotSpect (.SPECT). Архивировано 31 марта 2006 г. в Wayback Machine , Spring.NET. Архивировано 2 апреля 2006 г. в Wayback Machine (как часть его функциональности), Wicca и Phx.Morph. Архивировано в 2006 г. 7 июля 2008 г. в Wayback Machine , SetPoint. Архивировано 7 октября 2008 г. в Wayback Machine.

[17] «Добро пожаловать в as3-commons-bytecode» . as3commons.org . Архивировано из оригинала 3 октября 2014 года . Проверено 5 мая 2018 г.

[18] «Обоснование Ada2012» (PDF) . adacore.com . Архивировано (PDF) из оригинала 18 апреля 2016 года . Проверено 5 мая 2018 г.

[19] «Функциональные крючки» . autohotkey.com . Архивировано из оригинала 17 января 2013 года . Проверено 5 мая 2018 г.

[20] Несколько: AspectC++ , FeatureC++ , AspectC. Архивировано 21 августа 2006 г. на Wayback Machine , AspeCt-ориентированный C. Архивировано 20 ноября 2008 г. на Wayback Machine , Aspicere.

[21] «Булыжник» . vub.ac.be . Проверено 5 мая 2018 г. ^{[ постоянная мертвая ссылка ]}

[22] «АспектКакао» . neu.edu . Архивировано из оригинала 26 октября 2007 года . Проверено 5 мая 2018 г.

[23] «ColdSpring Framework: Добро пожаловать» . 5 ноября 2005 г. Архивировано из оригинала 5 ноября 2005 г. Проверено 5 мая 2018 г. {{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )

[24] «Проект Ближе: АспектЛ» . Архивировано из оригинала 23 февраля 2011 года . Проверено 11 августа 2015 г.

[25] «Инфра – Интегрированные платформы для Delphi – Хостинг проектов Google» . Архивировано из оригинала 9 сентября 2015 года . Проверено 11 августа 2015 г.

[26] «meaop — MeSDK: MeObjects, MeRTTI, MeAOP — Delphi AOP (аспектно-ориентированное программирование), MeRemote, MeService… — Хостинг проектов Google» . Архивировано из оригинала 10 сентября 2015 года . Проверено 11 августа 2015 г.

[27] «Хостинг проектов Google» . Архивировано из оригинала 25 декабря 2014 года . Проверено 11 августа 2015 г.

[28] «РемОбъекты Циррус» . codegear.com . Архивировано из оригинала 23 января 2012 года . Проверено 5 мая 2018 г.

[29] «Консультационные функции Emacs» . Проект ГНУ. Архивировано из оригинала 24 октября 2011 года . Проверено 5 мая 2018 г.

[30] Монады позволяют изменять семантику программы путем изменения типа программы без изменения ее кода: Де Мойтер, Вольфганг (1997). «Монады как теоретическая основа АОП». Международный семинар по аспектно-ориентированному программированию в ЭКООП : 25. CiteSeerX 10.1.1.25.8262 . Табаро, Николя; Фигероа, Исмаэль; Тантер, Эрик (март 2013 г.). «Типизированное монадическое вложение аспектов» . Материалы 12-й ежегодной международной конференции по аспектно-ориентированной разработке программного обеспечения (PDF) . Аосд '13. стр. 171–184. дои : 10.1145/2451436.2451457 . ISBN 9781450317665 . S2CID 27256161 . Классы типов позволяют добавлять к типу дополнительные возможности: Сульцманн, Мартин; Ван, Мэн (март 2007 г.). «Аспектно-ориентированное программирование с классами типов» . Материалы 6-го семинара по основам аспектно-ориентированных языков (PDF) . стр. 65–74. дои : 10.1145/1233833.1233842 . ISBN 978-1595936615 . S2CID 3253858 . .

[31] Многие другие: CaesarJ. Архивировано 19 декабря 2008 г. в Wayback Machine , Compose*. Архивировано 21 августа 2005 г. в Wikiwix, Dynaop. Архивировано 24 июля 2007 г. в Wayback Machine . JAC. Архивировано 19 июня 2004 г. в Wayback Machine. , Google Guice (как часть его функциональности), Javassist. Архивировано 1 сентября 2004 г. на Wayback Machine . JAsCo (и AWED). Архивировано 11 апреля 2005 г. на Wayback Machine . JAML Архивировано 15 апреля 2005 г. на Wayback Machine. , JBoss AOP. Архивировано 17 октября 2006 г. в Wayback Machine . LogicAJ. Архивировано 4 мая 2006 г. в Wayback Machine . Объектные группы . Архивировано 31 августа 2005 г. в Wayback Machine . PROSE Архивировано 24 января 2007 г. в Wayback Machine. , Компилятор AspectBench для AspectJ (abc), Архивировано 16 декабря 2014 г. в Wayback Machine , Spring framework (как часть его функциональности), Seasar , Проект JMangler . Архивировано 28 октября 2005 г. в Wayback Machine , InjectJ. Архивировано в 2005 г. 05 апреля в Wayback Machine , GluonJ. Архивировано 6 февраля 2007 г. в Wayback Machine , Steamloom. Архивировано 18 августа 2007 г. в Wayback Machine.

[32] Многие: желательно. Архивировано 4 июля 2008 г. на Wayback Machine , Ajaxpect. Архивировано 9 июля 2016 г. на Wayback Machine . Плагин jQuery AOP . Архивировано 13 января 2008 г. на Wayback Machine . Аспекты. Архивировано 8 мая 2006 г. на Wikiwix. , AspectJS. Архивировано 16 декабря 2008 г. в Wayback Machine . Cerny.js. Архивировано 27 июня 2007 г. в Wayback Machine . Dojo Toolkit. Архивировано 21 февраля 2006 г. в Wayback Machine . Humax Web Framework . Архивировано 9 декабря 2008 г. в the Wayback Machine , Joose. Архивировано 18 марта 2015 г. в Wayback Machine . Прототип – Функция прототипа #wrap. Архивировано 5 мая 2009 г. в Wayback Machine . YUI 3 (Y.Do). Архивировано 25 января 2011 г. в Wayback Machine.

[33] Использование встроенной поддержки категорий (которая позволяет инкапсулировать аспектный код) и событийно-ориентированного программирования (что позволяет определять до и после обработчики событий ).

[34] «АспектЛуа» . Архивировано из оригинала 17 июля 2015 года . Проверено 11 августа 2015 г.

[35] «МАКАО, реверс-инжиниринг систем сборки» . Архивировано из оригинала 24 июля 2012 года . Проверено 11 августа 2015 г.

[36] «МакЛаб» . Архивировано из оригинала 24 сентября 2015 года . Проверено 11 августа 2015 г.

[37] «AspectML – исследование аспектно-ориентированного языка функционального программирования» . Архивировано из оригинала 5 декабря 2010 года . Проверено 11 августа 2015 г.

[38] «nemerle/README.md в мастере · rsdn/nemerle» . Гитхаб . Проверено 22 марта 2018 г.

[39] Адам Кеннеди. «Аспект – Аспектно-ориентированное программирование (АОП) для Perl – Metacpan.org» . Архивировано из оригинала 31 августа 2013 года . Проверено 11 августа 2015 г.

[40] Несколько: PHP-AOP (AOP.io). Архивировано 18 августа 2014 г. на Wikiwix, Go! Фреймворк AOP. Архивировано 1 марта 2013 г. на Wayback Machine , PHPaspect. Архивировано 22 августа 2016 г. на Wayback Machine , Seasar.PHP. Архивировано 26 декабря 2005 г. на Wayback Machine , PHP-AOP , Flow. Архивировано 4 января 2018 г. на Wayback Machine , расширение AOP PECL. Архивировано 11 апреля 2017 г. на Wayback Machine.

[41] «bigzaphod.org скоро появится» . bigzaphod.org . Архивировано из оригинала 20 апреля 2016 года . Проверено 5 мая 2018 г.

[42] Несколько: PEAK. Архивировано 9 апреля 2005 г. на Wayback Machine , Aspyct AOP , Lightweight Python AOP. Архивировано 9 октября 2004 г. на Wayback Machine , аспектный модуль Logilab . Архивировано 9 марта 2005 г. на Wayback Machine , Pythius. Архивировано в 2005 г. - 08 апреля в Wayback Machine , модуль AOP Spring Python. Архивировано 4 марта 2016 г. в Wayback Machine , модуль AOP Pytilities. Архивировано 25 августа 2011 г. в Wayback Machine , spectlib. Архивировано 5 ноября 2014 г. в Wayback Machine.

[43] «Репозиторий пакетов PLaneT: PLaneT > dutchyn >spectcheme.plt» . Архивировано из оригинала 5 сентября 2015 года . Проверено 11 августа 2015 г.

[44] «AspectR — Простое аспектно-ориентированное программирование на Ruby» . Архивировано из оригинала 12 августа 2015 года . Проверено 11 августа 2015 г.

[45] Дин Уэмплер. "Дом" . Архивировано из оригинала 26 октября 2007 года . Проверено 11 августа 2015 г.

[46] "gcao/аспектор" . Гитхаб . Архивировано из оригинала 4 января 2015 года . Проверено 11 августа 2015 г.

[47] «Аспекты» . tu-ilmenau.de . Архивировано из оригинала 6 января 2006 года . Проверено 5 мая 2018 г.

[48] «MetaclassTalk: размышления и метапрограммирование в Smalltalk» . Архивировано из оригинала 29 июля 2015 года . Проверено 11 августа 2015 г.

[49] «ВИВР» . iit.edu . Архивировано из оригинала 12 декабря 2008 года . Проверено 5 мая 2018 г.

[50] «aspectxml — Аспектно-ориентированный механизм плетения XML (AXLE) — Хостинг проектов Google» . Архивировано из оригинала 12 сентября 2015 года . Проверено 11 августа 2015 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

v т Это Аспектно-ориентированное программирование
Concepts	Advice Aspect Aspect-oriented programming Aspect weaver Cross-cutting concerns Join point Pointcut
Languages	AspectC++ AspectJ AspectWerkz