Как внедряется АОП?

Question

Я прочитал о АОП guice в документации здесь: - https://github.com/google/guice/wiki/AOP Из документации: -

За кулисами, перехват метода осуществляется путем генерации байт-кода во время выполнения , Guice динамически создает подкласс, который применяет перехватчики путем переопределения методов. Если вы находитесь на платформе, которая не поддерживает генерацию байт-кода (например, Android), вы должны использовать Guice без поддержки AOP.

Что означает документация, расширяя подкласс. Это подкласс метода перехватчика? Работает ли это с помощью отражения, чтобы перехватить метод? Причина, по которой я задаю этот вопрос, заключается в том, что в документации за этой строкой следует следующее: -

В связи с этим у нас есть следующие ограничения на шаблон AOP

a) AOP не может быть применен к частному методу.

Мне неясно, почему AOP нельзя применить к частному методу.

Answer 1

Мне непонятно, почему AOP нельзя применить к частному методу.

Поскольку частные методы не наследуются подклассами, т. Е. Нет способа перехватить частный метод и затем делегировать к этому, потому что подкласс не может даже вызвать этот метод. Это нормальное ограничение Java, которое не имеет ничего общего с AOP.

Кстати, если вам нужен полноценный мощный инструмент AOP, работающий с любым языком JVM и способный перехватывать частные методы без необходимости чтобы использовать динамические c прокси (подклассы, созданные во время выполнения, такие как Guice или Spring AOP), просто используйте AspectJ.

Что означает документация, расширяя подкласс.

JRE знает концепцию dynamici c прокси , чтобы иметь возможность перехватывать вызовы методов и (необязательно) делегировать исходный вызов до / после выполнения чего-либо еще в методе-перехватчике. Это работает только для интерфейсов, но CGLIB распространяет эту концепцию на подклассы неинтерфейсных классов, поэтому в реализациях AOP на основе прокси, таких как Spring AOP (и, возможно, Guice, не уверен на 100%), используются прокси для реализации AOP , AspectJ работает по-другому, он не использует или не нуждается в динамических прокси c или других типах подклассов.