Каков хороший пример cross-cutting concern? Пример медицинской записи на странице wikipedia кажется мне неполным.
В частности, из этого примера, почему регистрация ведет к дублированию кода (рассеянию)? (Помимо простых вызовов, таких как log("....") повсюду, что не похоже на большое дело).
В чем разница между core concern и a cross-cutting concern?
Моя конечная цель - лучше понять АОП.
Прежде чем понимать Перекрестный вызов, нам нужно понять Концерн.
A Концерн - это термин, который относится к части системы, разделенной на основе функциональности.
Озабоченность представляет собой два типа:
Эта цифра представляет собой типичное приложение, разбитое на модули. В каждом модуле основная задача - предоставлять услуги для своего конкретного домена. Однако для каждого из этих модулей также требуются аналогичные вспомогательные функции, такие как ведение журнала безопасности и управление транзакциями. Примером проблем с перекрестными ссылками является "ведение журнала", которое часто используется в распределенных приложениях, чтобы помочь отлаживать вызовы методов трассировки. Предположим, что мы регистрируемся как в начале, так и в конце каждого тела функции. Это приведет к пересечению всех классов, имеющих хотя бы одну функцию.
Я считаю, что единственным лучшим примером межсекторальной озабоченности является транзакционное поведение. Например, для того, чтобы положить блоки try-catch с помощью вызовов фиксации и отката во всех ваших методах обслуживания, можно отталкивать. Аннотирование методов маркером, который АОП может использовать для инкапсуляции с требуемым транзакционным поведением, является большой победой.
Другим хорошим кандидатом в качестве примера межсекторальной проблемы является авторизация. Аннотирование метода услуги с помощью маркера, который сообщает, кто может его вызывать, и позволяя некоторым советам AOP решить, разрешать ли вызов метода или нет, может быть предпочтительнее обрабатывать это в коде метода службы.
Реализация ведения журнала с помощью советов AOP может стать способом получения большей гибкости, так что вы можете изменить то, что регистрируется, изменяя точку соединения. На практике я не вижу проектов, которые делают это очень часто. Обычно, используя библиотеку, такую как log4j, которая позволяет фильтровать по уровням ведения журналов и категориям, во время выполнения, если вам нужно, работает достаточно хорошо.
Основная проблема - причина, по которой приложение существует, бизнес-логику, которую приложение автоматизирует. Если у вас есть приложение для логистики, которое занимается доставкой грузов, выяснение того, сколько груза вы можете упаковать на грузовике или какой лучший маршрут для грузовика, чтобы взять его поставки, может быть основной проблемой. Общие проблемы - это, как правило, детали реализации, которые необходимо соблюдать отдельно от бизнес-логики.
В дополнение к принятому ответу я хочу упомянуть еще один пример для сквозной проблемы: удаленный доступ. Скажем, я просто хочу называть другие компоненты в своей экосистеме локально, как если бы они работали в процессе. Возможно, в некоторых случаях они даже делают. Но теперь я хочу запускать свои службы, распространяемые в облаке или кластере. Почему я должен заботиться об этом аспекте как разработчик приложения? Один аспект может позаботиться о том, чтобы узнать, кому звонить и как, сериализовать переданные данные, если это необходимо, и сделать удаленный вызов. Если все будет запущено в процессе, этот аспект будет просто перенаправлять локальный вызов. На стороне вызываемого лица аспект будет десериализовать данные, сделать локальный вызов и вернуть результат.
Теперь позвольте мне рассказать вам небольшую историю о "тривиальных" вещах, таких как выход журнала: всего несколько недель назад я реорганизовал сложную, но не слишком большую базу кода (около 250 тыс. строк кода) для клиента. В нескольких сотнях классов использовался один вид системы каротажа, еще в нескольких сотнях других. Затем было несколько тысяч строк System.out.println(*), где действительно должен был быть выход журнала. Таким образом, я закончил с фиксацией тысяч строк кода, разбросанных по всей базе кода. К счастью, я мог использовать некоторые хитроумные трюки в IntelliJ IDEA (структурный поиск и замена), чтобы ускорить все действия, но, мальчик, вы не думаете, что это было тривиально! Конечно, зависящее от контекста ведение журнала отладки всегда будет происходить внутри тела метода, но многие важные типы ведения журнала, такие как вызовы метода трассировки (даже иерархически с выводом с отличным отступом), протоколирование как обработанных, так и необработанных исключений, аудит пользователя (ведение журнала вызовов ограниченные методы, основанные на пользовательских ролях) и т.д. могут быть легко реализованы в аспектах без их загрязнения исходным кодом. Разработчику повседневных приложений не нужно думать об этом или даже видеть вызовы журнала, разбросанные по базе кода. Кто-то несет ответственность за поддержание актуальности этого аспекта и даже может переключать стратегию ведения журнала или всю систему ведения журнала централизованно в одном месте.
Я могу придумать похожие объяснения для других сквозных проблем. Идентификация кода чистым и свободным от рассеяния и запутывания ИМО - это вопрос профессионализма, а не что-то необязательное. И последнее, но не менее важное: код читается, поддерживается, рефакторизуем. Аминь.