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


Парадигмы программирования

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

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

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

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

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

История

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

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

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

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

Мотивация и основные понятия

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

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

пустота передача(Счет fromAcc, Счет toAcc, int количество) бросает Исключение {  если (fromAcc.getBalance() < количество)      бросать новый InsfficientFundsException();  fromAcc.снять со счета(количество);  toAcc.депозит(количество);}

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

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

пустота передача(Счет fromAcc, Счет toAcc, int количество, Пользователь Пользователь,    Регистратор регистратор, База данных база данных) бросает Исключение {  регистратор.Информация(«Перевод денег ...»);    если (!isUserAuthorised(Пользователь, fromAcc)) {    регистратор.Информация(«У пользователя нет разрешения».);    бросать новый UnauthorisedUserException();  }    если (fromAcc.getBalance() < количество) {    регистратор.Информация("Недостаточно средств.");    бросать новый InsfficientFundsException();  }  fromAcc.снять со счета(количество);  toAcc.депозит(количество);  база данных.commitChanges();  // Атомарная операция.  регистратор.Информация(«Транзакция успешна».);}

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

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

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

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

аспект Регистратор {  пустота банк.передача(Счет fromAcc, Счет toAcc, int количество, Пользователь Пользователь, Регистратор регистратор)  {    регистратор.Информация(«Перевод денег ...»);  }  пустота банк.getMoneyBack(Пользователь Пользователь, int ID транзакции, Регистратор регистратор)  {    регистратор.Информация(«Пользователь запросил возврат денег».);  }  // Другой перекрестный код.}

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

Модели точек соединения

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

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

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

Модель точки соединения AspectJ

Основная статья: AspectJ
  • Точки соединения в AspectJ включают вызов или выполнение метода или конструктора, инициализацию класса или объекта, доступ для чтения и записи полей, обработчики исключений и т. Д. Они не включают циклы, супервызовы, предложения throws, несколько операторов и т. Д.
  • Pointcuts задаются комбинациями примитивные обозначения pointcut (PCD).

    «Родственные» PCD соответствуют определенному типу точки соединения (например, выполнение метода) и имеют тенденцию принимать в качестве входных данных сигнатуру, подобную Java. Один из таких pointcut выглядит так:

     исполнение (* установить * (*))

    Этот pointcut соответствует точке соединения метода и выполнения, если имя метода начинается с "набор"и есть ровно один аргумент любого типа.

    «Динамические» PCD проверяют типы времени выполнения и связывают переменные. Например,

      эта точка)

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

    PCD "области" ограничивают лексический объем точки соединения. Например:

     внутри (com.company. *)

    Этот pointcut соответствует любой точке соединения любого типа в com.company упаковка. В * - это одна из форм подстановочных знаков, которая может использоваться для сопоставления многих вещей с помощью одной подписи.

    Pointcuts могут быть составлены и названы для повторного использования. Например:

     Pointcut набор() : исполнение(* набор*(*) ) && это(Точка) && в(com.Компания.*);
    Этот pointcut соответствует точке соединения метода и выполнения, если имя метода начинается с "набор" и это это экземпляр типа Точка в com.company упаковка. На это можно ссылаться, используя имя "набор()".
  • Advice указывает запускать (до, после или около) точки соединения (указанной с помощью pointcut) определенного кода (указанного как код в методе). Среда выполнения AOP автоматически вызывает Advice, когда pointcut совпадает с точкой соединения. Например: after (): set () {Display.update (); } Это эффективно определяет: "если набор() pointcut соответствует точке соединения, запустите код Display.update () после завершения точки соединения ".

Другие возможные модели точек соединения

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

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

Межтиповые объявления

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

  аспект DisplayUpdate {    пустота Точка.acceptVisitor(Посетитель v) {      v.посещение(это);    }    // другой перекрестный код ...  }

Этот фрагмент кода добавляет acceptVisitor метод к Точка учебный класс.

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

Выполнение

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

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

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

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

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

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

Терминология

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

Общие проблемы
Основная статья: Межсекторальная озабоченность
Несмотря на то, что большинство классов в объектно-ориентированной модели будут выполнять одну конкретную функцию, они часто разделяют общие вторичные требования с другими классами. Например, мы можем захотеть добавить ведение журнала к классам на уровне доступа к данным, а также к классам на уровне пользовательского интерфейса всякий раз, когда поток входит в метод или выходит из него. Дальнейшие проблемы могут быть связаны с безопасностью, например контроль доступа [8] или же управление информационным потоком.[9] Несмотря на то, что каждый класс имеет очень разные основные функции, код, необходимый для выполнения дополнительных функций, часто идентичен.
Совет
Основная статья: Консультации (программирование)
Это дополнительный код, который вы хотите применить к существующей модели. В нашем примере это код регистрации, который мы хотим применять всякий раз, когда поток входит в метод или выходит из него.
Pointcut
Основная статья: Pointcut
Это термин, обозначающий точку исполнения в приложении, к которой необходимо применить сквозное внимание. В нашем примере pointcut достигается, когда поток входит в метод, а другой pointcut достигается, когда поток выходит из метода.
Аспект
Основная статья: Аспект (информатика)
Комбинация pointcut и совета называется аспектом. В приведенном выше примере мы добавляем аспект ведения журнала в наше приложение, определяя pointcut и давая правильный совет.

Сравнение с другими парадигмами программирования

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

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

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

Проблемы с усыновлением

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

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

Критика

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

5ВХОДИкс10РАСПЕЧАТАТЬ"Результат:"15РАСПЕЧАТАТЬИкс20ПРИЕХАТЬИЗ1025Икс=Икс*Икс30ВОЗВРАЩАТЬСЯ

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

главный() {    Вход Икс    Распечатать(результат(Икс))}Вход результат(int Икс) { возвращаться Икс }вокруг(int Икс): вызов(результат(int)) && аргументы(Икс) {    int темп = продолжить(Икс)    возвращаться темп * темп}

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

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

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

Реализации

Следующее языки программирования реализовали АОП внутри языка или как внешнюю библиотеку:

Смотрите также

Примечания и ссылки

  1. ^ Кичалес, Г.; Lamping, J .; Mendhekar, A .; Maeda, C .; Lopes, C .; Loingtier, J.M .; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF). ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию. LNCS. 1241. С. 220–242. CiteSeerX  10.1.1.115.8660. Дои:10.1007 / BFb0053381. ISBN  3-540-63089-9. В архиве (PDF) из оригинала от 12.01.2016.
  2. ^ «Адаптивное объектно-ориентированное программирование: подход Деметры с шаблонами распространения» Карл Либхерр 1996 ISBN  0-534-94602-X представляет хорошо проработанную версию, по сути, того же самого (впоследствии Либерхерр осознал это и пересмотрел свой подход).
  3. ^ Дон Бокс; Крис Селлс (4 ноября 2002 г.). Essential.NET: среда CLR. Эддисон-Уэсли Профессионал. п.206. ISBN  978-0-201-73411-9. Получено 4 октября 2011.
  4. ^ Роман, Эд; Сриганеш, Рима Патель; Брозе, Джеральд (1 января 2005 г.). Освоение Enterprise JavaBeans. Джон Уайли и сыновья. п. 285. ISBN  978-0-7645-8492-3. Получено 4 октября 2011.
  5. ^ Примечание: примеры в этой статье представлены в синтаксисе, напоминающем синтаксис Ява язык.
  6. ^ "gnu.org". www.gnu.org. В архиве из оригинала 24 декабря 2017 г.. Получено 5 мая 2018.
  7. ^ «Архивная копия» (PDF). Архивировано из оригинал (PDF) на 2005-10-08. Получено 2005-06-19.CS1 maint: заархивированная копия как заголовок (связь)
  8. ^ Б. Де Вин, Б. Ванхаут и Б. Де Деккер. «Безопасность за счет аспектно-ориентированного программирования». В Достижения в области безопасности сетей и распределенных систем (2002).
  9. ^ Т. Паскье, Дж. Бэкон и Б. Шанд. "FlowR: Аспектно-ориентированное программирование для управления информационными потоками в Ruby". В ACM Proceedings 13-й международной конференции по модульности (аспектно-ориентированная разработка программного обеспечения) (2014).
  10. ^ Эдсгер Дейкстра, Примечания по структурированному программированию В архиве 2006-10-12 на Wayback Machine, стр. 1-2
  11. ^ а б c d Константинид, Константинос; Скотиниотис, Терапон; Стёрцер, Максимилиан (сентябрь 2004 г.). АОП считается вредным (PDF). Европейский интерактивный семинар по аспектам программного обеспечения (EIWAS). Берлин, Германия. В архиве (PDF) из оригинала 23 марта 2016 г.. Получено 5 мая 2018.
  12. ^ C2: ComeFrom
  13. ^ а б c d е Стейманн, Ф. (2006). «Парадоксальный успех аспектно-ориентированного программирования». Уведомления ACM SIGPLAN. 41 (10): 481–497. CiteSeerX  10.1.1.457.2210. Дои:10.1145/1167515.1167514., (слайды В архиве 2016-03-04 в Wayback Machine,слайды 2 В архиве 2015-09-23 на Wayback Machine, Абстрактные В архиве 2015-09-24 на Wayback Machine ), Фридрих Штайман, Гэри Т. Ливенс, OOPSLA 2006
  14. ^ «Более модульное мышление для аспектно-ориентированных программ». В архиве с оригинала 12 августа 2015 г.. Получено 11 августа 2015.
  15. ^ "АОП и антиномия лжеца" (PDF). fernuni-hagen.de. В архиве (PDF) с оригинала 9 августа 2017 г.. Получено 5 мая 2018.
  16. ^ Многочисленные:Запоздалая мысль В архиве 2016-03-15 в Wayback Machine, LOOM.NET В архиве 2008-08-27 на Wayback Machine, Блок приложения для внедрения политики Enterprise Library 3.0 В архиве 2007-01-19 на Wayback Machine, AspectDNG В архиве 2004-09-29 на Wayback Machine, DynamicProxy В архиве 2015-12-05 в Wayback Machine, Написать * В архиве 21 августа 2005 г. в Wikiwix, PostSharp В архиве 2016-05-03 в Wayback Machine, Seasar.NET В архиве 2006-07-25 на Wayback Machine, DotSpect (.SPECT) В архиве 31 марта 2006 г. Wayback Machine, Spring.NET В архиве 2006-04-02 в Wayback Machine (как часть его функциональности), Викка и Phx.Morph В архиве 2006-12-07 на Wayback Machine, SetPoint В архиве 2008-10-07 на 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. ^ Несколько: АспектС ++, Особенность: C ++, AspectC В архиве 2006-08-21 на Wayback Machine, AspeCt-ориентированный C В архиве 2008-11-20 на Wayback Machine, Aspicere
  21. ^ "Брусчатка". vub.ac.be. Получено 5 мая 2018.[постоянная мертвая ссылка ]
  22. ^ "AspectCocoa". neu.edu. Архивировано из оригинал 26 октября 2007 г.. Получено 5 мая 2018.
  23. ^ «ColdSpring Framework: Добро пожаловать!». 5 ноября 2005 г. Архивировано 5 ноября 2005 г.. Получено 5 мая 2018.CS1 maint: BOT: статус исходного URL-адреса неизвестен (связь)
  24. ^ "Closer Project: AspectL". В архиве из оригинала 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. ^ "RemObjects Cirrus". codegear.com. Архивировано из оригинал 23 января 2012 г.. Получено 5 мая 2018.
  29. ^ "Консультационные функции Emacs". gnu.org. В архиве из оригинала 24 октября 2011 г.. Получено 5 мая 2018.
  30. ^ Монады позволяют изменять семантику программы путем изменения типа программы без изменения ее кода: Де Мойтер, Вольфганг (1997). «Монады как теоретическая основа АОП». Международный семинар по аспектно-ориентированному программированию в ECOOP. CiteSeerX  10.1.1.25.8262. Табаро, Николас; Фигероа, Исмаил; Тантер, Эрик (март 2013 г.). «Типизированное монадическое вложение аспектов». Материалы 12-й ежегодной международной конференции по аспектно-ориентированной разработке программного обеспечения: 171–184. Дои:10.1145/2451436.2451457. ISBN  9781450317665. S2CID  27256161. Типовые классы позволяют добавлять к типу дополнительные возможности: Зульцманн, Мартин; Ван, Мэн (март 2007 г.). «Аспектно-ориентированное программирование с классами типов». Материалы 6-го семинара по основам аспектно-ориентированных языков: 65–74. Дои:10.1145/1233833.1233842. ISBN  978-1595936615. S2CID  3253858..
  31. ^ Многочисленные другие: ЦезарьJ В архиве 2008-12-19 на Wayback Machine, Написать * В архиве 21 августа 2005 г. в Wikiwix, Динаоп В архиве 2007-07-24 на Wayback Machine, JAC В архиве 2004-06-19 на Wayback Machine, Google Guice (как часть его функциональности), Javassist В архиве 2004-09-01 на Wayback Machine, JAsCo (и AWED) В архиве 2005-04-11 на Wayback Machine, JAML В архиве 2005-04-15 на Wayback Machine, JBoss AOP В архиве 2006-10-17 на Wayback Machine, LogicAJ В архиве 2006-05-04 в Wayback Machine, Команды объектов В архиве 2005-08-31 на Wayback Machine, ПРОЗА В архиве 2007-01-24 на Wayback Machine, Компилятор AspectBench для AspectJ (abc) В архиве 2014-12-16 в Wayback Machine, Пружинный каркас (как часть его функциональности), Seasar, Проект JMangler В архиве 2005-10-28 на Wayback Machine, InjectJ В архиве 2005-04-05 на Wayback Machine, GluonJ В архиве 2007-02-06 на Wayback Machine, Steamloom В архиве 2007-08-18 на Wayback Machine
  32. ^ Много: Желательно В архиве 2008-07-04 в Wayback Machine, Аяспект В архиве 2016-07-09 в Wayback Machine, Плагин jQuery AOP В архиве 2008-01-13 на Wayback Machine, Aspectes В архиве 2008-05-08 в Wikiwix, AspectJS В архиве 2008-12-16 на Wayback Machine, Cerny.js В архиве 2007-06-27 на Wayback Machine, Набор инструментов Dojo В архиве 2006-02-21 в Wayback Machine, Веб-платформа Humax В архиве 2008-12-09 на Wayback Machine, Joose В архиве 2015-03-18 в Wayback Machine, Прототип - Прототип функции # обертка В архиве 2009-05-05 на Wayback Machine, ЮЙ 3 (Й.до) В архиве 2011-01-25 на 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. ^ Адам Кеннеди. "Аспект - Аспектно-ориентированное программирование (АОП) для Perl - metacpan.org". В архиве из оригинала 31 августа 2013 г.. Получено 11 августа 2015.
  39. ^ Несколько: PHP-AOP (AOP.io) В архиве 2014-08-18 в Wikiwix, Идти! Структура АОП В архиве 2013-03-01 на Wayback Machine, PHPaspect В архиве 2016-08-22 в Wayback Machine, Seasar.PHP В архиве 2005-12-26 на Wayback Machine, PHP-АОП, Поток В архиве 2018-01-04 в Wayback Machine, Расширение AOP PECL В архиве 2017-04-11 в Wayback Machine
  40. ^ "bigzaphod.org скоро будет". www.bigzaphod.org. В архиве из оригинала от 20 апреля 2016 г.. Получено 5 мая 2018.
  41. ^ Несколько: ВЕРШИНА ГОРЫ В архиве 2005-04-09 на Wayback Machine, Аспект АОП, Легкий Python AOP В архиве 2004-10-09 на Wayback Machine, Модуль аспекта Logilab В архиве 2005-03-09 на Wayback Machine, Пифий В архиве 2005-04-08 на Wayback Machine, Модуль Spring Python AOP В архиве 2016-03-04 в Wayback Machine, Модуль АОП Pytilities В архиве 2011-08-25 на Wayback Machine, Aspectlib В архиве 2014-11-05 в Wayback Machine
  42. ^ "Репозиторий пакетов PLaneT: PLaneT> dutchyn> sizescheme.plt". В архиве из оригинала 5 сентября 2015 г.. Получено 11 августа 2015.
  43. ^ «AspectR - Простое аспектно-ориентированное программирование на Ruby». В архиве с оригинала 12 августа 2015 г.. Получено 11 августа 2015.
  44. ^ Дин Уэмплер. "Дома". Архивировано из оригинал 26 октября 2007 г.. Получено 11 августа 2015.
  45. ^ "gcao / aspector". GitHub. В архиве из оригинала 4 января 2015 г.. Получено 11 августа 2015.
  46. ^ «АСПЕКТЫ». tu-ilmenau.de. Архивировано из оригинал 6 января 2006 г.. Получено 5 мая 2018.
  47. ^ "MetaclassTalk: отражение и метапрограммирование в Smalltalk". Архивировано из оригинал 29 июля 2015 г.. Получено 11 августа 2015.
  48. ^ "WEAVR". iit.edu. В архиве из оригинала 12 декабря 2008 г.. Получено 5 мая 2018.
  49. ^ "Aspectxml - Аспектно-ориентированный механизм создания XML (AXLE) - Хостинг проектов Google". В архиве из оригинала 12 сентября 2015 г.. Получено 11 августа 2015.

дальнейшее чтение

внешняя ссылка