АОП Следует ли мне отучиться от ООП?

Что в двух словах представляет собой аспектно-ориентированное программирование?

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

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

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

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

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

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

log.write("hello");

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

Могу ли я преобразовать одно в другое?

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуемая литература: Eclipse AspectJ: аспектно-ориентированное программирование с AspectJ и Инструменты разработки Eclipse AspectJ