Well, the core essence of this problem is determined by the mechanism of the JDK dynamic proxy itself. First of all, in Java, dynamic proxy is realized through Proxy.newProxyInstance() method, which needs to pass in the interface class to be dynamically proxied.
The reason why the interface cannot be passed in is that it depends on the underlying implementation of the JDK dynamic proxy (as shown in the figure).
The JDK dynamic proxy will dynamically generate a proxy class $Proxy0 during the running of the program. This dynamically generated proxy class
It will inherit the java.lang.reflect.Proxy class, and will also implement the interface IHelloService of the proxy class.
In Java, multiple inheritance is not supported. And each dynamic proxy class will inherit the Proxy class (this is also the JDK
The implementation specification of dynamic proxy), so the dynamic proxy in the JDK can only proxy the interface, not the proxy
Implementation class.
I have analyzed the source code of the dynamic proxy and found that the Proxy class just saves the processor of the dynamic proxy
InvocationHandler, if you don’t extract it, you can directly set it in the dynamic proxy class of $Proxy0
of.
If you do this, you can do dynamic proxy for the implementation class. Why did the author design this way, I think there are several
reasons.
1. The usage scenarios or requirements of the dynamic proxy itself are just an interception of the original implementation, and then do some functions
Enhancement or extension of capabilities. The actual development model is also based on interface-oriented development, so interface-based
To realize dynamic proxy, the requirements and scenarios are consistent. Of course, there may indeed be some classes that do not implement the interface
Well, at this time, the JDK dynamic proxy is really not enough.
2. In Java, the design of the inheritance relationship of classes is more about the abstraction of common ability, so as to improve
Code reusability and scalability, and dynamic proxy is also doing such a thing, it encapsulates the dynamic proxy class
Generated abstract logic, judging whether a class is a dynamic proxy class,
InvocationHandler holds, etc.,
Then it is obviously a relatively normal setting to put these abstract public logics in the parent class of Proxy.
Thinking.
In general, I don't think there is anything particularly worth discussing about this design, because I think the technical solution
Design is to solve specific scene problems.
If you must do dynamic proxy for ordinary classes, you can choose the cglib component, which will dynamically generate a proxy
The subclass of the proxy class, the subclass rewrites all non-final modified methods in the parent class, and intercepts all methods of the parent class in the subclass
Method calls to achieve dynamic proxy.