the landlord feels trapped in a misunderstanding of the enrollment design pattern, which essentially exists to solve a certain kind of problem, so there is no need to think of the design pattern as the same as the mathematical formula. The differences between different design patterns may be exactly the same in implementation, but different problems are solved by different patterns; the main purpose of the adapter pattern is to convert An interface to B interface, as long as it is implemented for this purpose, then it is the adapter pattern. I don't know exactly what this pattern is because I haven't used spring,. But from the intuitive function to guess, it feels more like a policy mode, different AdvisorAdapter implements different policies

my personal understanding is that first of all, Spring is an interface-oriented framework, which determines that it must be extensible, then when users follow the Spring specification to customize the interface, unpredictable factors cannot cooperate at runtime, resulting in program down. It has come up with one or more ways to solve these problems, so Spring provides you with A, B, C, D extensible upper-level specifications to solve runtime dynamic proxy binding problems. Because your custom interface is based on Spring, it must also follow the Spring specification, so when it finds that you need B, then assemble a B tool or object to be compatible with your interface and complete your work to achieve peaceful cooperation, just like matching by name and matching by type. It is concluded that the core of the adapter pattern is: the idea of mathematical classification discussion, but here the classification is not a specific person but Spring.

adapter pattern has two forms, one is the adapter form of the class (using inheritance implementation), and the other is the adapter form of the object (using aggregation implementation), which is the adapter form of the class.

    public MethodInterceptor getInterceptor(Advisor advisor) {  
        MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();  
        return new MethodBeforeAdviceInterceptor(advice);  
    }  

the adapter pattern is indeed used here, and you can put aside the rest of the spring code and focus on the code about the adapter.
this article is about adapter patterns, but policy patterns are not the focus of this article.

but there is a problem with this article, that is, the Adaptee and Target, of the adapter pattern. Here Adaptee should be the Advisor class and Target should be the MethodBeforeAdvice class. I think this may be due to the blogger's negligence.

MethodBeforeAdvice:Adaptee
Adapter:Target
MethodBeforeAdviceAdapterAdapter