Аспектно-ориентированное программирование против.Объектно-ориентированного программирования
https://stackoverflow.com/questions/232884
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Как и большинство разработчиков здесь и во всем мире, я уже много лет занимаюсь разработкой программных систем с использованием методов объектно-ориентированного программирования (ООП).Поэтому, когда я читаю, что аспектно-ориентированное программирование (АОП) решает многие проблемы, которые традиционное ООП не решает полностью или напрямую, я останавливаюсь и думаю, реально ли это?
Я прочитал много информации, пытаясь изучить ключи этой парадигмы АОП, и я нахожусь в том же месте, поэтому я хотел лучше понять ее преимущества в разработке реальных приложений.
Есть ли у кого-нибудь ответ?
Решение
Почему «против»?Это не «против».Вы можете использовать аспектно-ориентированное программирование в сочетании с функциональным программированием, а также в сочетании с объектно-ориентированным программированием.Это не «против», это «Аспектно-ориентированное программирование». с Объектно-ориентированного программирования".
Для меня АОП — это своего рода «метапрограммирование».Все, что делает АОП, можно сделать и без него, просто добавив больше кода.АОП просто избавляет вас от написания этого кода.
В Википедии есть один из лучших примеров такого метапрограммирования.Предположим, у вас есть графический класс со множеством методов «set...()».После каждого установленного метода данные графики изменяются, поэтому графика меняется, и поэтому графику необходимо обновлять на экране.Предположим, что для перерисовки графики необходимо вызвать «Display.update()».Классический подход состоит в том, чтобы решить эту проблему, добавив больше кода.В конце каждого метода set вы пишете
void set...(...) {
:
:
Display.update();
}
Если у вас есть 3 метода set, это не проблема.Если у вас есть 200 (гипотетических), становится очень больно добавлять это повсюду.Кроме того, всякий раз, когда вы добавляете новый метод set, вы должны не забыть добавить его в конец, иначе вы просто создадите ошибку.
АОП решает эту проблему без добавления тонны кода, вместо этого вы добавляете аспект:
after() : set() {
Display.update();
}
Вот и все!Вместо того, чтобы писать код обновления самостоятельно, вы просто сообщаете системе, что после достижения точки set() она должна запустить этот код, и она запустит этот код.Нет необходимости обновлять 200 методов, не нужно следить за тем, чтобы вы не забыли добавить этот код в новый метод set.Кроме того, вам просто нужен pointcut:
pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);
Что это значит?Это означает, что если метод называется «set*» (* означает, что после set может следовать любое имя), независимо от того, что возвращает метод (первая звездочка) или какие параметры он принимает (третья звездочка). и это метод MyGraphicsClass и этот класс является частью пакета «com.company.*», тогда это pointcut set().И наш первый код говорит: «после запустив любой метод, являющийся набором pointcut, запустите следующий код».
Видите, как АОП элегантно решает эту проблему?На самом деле все, что здесь описано, можно сделать во время компиляции.Препроцессор АОП может просто изменить ваш исходный код (например,добавление Display.update() в конец каждого метода set-pointcut) еще до компиляции самого класса.
Однако этот пример также демонстрирует один из больших недостатков АОП.АОП на самом деле делает то, что многие программисты считают «Антипаттерн".Точный шаблон называется "Действие на расстоянии".
Действие на расстоянии-это анти-паттерн (признанная общая ошибка), в которой поведение в одной части программы варьируется в зависимости от трудного или невозможного для выявления операций в другой части программы.
Будучи новичком в проекте, я мог бы просто прочитать код любого метода set и посчитать его сломанным, поскольку он, похоже, не обновляет отображение.Я не видеть просто взглянув на код метода set, можно увидеть, что после его выполнения «волшебным образом» будет выполнен какой-то другой код для обновления дисплея.Считаю это серьезным минусом!При внесении изменений в метод могут возникнуть странные ошибки.Дальнейшее понимание потока кода, где некоторые вещи работают правильно, но не очевидны (как я уже сказал, они просто волшебным образом работают...почему-то), это действительно сложно.
Обновлять
Просто чтобы уточнить это:У некоторых людей может сложиться впечатление, что я говорю, что АОП — это что-то плохое, и его не следует использовать.Я не это говорю!АОП на самом деле отличная функция.Я просто говорю: «Используйте осторожно».АОП вызовет проблемы только в том случае, если вы перепутаете обычный код и АОП для одного и того же. Аспект.В приведенном выше примере у нас есть Аспект обновления значений графического объекта и рисования обновленного объекта.На самом деле это один аспект.Кодирование половины его как обычного кода, а другой половины как аспекта — вот что добавляет проблему.
Если вы используете АОП для совершенно другого аспекта, например.при ведении журнала вы не столкнетесь с проблемой анти-шаблона.В этом случае новичок в проекте может задаться вопросом: «Откуда берутся все эти сообщения журнала?Я не вижу вывода журнала в коде», но это не большая проблема.Изменения, которые он вносит в логику программы, вряд ли нарушат функцию журнала, а изменения, внесенные в функцию журнала, вряд ли нарушат логику его программы - эти аспекты полностью разделены.Использование АОП для ведения журнала имеет то преимущество, что ваш программный код может полностью сконцентрироваться на выполнении того, что он должен делать, и вы по-прежнему можете осуществлять сложное ведение журнала, не загромождая свой код сотнями сообщений журнала повсюду.Кроме того, когда вводится новый код, волшебным образом сообщения журнала появляются в нужное время с нужным содержанием.Программист-новичок может не понимать, почему они здесь и откуда взялись, но поскольку они зарегистрируют «нужные вещи» в «нужное время», он может просто с радостью принять тот факт, что они здесь, и перейти к чему-то другому. .
Поэтому хорошим использованием АОП в моем примере было бы всегда регистрировать, если какое-либо значение было обновлено с помощью метода set.Это не создаст анти-шаблона и вряд ли когда-либо станет причиной каких-либо проблем.
Можно сказать, что если вы можете легко злоупотребить АОП и создать столько проблем, то использовать все это — плохая идея.Однако какой технологией нельзя злоупотреблять?Вы можете злоупотреблять инкапсуляцией данных, злоупотреблять наследованием.Практически любая полезная технология программирования может быть использована неправильно.Представьте себе язык программирования, настолько ограниченный, что он содержит только функции, которыми нельзя злоупотреблять;язык, в котором функции можно использовать только так, как они изначально предполагались.Такой язык был бы настолько ограниченным, что можно было бы спорить, можно ли его вообще использовать для программирования в реальном мире.
Другие советы
ООП и АОП не являются взаимоисключающими. АОП может быть хорошим дополнением к ООП. AOP особенно удобен для добавления стандартного кода, такого как ведение журнала, отслеживание производительности и т. Д., К методам без засорения кода метода этим стандартным кодом.
аспектно-ориентированное программирование обеспечивает хороший способ реализации сквозных задач, таких как ведение журнала и безопасность. Эти сквозные концепции представляют собой кусочки логики, которые должны применяться во многих местах, но на самом деле не имеют ничего общего с бизнес-логикой.
Вы не должны рассматривать АОП как замену ООП, а скорее как хорошее дополнение, которое делает ваш код более чистым, слабосвязанным и ориентированным на бизнес-логику. Таким образом, применяя АОП, вы получите 2 основных преимущества:
<Ол>Логика для каждой задачи теперь находится в одном месте, а не разбросана по всей базе кода.
более чистые, поскольку они содержат код только для своей основной задачи (или основной функциональности), а вторичные проблемы были перенесены в аспекты.
Я думаю, что нет общего ответа на этот вопрос, но следует отметить, что AOP не заменяет ООП, а добавляет некоторые функции декомпозиции, которые обращаются к так называемой тирании доминирующий состав ( 1 ) (или сквозные вопросы).
Это, безусловно, помогает в определенных случаях, пока вы контролируете инструменты и языки, используемые для конкретного проекта, но также добавляет новый уровень сложности в отношении взаимодействия аспектов и необходимости в дополнительных инструментах, таких как < a href = "http://www.eclipse.org/ajdt" rel = "nofollow noreferrer"> AJDT , чтобы по-прежнему понимать вашу программу.
Грегор Кичалес однажды выступил с интересной вступительной речью по AOP на Google Tech Talks, которую я рекомендую посмотреть: Аспектно-ориентированное программирование: радикальное исследование модульности .
Прежде всего, АОП не заменит ООП. АОП расширяет ООП. Идеи и практики ООП остаются актуальными. Хороший дизайн объекта, вероятно, облегчит его расширение аспектами.
Я думаю, что идеи, которые приносит АОП, важны. Нам нужно разработать способы реализации сквозных задач для разных классов в вашей программе без необходимости изменения самих классов. Но я думаю, что в конечном итоге АОП просто станет частью других инструментов, которые мы используем, а не отдельным инструментом или техникой. Мы уже видим, как это происходит.
У нескольких динамических языков, таких как Ruby и Python, есть языковые конструкции, такие как миксины, которые решают те же проблемы. Это похоже на АОП, но лучше интегрировано в язык.
Spring и Castle и пара других структур внедрения зависимостей имеют опции для добавления поведения к классам, которые они внедряют. Это способ выполнения ткачества во время выполнения, и я думаю, что у этого есть большой потенциал.
Я не думаю, что вам придется изучать совершенно новую парадигму, чтобы использовать AOP. Идеи интересны, но постепенно усваиваются существующими инструментами и языками. Просто будьте в курсе и опробуйте эти инструменты.
AOP - это новая парадигма программирования, связанная с этой концепцией. Аспектом является программный объект, реализующий конкретную нефункциональную часть приложения.
Я думаю, что эта статья - хорошее место, чтобы начать с Аспектно-ориентированного программирования: http://www.jaftalks.com/wp/ index.php / введение к аспектно-ориентированное программирование /
OOP в основном используется для организации бизнес-логики , а AOP помогает организовать нефункциональные вещи . такие как аудит, ведение журнала, управление транзакциями, безопасность и т. д.
Таким образом, вы можете отделить свою бизнес-логику от вымышленной логики, которая делает код чище.
Преимущество выдры в том, что вы можете применять рекомендации (например, аудит) очень согласованно, не реализуя интерфейс, который дает большую гибкость для модификации, не затрагивая бизнес-логику
