✖


Jump to content

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

В вычислительной технике аспектно -ориентированное программирование ( АОП ) — это парадигма программирования , целью которой является повышение модульности за счет разделения сквозных задач . Это делается путем добавления поведения к существующему коду ( рекомендация ) без изменения кода, вместо этого отдельно указывая, какой код изменяется, с помощью спецификации « 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] 

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
  if (fromAcc.getBalance() < amount)
      throw new InsufficientFundsException();

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);
}

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

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

void transfer(Account fromAcc, Account toAcc, int amount, User user,
    Logger logger, Database database) throws Exception {
  logger.info("Transferring money...");
  
  if (!isUserAuthorised(user, fromAcc)) {
    logger.info("User has no permission.");
    throw new UnauthorisedUserException();
  }
  
  if (fromAcc.getBalance() < amount) {
    logger.info("Insufficient funds.");
    throw new InsufficientFundsException();
  }

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);

  database.commitChanges();  // Atomic operation.

  logger.info("Transaction successful.");
}

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

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

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

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

aspect Logger {
  void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger)  {
    logger.info("Transferring money...");
  }

  void Bank.getMoneyBack(User user, int transactionId, Logger logger)  {
    logger.info("User requested money back.");
  }

  // Other crosscutting code.
}

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

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

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

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

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

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

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

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

    execution(* set*(*))

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

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

    this(Point)

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

    «Область» PCD ограничивает лексическую область действия точки соединения. Например: 

    within(com.company.*)

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

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

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

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

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

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

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

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

  aspect DisplayUpdate {
    void Point.acceptVisitor(Visitor v) {
      v.visit(this);
    }
    // other crosscutting code...
  }

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

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

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

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

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

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

Системы могут реализовать переплетение на уровне исходного кода с использованием препроцессоров (поскольку 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 'Result is :'
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 }
around(int x): call(result(int)) && args(x) {
    int temp = proceed(x)
    return temp * temp
}

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

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

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

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

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

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

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

  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 представляет собой хорошо проработанную версию, по сути, того же самого (Либерхерр впоследствии осознал это и переосмыслил свой подход).
  3. ^ Дон Бокс; Крис Селлс (4 ноября 2002 г.). Essential.NET: общеязыковая среда выполнения . Аддисон-Уэсли Профессионал. п. 206 . ISBN  978-0-201-73411-9 . Проверено 4 октября 2011 г.
  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: архивная копия в заголовке ( ссылка )
  8. ^ Б. Де Вин, Б. Ванот и Б. Де Декер. «Безопасность посредством аспектно-ориентированного программирования». В книге «Достижения в области безопасности сетей и распределенных систем» (2002 г.).
  9. ^ Т. Паскье, Дж. Бэкон и Б. Шанд. «FlowR: аспектно-ориентированное программирование для управления информационными потоками в Ruby». В материалах ACM 13-й международной конференции по модульности (аспектно-ориентированной разработке программного обеспечения) (2014).
  10. ^ Эдсгер Дейкстра , Заметки по структурированному программированию, заархивированные 12 октября 2006 г. в Wayback Machine , стр. 1-2
  11. ^ Jump up to: Перейти обратно: а б с д Константинидес, Константинос; Скотиниотис, Терапон; Штерцер, Максимилиан (сентябрь 2004 г.). АОП считается вредным (PDF) . Европейский интерактивный семинар по аспектам программного обеспечения (EIWAS). Берлин, Германия. Архивировано (PDF) из оригинала 23 марта 2016 г. Проверено 5 мая 2018 г.
  12. ^ C2: ComeFrom
  13. ^ Jump up to: Перейти обратно: а б с д и Стейманн, Ф. (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 , Object Teams, архивировано 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 г.

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

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Aspect-oriented_programming&oldid=1222266331"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: de6ff7c58cddffdd2d74c564239e587c__1714852140
URL1:https://arc.ask3.ru/arc/aa/de/7c/de6ff7c58cddffdd2d74c564239e587c.html
Заголовок, (Title) документа по адресу, URL1:
Aspect-oriented programming - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)