Секретность
Предположим, что у нас существует часть параметров объектов модели, которые не должны быть видимы для определённого типа пользователей, но в тоже время видны для остальных. Для примера рассмотрим тот же самый альбом с фотографиями, но некоторые фотографии в каждом альбоме могут быть помечены как приватные, то есть видны только «друзьям» создателя альбома, в этом случае получаем следующее взаимодействие:
Как видно, здесь мы опять получили зависимость между слоем отображения и слоем авторизации. Кроме того, опять же необходимо контролировать, что все вызовы к методам возвращающим «секретные» данные должны быть окружены проверками пользователями, что очень трудно проконтролировать (представьте себе какой урон безопасности системы может нанести не окружённый проверками метод).
Усовершенствовав приведенный выше авторизационный аспект, мы с лёгкостью можем точно разграничить доступ даже к отдельным полям объекта данных, тем самым реализовывать такую систему доступа данным, которая подходит именно для нашего приложения. Достоинства АОП очевидны, т.к. обычно никакого изменения в исходной системе не производится.
Кроме того, AspectJ даёт нам ещё один очень интересный инструмент – ограничения на статическую структуру приложения. Так как внедрение аспектов производится во время компиляции специальным компилятором, то существует возможность создать определённые правила, накладывающие ограничения на структуру и внутреннее взаимодействие объектов системы (статическую структуру). Например, мы можем определить правило - вызовы методов объектов модели приводящих к изменению состояния доступны только из «контроллеров». Или, например, что бы классы модели не были связанны с классами уровня контроллеров. В случае не соблюдения правил AspectJ компилятор может либо просто выдать предупреждение, либо прервать компиляцию с фатальной ошибкой (в зависимости от определения правила).
