Пример использования поперечной резки

Ответ 1

Прежде чем понимать Перекрестный вызов, нам нужно понять Концерн.

A Концерн - это термин, который относится к части системы, разделенной на основе функциональности.

Озабоченность представляет собой два типа:

• Проблемы, представляющие единую и специфическую функциональность для первичных требований, известны как основные проблемы.
  ИЛИ
  Первичная функция системы известна как основная проблема.
  Например: бизнес-логика
• Проблемы, представляющие функциональные возможности для вторичных требований, называются сквозными проблемами или общесистемными проблемами.
  ИЛИ
  сквозная проблема - это проблема, которая применима во всем приложении и влияет на все приложение.
  Например: протоколирование, безопасность и передача данных - это проблемы, которые необходимы практически для каждого модуля приложения, поэтому они являются сквозными проблемами.

Предоставлено

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

(любезность)

Ответ 2

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

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

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

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

Ответ 3

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

Теперь позвольте мне рассказать вам небольшую историю о "тривиальных" вещах, таких как выход журнала: всего несколько недель назад я реорганизовал сложную, но не слишком большую базу кода (около 250 тыс. строк кода) для клиента. В нескольких сотнях классов использовался один вид системы каротажа, еще в нескольких сотнях других. Затем было несколько тысяч строк System.out.println(*), где действительно должен был быть выход журнала. Таким образом, я закончил с фиксацией тысяч строк кода, разбросанных по всей базе кода. К счастью, я мог использовать некоторые хитроумные трюки в IntelliJ IDEA (структурный поиск и замена), чтобы ускорить все действия, но, мальчик, вы не думаете, что это было тривиально! Конечно, зависящее от контекста ведение журнала отладки всегда будет происходить внутри тела метода, но многие важные типы ведения журнала, такие как вызовы метода трассировки (даже иерархически с выводом с отличным отступом), протоколирование как обработанных, так и необработанных исключений, аудит пользователя (ведение журнала вызовов ограниченные методы, основанные на пользовательских ролях) и т.д. могут быть легко реализованы в аспектах без их загрязнения исходным кодом. Разработчику повседневных приложений не нужно думать об этом или даже видеть вызовы журнала, разбросанные по базе кода. Кто-то несет ответственность за поддержание актуальности этого аспекта и даже может переключать стратегию ведения журнала или всю систему ведения журнала централизованно в одном месте.

Я могу придумать похожие объяснения для других сквозных проблем. Идентификация кода чистым и свободным от рассеяния и запутывания ИМО - это вопрос профессионализма, а не что-то необязательное. И последнее, но не менее важное: код читается, поддерживается, рефакторизуем. Аминь.