В вычислительной , аспект-ориентированное программирование ( АОП ) является парадигма программирования , которая направлена на повышение модульности , позволяя разделение сквозных проблем . Он делает это, добавляя дополнительное поведение к существующему коду ( совет ) без изменения самого кода, вместо этого отдельно указывая, какой код модифицируется с помощью спецификации « pointcut », например, «записывать все вызовы функций, когда имя функции начинается с 'set '. ". Это позволяет поведение, которое не является центральным для бизнес-логики (например, ведение журнала) для добавления в программу, не загромождая ядро кода функциональными возможностями.
АОП включает в себя методы и инструменты программирования, которые поддерживают модульность задач на уровне исходного кода, в то время как аспектно-ориентированная разработка программного обеспечения относится ко всей инженерной дисциплине.
Аспект-ориентированное программирование регистрация требует Ломая логику программы на отдельные части (так называемые проблемы , связные области функциональности). Почти все парадигмы программирования поддерживают некоторый уровень группировки и инкапсуляции проблем в отдельные независимые сущности, предоставляя абстракции (например, функции, процедуры, модули, классы, методы), которые можно использовать для реализации, абстрагирования и объединения этих проблем. Некоторые проблемы «пересекают» несколько абстракций в программе и бросают вызов этим формам реализации. Эти проблемы называются сквозными или горизонтальными.
Ведение журнала представляет собой комплексную проблему, поскольку стратегия ведения журнала обязательно влияет на каждую регистрируемую часть системы. Таким образом, ведение журнала пересекает все зарегистрированные классы и методы.
Все реализации АОП имеют несколько пересекающихся выражений, которые объединяют каждую проблему в одном месте. Разница между реализациями заключается в мощности, безопасности и удобстве использования предоставленных конструкций. Например, перехватчики, которые определяют методы для выражения ограниченной формы пересечения, без особой поддержки безопасности типов или отладки. AspectJ имеет несколько таких выражений и инкапсулирует их в специальный класс, аспект . Например, аспект может изменить поведение базового кода (не аспектная часть программы), применяя совет (дополнительное поведение) в различных точках соединения (точках в программе), указанных в количественной оценке или запросе, называемом pointcut ( который определяет, совпадает ли данная точка соединения). Аспект также может вносить бинарно-совместимые структурные изменения в другие классы, такие как добавление членов или родителей.
История
АОП имеет несколько прямых предшественников A1 и A2: [1] протоколы отражения и метаобъектов , предметно-ориентированное программирование , фильтры композиции и адаптивное программирование. [2]
Грегор Кичалес и его коллеги из Xerox PARC разработали явную концепцию АОП, а затем разработали расширение AspectJ AOP для Java. Исследовательская группа IBM предпочла инструментальный подход к языковому дизайну и в 2001 году предложила Hyper / J и среду управления проблемами , которые не получили широкого распространения.
В примерах в этой статье используется AspectJ.
Transaction Server Microsoft считается первым крупным применение АОП с последующим Enterprise JavaBeans . [3] [4]
Мотивация и основные понятия
Обычно аспект разбросан или запутан в виде кода, что затрудняет понимание и сопровождение. Он разбросан в силу того, что функция (например, ведение журнала) распределена по ряду несвязанных функций, которые могут использовать его функцию, возможно, в совершенно несвязанных системах, на разных исходных языках и т. Д. Это означает, что для изменения ведения журнала может потребоваться изменение всех затронутых модулей. . Аспекты запутываются не только с основной функцией систем, в которых они выражены, но и друг с другом. Это означает, что изменение одной проблемы влечет за собой понимание всех запутанных проблем или наличие некоторых средств, с помощью которых можно сделать вывод о последствиях изменений.
Например, рассмотрим банковское приложение с концептуально очень простым методом перевода суммы с одного счета на другой: [5]
void transfer ( Account fromAcc , Account toAcc , int amount ) выдает исключение { if ( fromAcc . getBalance () < amount ) throw new InsfficientFundsException (); fromAcc . снять ( сумма ); toAcc . депозит ( сумма ); }
Однако этот метод передачи игнорирует некоторые соображения, которые потребуются развернутому приложению: в нем отсутствуют проверки безопасности, чтобы убедиться, что текущий пользователь имеет разрешение на выполнение этой операции; транзакций базы данных должна инкапсулировать операции, чтобы предотвратить случайную потерю данных; для диагностики операция должна быть записана в системный журнал и т. д.
Версия со всеми этими новыми проблемами, для примера, могла бы выглядеть примерно так:
void transfer ( Account fromAcc , Account toAcc , int amount , User user , Logger logger , Database database ) выдает исключение { logger . info ( "Перевод денег ..." ); if ( ! isUserAuthorised ( пользователь , fromAcc )) { регистратор . info ( «У пользователя нет разрешения.» ); выбросить новое исключение UnauthorisedUserException (); } if ( fromAcc . getBalance () < количество ) { регистратор . info ( «Недостаточно средств» ); выбросить новое Исключение НедостаточныеФунды (); } fromAcc . снять ( сумма ); toAcc . депозит ( сумма ); база данных . commitChanges (); // Атомарная операция. регистратор . info ( "Транзакция успешна." ); }
В этом примере другие интересы запутались в основных функциях (иногда называемых проблемами бизнес-логики ). Транзакции, безопасность и ведение журналов - все это примеры сквозных проблем .
Теперь подумайте, что произойдет, если нам вдруг понадобится изменить (например) меры безопасности для приложения. В текущей версии программы операции, связанные с безопасностью, разбросаны по многочисленным методам, и такое изменение потребует значительных усилий.
АОП пытается решить эту проблему, позволяя программисту выражать сквозные проблемы в автономных модулях, называемых аспектами . Аспекты могут содержать совет (код, соединенный с указанными точками в программе) и объявления типов (структурные элементы, добавленные в другие классы). Например, модуль безопасности может включать совет, который выполняет проверку безопасности перед доступом к банковскому счету. Срез точки определяет время ( точки соединения ) , когда один может получить доступ к учетной записи в банке, а код в Определяют тела советов , как осуществляется проверка безопасности. Таким образом, и чек, и места могут храниться в одном месте. Кроме того, хороший pointcut может предвидеть более поздние изменения программы, поэтому, если другой разработчик создаст новый метод для доступа к банковскому счету, совет будет применяться к новому методу при его выполнении.
Итак, для приведенного выше примера реализации ведения журнала в аспекте:
Аспект Logger { void Bank . передача ( Аккаунт из Аккаунта , Аккаунт в Аккаунт , int amount , User user , Logger logger ) { logger . info ( "Перевод денег ..." ); } недействителен банк . getMoneyBack ( Пользователь- пользователь , int transactionId , регистратор регистратора ) { регистратор . info ( «Пользователь запросил возврат денег.» ); } // Другой перекрестный код. }
Можно думать об АОП как об инструменте отладки или как об инструменте пользовательского уровня. Совет следует зарезервировать для случаев, когда вы не можете изменить функцию (уровень пользователя) [6] или не хотите изменять функцию в производственном коде (отладка).
Модели точек соединения
Связанный с советами компонент аспектно-ориентированного языка определяет модель точки соединения (JPM). JPM определяет три вещи:
- Когда совет может работать. Они называются точками соединения, потому что они являются точками в работающей программе, где может быть полезно объединить дополнительное поведение. Чтобы точка соединения была полезной, она должна быть адресуемой и понятной для обычного программиста. Он также должен быть стабильным при несущественных изменениях программы, чтобы аспект был стабильным при таких изменениях. Многие реализации АОП поддерживают выполнение методов и ссылки на поля в качестве точек соединения.
- Способ определения (или количественной оценки ) точек соединения, называемый pointcuts . Pointcuts определяет, совпадает ли данная точка соединения. Большинство полезных языков pointcut используют синтаксис, подобный базовому языку (например, AspectJ использует сигнатуры Java) и допускают повторное использование посредством именования и комбинации.
- Средство указания кода для запуска в точке соединения. AspectJ вызывает этот совет и может запускать его до, после и вокруг точек соединения. Некоторые реализации также поддерживают такие вещи, как определение метода в аспекте другого класса.
Модели точек соединения можно сравнивать на основе представленных точек соединения, способа задания точек соединения, операций, разрешенных в точках соединения, и структурных улучшений, которые могут быть выражены.
Модель точки соединения AspectJ
- Точки соединения в AspectJ включают вызов или выполнение метода или конструктора, инициализацию класса или объекта, доступ для чтения и записи полей, обработчики исключений и т. Д. Они не включают циклы, супервызовы, предложения throws, несколько операторов и т. Д.
- Точечные срезы задаются комбинациями примитивных точечных обозначений (PCD).
«Родственные» PCD соответствуют определенному типу точки соединения (например, выполнение метода) и имеют тенденцию принимать в качестве входных данных сигнатуру, подобную Java. Один такой pointcut выглядит так:
исполнение (* установить * (*))
Этот pointcut соответствует точке соединения метода и выполнения, если имя метода начинается с "
set
" и имеется ровно один аргумент любого типа.«Динамические» PCD проверяют типы времени выполнения и связывают переменные. Например,
эта точка)
Этот pointcut соответствует случаю, когда выполняемый в данный момент объект является экземпляром класса
Point
. Обратите внимание, что неполное имя класса можно использовать с помощью обычного поиска типа Java.PCD «области действия» ограничивают лексическую область действия точки соединения. Например:
внутри (com.company. *)
Этот pointcut соответствует любой точке соединения любого типа в
com.company
пакете. Это*
одна из форм подстановочных знаков, которая может использоваться для сопоставления многих вещей с помощью одной подписи.Pointcuts могут быть составлены и названы для повторного использования. Например:
Этот pointcut соответствует точке соединения выполнения метода, если имя метода начинается с "pointcut set () : выполнение ( * set * ( * ) ) && this ( Point ) && внутри ( com . company . * );
set
" иthis
является экземпляром типаPoint
вcom.company
пакете. На него можно ссылаться, используя имя "set()
". - Advice указывает запускать в (до, после или около) точки соединения (указанной с помощью pointcut) определенного кода (указанного как код в методе). Среда выполнения AOP автоматически вызывает Advice, когда pointcut совпадает с точкой соединения. Например: after (): set () {Display.update (); } Это фактически определяет: «если
set()
pointcut совпадает с точкой соединения, запускать кодDisplay.update()
после завершения точки соединения».
Другие потенциальные модели точек соединения
Существуют и другие виды JPM. Все языки рекомендаций могут быть определены в терминах их JPM. Например, гипотетический аспектный язык для UML может иметь следующий JPM:
- Точки соединения - это все элементы модели.
- Pointcuts - это логическое выражение, объединяющее элементы модели.
- Средства воздействия на эти точки - это визуализация всех совпадающих точек соединения.
Межтиповые объявления
Объявления между типами предоставляют способ выразить сквозные проблемы, влияющие на структуру модулей. Также известный как открытые классы и методы расширения , это позволяет программистам объявлять в одном месте членов или родителей другого класса, обычно для того, чтобы объединить весь код, связанный с проблемой, в одном аспекте. Например, если программист реализовал проблему сквозного отображения-обновления, используя вместо этого посетителей, межтиповое объявление с использованием шаблона посетителя может выглядеть в AspectJ следующим образом:
аспект DisplayUpdate { void Point . acceptVisitor ( Посетитель v ) { v . посетить ( это ); } // другой перекрестный код ... }
Этот фрагмент кода добавляет acceptVisitor
метод в Point
класс.
Требуется, чтобы любые структурные дополнения были совместимы с исходным классом, чтобы клиенты существующего класса продолжали работать, если только реализация АОП не может рассчитывать на постоянное управление всеми клиентами.
Выполнение
Программы АОП могут влиять на другие программы двумя разными способами, в зависимости от базовых языков и сред:
- создается комбинированная программа, действительная на языке оригинала и неотличимая от обычной программы до окончательного интерпретатора
- конечный интерпретатор или среда обновляются для понимания и реализации функций АОП.
Сложность изменения среды означает, что большинство реализаций создают совместимые комбинированные программы посредством типа преобразования программ, известного как переплетение . Аспект Weaver считывает аспект-ориентированный код и генерирует соответствующий объектно-ориентированный код с аспектами интегрированных. Один и тот же язык АОП может быть реализован с помощью различных методов переплетения, поэтому семантика языка никогда не должна пониматься в терминах реализации переплетения. Только скорость реализации и простота развертывания зависят от того, какой метод комбинирования используется.
Системы могут реализовать переплетение на уровне исходного кода с помощью препроцессоров (поскольку C ++ изначально был реализован в CFront ), которым требуется доступ к исходным файлам программы. Однако четко определенная двоичная форма Java позволяет ткачам байт-кода работать с любой программой Java в форме файла .class. Ткачи байт-кода могут быть развернуты во время процесса сборки или, если модель плетения для каждого класса, во время загрузки класса. AspectJ начал с переплетения на уровне исходного кода в 2001 году, предоставил ткацкий механизм байт-кода для каждого класса в 2002 году и предложил расширенную поддержку времени загрузки после интеграции AspectWerkz в 2005 году.
Любое решение, объединяющее программы во время выполнения, должно предоставлять представления, которые должным образом разделяют их, чтобы поддерживать раздельную модель программиста. Поддержка байт-кода Java для нескольких исходных файлов позволяет любому отладчику пройти через правильно сплетенный файл .class в редакторе исходного кода. Однако некоторые сторонние декомпиляторы не могут обрабатывать сплетенный код, потому что они ожидают код, созданный Javac, а не все поддерживаемые формы байт-кода (см. Также § Критика ниже).
Ткачество во время развертывания предлагает другой подход. [7] Это в основном подразумевает постобработку, но вместо исправления сгенерированного кода этот подход «переплетения» подклассифицирует существующие классы, так что модификации вносятся путем переопределения методов. Существующие классы остаются нетронутыми даже во время выполнения, и все существующие инструменты (отладчики, профилировщики и т. Д.) Могут использоваться во время разработки. Подобный подход уже зарекомендовал себя в реализации многих Java EE серверов приложений, таких как IBM «s WebSphere .
Терминология
Стандартная терминология, используемая в аспектно-ориентированном программировании, может включать:
- Общие проблемы
- Несмотря на то, что большинство классов в объектно-ориентированной модели будут выполнять одну конкретную функцию, они часто имеют общие вторичные требования с другими классами. Например, мы можем захотеть добавить ведение журнала к классам на уровне доступа к данным, а также к классам на уровне пользовательского интерфейса всякий раз, когда поток входит в метод или выходит из него. Дополнительные проблемы могут быть связаны с безопасностью, такой как контроль доступа [8] или управление информационными потоками . [9] Несмотря на то, что каждый класс имеет очень разные основные функции, код, необходимый для выполнения дополнительных функций, часто идентичен.
- Совет
- Это дополнительный код, который вы хотите применить к существующей модели. В нашем примере это код ведения журнала, который мы хотим применять всякий раз, когда поток входит в метод или выходит из него.
- Pointcut
- Это термин, обозначающий точку выполнения в приложении, к которой необходимо применить сквозное внимание. В нашем примере pointcut достигается, когда поток входит в метод, а другой pointcut достигается, когда поток выходит из метода.
- Аспект
- Комбинация pointcut и совета называется аспектом. В приведенном выше примере мы добавляем аспект ведения журнала в наше приложение, определяя pointcut и давая правильный совет.
Сравнение с другими парадигмами программирования
Аспекты возникли из объектно-ориентированного программирования и вычислительной рефлексии . Языки АОП имеют функции, аналогичные, но более ограниченные, чем протоколы метаобъектов . Аспекты тесно связаны с такими концепциями программирования, как темы , миксины и делегирование . Другие способы использования парадигм аспектно-ориентированного программирования включают фильтры композиции и подход гиперпространств . По крайней мере, с 1970-х годов разработчики использовали формы перехвата и диспетчеризации, которые напоминают некоторые методы реализации АОП, но у них никогда не было семантики, которую предоставляют перекрестные спецификации, написанные в одном месте. [ необходима цитата ]
Разработчики рассмотрели альтернативные способы достижения разделения кода, такие как частичные типы C # , но в таких подходах отсутствует механизм количественной оценки, который позволяет достичь нескольких точек соединения кода с помощью одного декларативного оператора. [ необходима цитата ]
Хотя это может показаться несвязанным, при тестировании использование имитаторов или заглушек требует использования методов АОП, таких как советы и т. Д. Здесь взаимодействующие объекты предназначены для целей теста, сквозной проблемы. Таким образом, различные фреймворки Mock Object предоставляют эти функции. Например, процесс вызывает службу для получения суммы баланса. При тестировании процесса, откуда берется сумма, неважно, только то, что процесс использует баланс в соответствии с требованиями. [ необходима цитата ]
Проблемы с усыновлением
Программистам необходимо уметь читать код и понимать, что происходит, чтобы предотвратить ошибки. [10] Даже при надлежащем образовании понимание сквозных проблем может быть затруднено без надлежащей поддержки для визуализации как статической структуры, так и динамического потока программы. [11] Начиная с 2002 года, AspectJ начал предоставлять плагины IDE для поддержки визуализации пересекающихся проблем. Эти функции, а также помощь в коде аспектов и рефакторинг теперь стали обычным явлением.
Учитывая мощь АОП, если программист совершает логическую ошибку при выражении пересечения, это может привести к повсеместному сбою программы. И наоборот, другой программист может изменить точки соединения в программе - например, путем переименования или перемещения методов - способами, которые автор аспекта не ожидал, с непредвиденными последствиями . Одно из преимуществ модульного построения перекрестных задач состоит в том, что один программист может легко влиять на всю систему; в результате такие проблемы представляют собой конфликт ответственности двух или более разработчиков за конкретный сбой. Однако решение этих проблем может быть намного проще при наличии АОП, поскольку необходимо изменить только аспект, тогда как соответствующие проблемы без АОП могут быть гораздо более распространенными. [ необходима цитата ]
Критика
Основная критика эффекта АОП заключается в том, что поток управления затемнен, и что он не только хуже, чем часто критикуемый GOTO , но и фактически очень похож на шутливую инструкцию COME FROM . [11] забывчивость применения , которая является основой для многих определений АОПА (код в вопросе не имеет никаких признаков того, что совет будет применяться, которая указана вместо того, чтобы в срезе точек), означает , что рекомендации не видны, в отличии на явный вызов метода. [11] [12] Например, сравните программу COME FROM: [11]
5 INPUT X 10 PRINT 'Результат:' 15 PRINT X 20 ПРИХОДИТ ИЗ 10 25 X = X * X 30 ВОЗВРАТ
с фрагментом АОП с аналогичной семантикой:
main () { input x print ( result ( x )) } input result ( int x ) { return x } around ( int x ): call ( result ( int )) && args ( x ) { int temp = continue ( x ) температура возврата * темп}
Действительно, pointcut может зависеть от условий выполнения и, следовательно, не быть статически детерминированным. Это можно смягчить, но не решить с помощью статического анализа и поддержки IDE, показывающих, какие советы потенциально подходят.
Общая критика состоит в том, что АОП стремится улучшить «как модульность, так и структуру кода», но некоторые возражают, что вместо этого он подрывает эти цели и препятствует «независимой разработке и пониманию программ». [13] В частности, количественная оценка с помощью pointcut нарушает модульность: «в общем, нужно обладать знаниями всей программы, чтобы рассуждать о динамическом выполнении аспектно-ориентированной программы». [14] Кроме того, хотя его цели (разбиение на модули сквозных проблем) хорошо понятны, его фактическое определение неясно и не отличается четко от других хорошо зарекомендовавших себя методов. [13] Сквозные проблемы потенциально пересекаются друг с другом, требуя некоторого механизма разрешения, такого как упорядочивание. [13] Действительно, аспекты могут применяться сами по себе, что приводит к таким проблемам, как парадокс лжеца . [15]
Техническая критика включает в себя то, что количественная оценка pointcut (определение того, где выполняются советы) "чрезвычайно чувствительна к изменениям в программе", что известно как проблема хрупкой pointcut . [13] Проблемы с pointcuts считаются неразрешимыми: если заменить количественную оценку pointcut явными аннотациями, вместо этого получится ориентированное на атрибуты программирование , которое является просто явным вызовом подпрограммы и страдает той же проблемой рассеяния, для решения которой был разработан AOP. . [13]
Реализации
Следующие языки программирования реализовали АОП внутри языка или как внешнюю библиотеку:
- Языки .NET Framework ( C # / VB.NET ) [16]
- PostSharp - это коммерческая реализация АОП с бесплатным, но ограниченным выпуском.
- Unity предоставляет API для упрощения проверенных практик в основных областях программирования, включая доступ к данным, безопасность, ведение журнала, обработку исключений и другие.
- ActionScript [17]
- Ада [18]
- AutoHotkey [19]
- C / C ++ [20]
- КОБОЛ [21]
- В какао Objective-C каркасы [22]
- ColdFusion [23]
- Общий Лисп [24]
- Дельфи [25] [26] [27]
- Призма Дельфи [28]
- e (IEEE 1647)
- Emacs Lisp [29]
- Groovy
- Haskell [30]
- Java [31]
- AspectJ
- JavaScript [32]
- Logtalk [33]
- Lua [34]
- сделать [35]
- Matlab [36]
- ML [37]
- Perl [38]
- PHP [39]
- Пролог [40]
- Python [41]
- Ракетка [42]
- Руби [43] [44] [45]
- Squeak Smalltalk [46] [47]
- UML 2.0 [48]
- XML [49]
Смотрите также
- Распределенный АОП
- Грамматика атрибутов - формализм, который можно использовать для аспектно-ориентированного программирования поверх функциональных языков программирования.
- Парадигмы программирования
- Предметно-ориентированное программирование , альтернатива аспектно-ориентированному программированию
- Ролевое программирование , альтернатива аспектно-ориентированному программированию
- Отправка предикатов , старая альтернатива аспектно-ориентированному программированию
- Исполняемый UML
- Шаблон декоратора
- Домен-ориентированный дизайн
Примечания и ссылки
- ^ Kiczales, Г .; Lamping, J .; Mendhekar, A .; Maeda, C .; Lopes, C .; Loingtier, JM; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF) . ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию . LNCS . 1241 . С. 220–242. CiteSeerX 10.1.1.115.8660 . DOI : 10.1007 / BFb0053381 . ISBN 3-540-63089-9. Архивировано (PDF) из оригинала 12 января 2016 года.
- ^ "Адаптивное объектно-ориентированное программирование: подход Деметры с шаблонами распространения" Карл Либхерр 1996 ISBN 0-534-94602-X представляет собой хорошо проработанную версию, по сути, того же самого (впоследствии Либерхерр осознал это и пересмотрел свой подход).
- ^ Дон Бокс; Крис Селлс (4 ноября 2002 г.). Essential.NET: среда CLR . Эддисон-Уэсли Профессионал. п. 206 . ISBN 978-0-201-73411-9. Проверено 4 октября 2011 года .
- ^ Роман, Эд; Сриганеш, Рима Патель; Брозе, Джеральд (1 января 2005 г.). Освоение Enterprise JavaBeans . Джон Вили и сыновья. п. 285. ISBN 978-0-7645-8492-3. Проверено 4 октября 2011 года .
- ^ Примечание. Примеры в этой статье имеют синтаксис, напоминающий синтаксисязыка Java .
- ^ "gnu.org" . www.gnu.org . Архивировано 24 декабря 2017 года . Проверено 5 мая 2018 .
- ^ «Архивная копия» (PDF) . Архивировано из оригинального (PDF) 8 октября 2005 года . Проверен +19 июня 2005 .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 . DOI : 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 .
- ^ Многочисленная: Запоздалая мысль архивации 2016-03-15 в Wayback Machine , LOOM.NET архивации 2008-08-27 в Wayback Machine , Enterprise Library 3.0 Политика Injection Application Block архивации 2007-01-19 в Wayback Machine , AspectDNG архивации 2004 -09-29 в Wayback Machine , DynamicProxy Архивировано 5 декабря 2015 года в Wayback Machine , Compose * Архивировано 21 августа 2005 г. в Wikiwix, PostSharp Архивировано 3 мая 2016 г. в Wayback Machine , Seasar.NET Архивировано 2006 г. 25 июля в Wayback Machine , DotSpect (.SPECT). Архивировано 31 марта 2006 г. в Wayback Machine , Spring.NET. Архивировано 2 апреля 2006 г. в Wayback Machine (как часть его функциональности), Wicca и Phx.Morph. Архивировано 7 декабря 2006 г. в Wayback Machine , SetPoint. Архивировано 7 октября 2008 г. в Wayback Machine.
- ^ «Добро пожаловать в as3-commons-bytecode» . as3commons.org . Архивировано 3 октября 2014 года . Проверено 5 мая 2018 .
- ^ «Обоснование Ada2012» (PDF) . adacore.com . Архивировано 18 апреля 2016 года (PDF) из оригинала . Проверено 5 мая 2018 .
- ^ «Функциональные крючки» . autohotkey.com . Архивировано из оригинального 17 -го января 2013 года . Проверено 5 мая 2018 .
- ^ Несколько: AspectC ++ , FeatureC ++ , AspectC архивации 2006-08-21 в Wayback Machine , аспектно-ориентированный C в архив 2008-11-20 в Wayback Machine , Aspicere
- ^ «Брусчатка» . vub.ac.be . Проверено 5 мая 2018 .[ постоянная мертвая ссылка ]
- ^ «АспектКокаа» . neu.edu . Архивировано из оригинального 26 октября 2007 года . Проверено 5 мая 2018 .
- ^ «ColdSpring Framework: Добро пожаловать» . 5 ноября 2005 года Архивировано из первоисточника 5 ноября 2005 года . Проверено 5 мая 2018 .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 .
- ^ «RemObjects Cirrus» . codegear.com . Архивировано из оригинального 23 января 2012 года . Проверено 5 мая 2018 .
- ^ «Консультационные функции Emacs» . gnu.org . Архивировано 24 октября 2011 года . Проверено 5 мая 2018 .
- ^ Монады позволяют изменять семантику программы путем изменения типа программы без изменения ее кода: Де Мойтер, Вольфганг (1997). «Монады как теоретическая основа АОП». Международный семинар по аспектно-ориентированному программированию в ECOOP . CiteSeerX 10.1.1.25.8262 .Табаро, Николас; Фигероа, Исмаил; Тантер, Эрик (март 2013 г.). «Типизированное монадическое вложение аспектов» . Труды 12-й ежегодной международной конференции по аспектно-ориентированной разработке программного обеспечения . АОСД '13: 171–184. DOI : 10.1145 / 2451436.2451457 . ISBN 9781450317665. S2CID 27256161 . Классы типов позволяют добавлять к типу дополнительные возможности: Зульцманн, Мартин; Ван, Мэн (март 2007 г.). «Аспектно-ориентированное программирование с классами типов» . Материалы 6-го семинара по основам аспектно-ориентированных языков : 65–74. DOI : 10.1145 / 1233833.1233842 . ISBN 978-1595936615. S2CID 3253858 ..
- ^ Многие другие: CaesarJ архивация 2008-12-19 в Wayback Machine , Compose * архивации 2005-08-21 в Wikiwix, Dynaop архивация 2007-07-24 в Wayback Machine , JAC архивация 2004-06-19 в Wayback Machine , Google Guice (как часть его функциональности), Javassist. Архивировано 01 сентября 2004 г. в Wayback Machine , JAsCo (и AWED). Архивировано 11 апреля 2005 г. в Wayback Machine , JAML. Архивировано 15 апреля 2005 г. в 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 (КСБ) Архивированные 2014-12-16 в Wayback Machine , Spring Framework (как часть его функциональности), Seasar , JMangler проект архивации 2005-10-28 в Wayback Machine , InjectJ Архивированного 2005- 04.05 в Wayback Machine , GluonJ Архивировано 06.02.2007 в Wayback Machine , Steamloom Архивировано 18.08.2007 в Way назад машина
- ^ Много: Полезности архивации 2008-07-04 в Wayback Machine , Ajaxpect архивации 2016-07-09 в Wayback Machine , JQuery АОП плагин архивации 2008-01-13 в Wayback Machine , Aspectes архивации 2006-05-08 в 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 , Prototype - Prototype Function # 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 .
- ^ Адам Кеннеди. «Аспект - аспектно-ориентированное программирование (АОП) для 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 г. at the Wayback Machine , расширение AOP PECL, заархивированное 11 апреля 2017 г., на Wayback Machine
- ^ "bigzaphod.org скоро появится" . www.bigzaphod.org . Архивировано 20 апреля 2016 года . Проверено 5 мая 2018 .
- ^ Несколько: PEAK архивация 2005-04-09 в Wayback Machine , Aspyct АОПЕ , Lightweight Python АОП Архивированных 2004-10-09 в Wayback Machine , аспект модуль Logilab в архивации 2005-03-09 в Wayback Machine , Pythius Архивированного 2005- 04-08 в Wayback Machine , модуль АОП Spring Пайтона архивации 2016-03-04 в Wayback Machine , модуль Pytilities' АОП архивации 2011-08-25 в Wayback Machine , aspectlib Архивированные 2014-11-05 в Wayback Machine
- ^ "Репозиторий пакетов PLaneT: PLaneT> dutchyn> sizescheme.plt" . Архивировано 5 сентября 2015 года . Дата обращения 11 августа 2015 .
- ^ «AspectR - Простое аспектно-ориентированное программирование на Ruby» . Архивировано 12 августа 2015 года . Дата обращения 11 августа 2015 .
- ^ Дин Уэмплер. «Дом» . Архивировано из оригинального 26 октября 2007 года . Дата обращения 11 августа 2015 .
- ^ "gcao / aspector" . GitHub . Архивировано 4 января 2015 года . Дата обращения 11 августа 2015 .
- ^ «АСПЕКТЫ» . tu-ilmenau.de . Архивировано из оригинала 6 января 2006 года . Проверено 5 мая 2018 .
- ^ «MetaclassTalk: отражение и метапрограммирование в Smalltalk» . Архивировано из оригинала 29 июля 2015 года . Дата обращения 11 августа 2015 .
- ^ «WEAVR» . iit.edu . Архивировано 12 декабря 2008 года . Проверено 5 мая 2018 .
- ^ «Aspectxml - Аспектно-ориентированный механизм создания XML (AXLE) - Хостинг проектов Google» . Архивировано 12 сентября 2015 года . Дата обращения 11 августа 2015 .
дальнейшее чтение
- Кичалес, Г .; Lamping, J .; Mendhekar, A .; Maeda, C .; Lopes, C .; Loingtier, JM; Ирвин, Дж. (1997). Аспектно-ориентированное программирование (PDF) . ЭКООП '97. Материалы 11-й Европейской конференции по объектно-ориентированному программированию . LNCS . 1241 . С. 220–242. CiteSeerX 10.1.1.115.8660 . DOI : 10.1007 / BFb0053381 . ISBN 3-540-63089-9. Этот документ обычно считается авторитетным справочником по АОП.
- Андреас Хольцингер; М. Бруггер; В. Слэни (2011). Применение аспектно-ориентированного программирования (АОП) в процессах юзабилити-инжиниринга: на примере отслеживания информации об использовании для удаленного тестирования юзабилити . Материалы 8-й Международной конференции по электронному бизнесу и телекоммуникациям. Севилья . Д. А. Марка, Б. Шишков и М. В. Синдерен (редакторы). С. 53–56.
- Роберт Э. Филман; Цилла Эльрад; Сиобхан Кларк; Мехмет Аксит (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 г.
- Zambrano Polo y La Borda, Артуро Федерико (5 июня 2013 г.). «Решение аспектов взаимодействия в промышленных условиях: опыт, проблемы и решения» : 159 . Проверено 30 мая 2014 . Цитировать журнал требует
|journal=
( помощь ) - Виджесурия, Вирадж Брайан (2016-08-30) Аспектно-ориентированное развитие, конспект лекций, Школа вычислительной техники Университета Коломбо, Шри-Ланка
- Гровс, Мэтью Д. (2013). АОП в .NET . ISBN 9781617291142.
Внешние ссылки
- Список инструментов АОП Эрика Боддена в .NET Framework
- Аспектно-ориентированная разработка программного обеспечения , ежегодная конференция по АОП
- Руководство по программированию AspectJ
- Компилятор AspectBench для AspectJ , еще одной реализации Java
- Серия статей IBM developerWorks по АОП
- Ладдад, Рамнивас (18 января 2002 г.). «Я хочу мой АОП !, Часть 1» . JavaWorld . Проверено 20 июля 2020 . Подробный цикл статей по основам аспектно-ориентированного программирования и AspectJ
- Что такое аспектно-ориентированное программирование? , знакомство с RemObjects Taco
- Аспект ограничения-спецификации Weaver
- Аспектное и объектно-ориентированное программирование: какой метод и когда?
- Грегор Кичалес, профессор компьютерных наук, объясняет АОП , видео 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 ViewModels