АОП... Должен ли я освобождать ООП?

Ответ 1

Что вкратце, ориентированное на аспект программирования?

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

Это просто лучше, чем объектно-ориентированное программирование? Должен ли я высвобождать ООП?

Нет, и нет. Он работает вместе с любой средой программирования, которая ее поддерживает. (См. Выше).

Если нет, как узнать, когда использовать тот или иной? Каковы основные различия между ними?

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

Как и выше, основное отличие на самом деле не существует, поскольку они не сопоставимы. Но, скажем, вы хотите выполнить регистрацию "нормально", вы просто вызываете регистратор в соответствующих точках:

log.write("hello");

Но с AOP вы можете создать "аспект", который присоединяется к каждому вызову метода, и log "Method b called". Дело в том, что в АОП вы приближаетесь больше "дробовиком": вы привязываетесь ко всему или просто небольшому подмножеству. Обычно добавление журнала обычно лучше.

Можно ли переделать один в другой?

Не очень важно, см. другие ответы. Опять же, с безопасностью, вы можете поменять модель AOP на типичную модель OOP this.IsAllowed() на что-то вроде if (callMethod.HasAttribute(foo)) {allowed = true; }

Надеюсь, что эти ответы полезны. Дайте мне знать, если вы хотите, чтобы я расширился дальше.

Ответ 2

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

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

Ответ 3

АОП отличается от ООП, совершенно разными подходами к разработке.

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

Что касается того, когда использовать AOP или OOP, я бы предложил вам написать программу, заставить ее работать, а затем, когда вы ее используете, посмотрите на удаление кода, который на самом деле не связан с функцией, но служит для некоторых другой цели. Например, если вам нужно проверить правильность входных параметров перед их использованием, используйте для этого аспект. Если у вас есть аналогичная обработка событий, такая как все исключения, сброшенные на уровне доступа к данным, записываются в файл журнала, затем создайте для этого аспект.

Когда вы удалите эти проблемы с перекрестными ссылками, ваш код станет меньше.

По мере того как вы получите больше опыта, вы увидите больше возможностей для AOP, но сначала я бы предложил написать его, а затем рефакторинг с помощью AOP.

Используйте Eclipse, если используете Java, для AOP, поскольку плагин AJDT будет очень полезен, чтобы увидеть, где вы добавляете аспекты.

Ответ 4

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

Несколько лет назад Raymie Stata написал блестящую докторскую диссертацию о том, как объектно-ориентированные языки могут контролировать подклассификацию и препятствовать ее нарушению ключевых инвариантов. Соответствующая работа для АОП еще не написана.

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

Ответ 5

Рекомендуемое чтение: Eclipse AspectJ: аспектно-ориентированное программирование с помощью AspectJ и инструментов разработки Eclipse AspectJ