1.什么是代理模式
代理模式的定义：为其他对象提供一种[代理]以控制对这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用.
分为静态代理和动态代理两种类型。
2.UML模式结构
image.png
代理模式的结构比较简单，包含如下三个角色：
-
Subject（抽象主题角色）：它声明了真实主题和代理主题的共同接口，这样一来在任何使用真实主题的地方都可以使用代理主题，客户端通常需要针对抽象主题角色进行编程。
-
Proxy（代理主题角色）：它包含了对真实主题的引用，从而可以在任何时候操作真实主题对象；在代理主题角色中提供一个与真实主题角色相同的接口，以便在任何时候都可以替代真实主题；代理主题角色还可以控制对真实主题的使用，负责在需要的时候创建和删除真实主题对象，并对真实主题对象的使用加以约束。通常，在代理主题角色中，客户端在调用所引用的真实主题操作之前或之后还需要执行其他操作，而不仅仅是单纯调用真实主题对象中的操作。
-
RealSubject（真实主题角色）：它定义了代理角色所代表的真实对象，在真实主题角色中实现了真实的业务操作，客户端可以通过代理主题角色间接调用真实主题角色中定义的操作。
3.典型代码
抽象主题类声明了真实主题类和代理类的公共方法，它可以是接口，抽象类或具体类，客户端针对抽象主题类编程，一致性地对待真实主题和代理主题，典型的抽象主题类代码如下：
public interface Subject {
void request();
}
真实主题代码:
public class RealSubject implements Subject {
public void request() {
// todo
}
}
代理类代码:
public class Proxy implements Subject {
private RealSubject realSubject = new RealSubject();//真实主题的引用
public void request() {
postRequest();
realSubject.request();
postRequest();
}
public void preRequest(){
//todo
}
public void postRequest(){
//todo
}
}
4.示例代码
在开始之前，我们先假设这样一个场景：有一个蛋糕店，他们卖的蛋糕都是用蛋糕机做的。而且不同种类的蛋糕由不同的蛋糕机来做，这样有：水果蛋糕机，巧克力蛋糕机等。它们卖的面包片也是用面包机做的，同样不同种类的面包片也是由不同的面包机来做，这样就有：葡萄干面包机，红豆面包机等。
//做蛋糕的机器
public interface CakeMachine{
void makeCake();
}
//专门做水果蛋糕的机器
class FruitCakeMachine implements CakeMachine{
public void makeCake() {
System.out.println("Making a fruit cake...");
}
}
//专门做巧克力蛋糕的机器
public class ChocolateCakeMachine implements CakeMachine{
public void makeCake() {
System.out.printf("making a Chocolate Cake...");
}
}
//做面包的机器
public interface BreadMachine {
void makeBread();
}
//专门做红豆面包的机器
public class RedBeanBreadMachine implements BreadMachine {
public void makeBread() {
System.out.println("making red bean bread....");
}
}
//专门做葡萄干面包的机器
public class CurrantBreadMachine implements BreadMachine{
public void makeBread() {
System.out.println("making currant bread...");
}
}
//蛋糕店
public class CakeShop {
public static void main(String[] args) {
new FruitCakeMachine().makeCake();
new ChocolateCakeMachine().makeCake();
new RedBeanBreadMachine().makeBread();
new CurrantBreadMachine().makeBread();
}
}
上面的代码抽象出了一个CakeMachine接口和BreadMachine接口，有各种蛋糕机实现了CakeMachine接口，有各种面包机实现了BreadMachine接口，最后蛋糕店直接利用这些蛋糕机来做蛋糕。
这样的一个例子真实地描叙了实际生活中的场景。但生活中的场景往往是复杂多变的，假设这个时候来了一个顾客，他想要一个水果蛋糕，但是他特别喜欢杏仁，希望在水果蛋糕上加一层杏仁，这个时候我们应该怎么做呢？
因为我们的蛋糕机只能做水果蛋糕，没办法做杏仁蛋糕。最简单的办法是直接修改水果蛋糕机的程序，做一台能做杏仁水果的蛋糕机。这种方式对应的代码修改也很简单，直接在原来的代码上进行修改，生成一台专门做杏仁的水果蛋糕机就好了，修改后的FruitCakeMachine类应该是这样子:
//专门做水果蛋糕的机器，并且加上一层杏仁
class FruitCakeMachine implements CakeMachine{
public void makeCake() {
System.out.println("making a Fruit Cake...");
System.out.println("adding apricot...");
}
}
虽然上面这种方式实现了我们的业务需求。但是仔细想一想，在现实生活中如果我们遇到这样的一个需求，我们不可能因为一个顾客的特殊需求就去修改一台蛋糕机的硬件程序，这样成本太高！而且从代码实现角度上来说，这种方式从代码上不是很优雅，修改了原来的代码。根据代码圈中「对修改封闭、对扩展开放」的思想，我们在尝试满足新的业务需求的时候应该尽量少修改原来的代码，而是在原来的代码上进行拓展。
那我们究竟应该怎么做更加合适一些呢？我们肯定是直接用水果蛋糕机做一个蛋糕，然后再人工撒上一层杏仁啦。我们需要做的，其实就是设计一个杏仁代理类（ApricotCakeProxy），这个代理类就完成撒杏仁这个动作，之后让蛋糕店直接调用代理类去实现即可。
//杏仁蛋糕代理
public class ApricotCakeProxy implements CakeMachine{
private CakeMachine cakeMachine;
public ApricotCakeProxy(CakeMachine cakeMachine) {
this.cakeMachine = cakeMachine;
}
public void makeCake() {
cakeMachine.makeCake();
System.out.println("adding apricot...");
}
}
//蛋糕店
public class CakeShop {
public static void main(String[] args) {
//可以给各种各样的蛋糕加上杏仁
FruitCakeMachine fruitCakeMachine = new FruitCakeMachine();
ApricotCakeProxy apricotProxy = new ApricotCakeProxy(fruitCakeMachine);
apricotProxy.makeCake();
apricotProxy = new ApricotCakeProxy(new ChocolateCakeMachine());
apricotProxy.makeCake();
}
}
这其实就对应了设计模式中的代理模式，虽然调用的是 ApricotCakeProxy 类的方法，但实际上真正做蛋糕的是 FruitCakeMachine 类。ApricotCakeProxy 类只是在 FruitCakeMachine 做出蛋糕后，撒上一层杏仁而已。而且通过代理，我们不仅可以给水果蛋糕撒上一层杏仁，还可以给巧克力蛋糕、五仁蛋糕等撒上一层杏仁。只要它是蛋糕（实现了 CakeMachine 接口），那么我们就可以给这个蛋糕撒上杏仁。
通过代理实现这样的业务场景，这样我们就不需要在原来的类上进行修改，从而使得代码更加优雅，拓展性更强。如果下次客人喜欢葡萄干水果蛋糕了了，那可以再写一个 CurrantCakeProxy 类来撒上一层葡萄干，原来的代码也不会被修改。上面说的这种业务场景就是代理模式的实际应用，准确地说这种是静态代理。
业务场景的复杂度往往千变万化，如果这个特别喜欢杏仁的客人，他也想在面包上撒一层杏仁，那我们怎么办?我们能够使用之前写的ApricotCakeProxy代理类么？不行，因为ApricotCakeProxy里面规定了只能为蛋糕(实现了CakeMachine接口)的实体做代理。这种情况下，我们只能再写一个 可以为所有面包加杏仁的代理类:ApricotBreadProxy.
//杏仁面包代理
public class ApricotBreadProxy implements BreadMachine{
private BreadMachine breadMachine;
public ApricotBreadProxy(BreadMachine breadMachine) {
this.breadMachine = breadMachine;
}
public void makeBread() {
breadMachine.makeBread();
System.out.println("adding apricot...");
}
}
//蛋糕店
public class CakeShop {
public static void main(String[] args) {
//可以给各种各样的面包加上杏仁
RedBeanBreadMachine redBeanBreadMachine = new RedBeanBreadMachine();
ApricotBreadProxy apricotBreadProxy = new ApricotBreadProxy(redBeanBreadMachine);
apricotBreadProxy.makeBread();
CurrantBreadMachine currantBreadMachine = new CurrantBreadMachine();
apricotBreadProxy = new ApricotBreadProxy(currantBreadMachine);
apricotBreadProxy.makeBread();
}
}
最终输出结果:
making red bean bread....
adding apricot...
making currant bread...
adding apricot...
我们可以看到我们也成功地做出了客人想要的杏仁红豆面包，杏仁葡萄干面包。
对于客人来说，他肯定希望我们所有的产品都有一层杏仁，这样客人最喜欢了。为了满足客人的需求，那如果我们的产品有100种，我们是不是得写100个代理类？有没有一种方式可以让我们只写一次实现(撒杏仁的实现)，但是任何类型的产品(蛋糕，面包，饼干，酸奶等)都可以使用呢?其实在Java中早已经有了针对这种情况而设计的一个接口，专门用来解决类似的问题，它就是动态代理-- InvocationHandler。
接下来我们针对这个业务场景来做一个代码的抽象实现。首先我们分析一下可以知道这种场景的共同点是希望所有产品都做撒杏仁的操作，所以我们做一个杏仁动态代理。
//杏仁动态代理
public class ApricotHandler implements InvocationHandler{
private Object object;
public ApricotHandler(Object object){
this.object=object;
}
public Object invoke(Object proxy,Method method,Object[] args) throws Throwable{
Object result=method.invoke(object,args);
System.out.println("adding apricot ...");
return result;
}
}
撒杏仁的代理写完之后，我们直接让蛋糕店开工：
public class CakeShop{
public static void main(String[] args){
//动态代理(可以同时给蛋糕，面包等加杏仁)
//给蛋糕加杏仁
FruitCakeMachine fruitCakeMachine=new FruitCakeMachine();
ApricotHandler apricotHandler=new ApricotHanlder(fruitCakeMachine);
CakeMachine cakeMachine=Proxy.newProxyInstance(fruitCakeMachine.getClass().getClassLoader(),fruitCakeMachine.getClass().getInterfaces(),apricotHandler);
cakeMachine.makeCake();
//给面包加上杏仁
RedBeanBreadMachine redBeanBreadMachine = new RedBeanBreadMachine();
apricotHandler = new ApricotHandler(redBeanBreadMachine);
BreadMachine breadMachine = (BreadMachine) Proxy.newProxyInstance(redBeanBreadMachine.getClass().getClassLoader(),
redBeanBreadMachine.getClass().getInterfaces(),
apricotHandler);
breadMachine.makeBread();
}
}
输出结果为:
making a fruit cake...
adding apricot...
making red bean bread....
adding apricot...
静态代理只能针对某一接口（面包 或 蛋糕）进行操作，如果要对所有接口都（所有产品）都能做一样操作，那就必须要动态代理出马了。
5.Java动态代理的原理
从上面的例子我们可以知道，Java动态代理的入口是从Proxy.newInstance()方法中开始的，那么我们就可以从这个方法开始边剖析源码边理解其原理。
/**
* Returns an instance of a proxy class for the specified interfaces
* that dispatches method invocations to the specified invocation
* handler.
*
* <p>{@code Proxy.newProxyInstance} throws
* {@code IllegalArgumentException} for the same reasons that
* {@code Proxy.getProxyClass} does.
*
* @param loader the class loader to define the proxy class
* @param interfaces the list of interfaces for the proxy class
* to implement
* @param h the invocation handler to dispatch method invocations to
* @return a proxy instance with the specified invocation handler of a
* proxy class that is defined by the specified class loader
* and that implements the specified interfaces
* @throws IllegalArgumentException if any of the restrictions on the
* parameters that may be passed to {@code getProxyClass}
* are violated
* @throws SecurityException if a security manager, <em>s</em>, is present
* and any of the following conditions is met:
* <ul>
* <li> the given {@code loader} is {@code null} and
* the caller's class loader is not {@code null} and the
* invocation of {@link SecurityManager#checkPermission
* s.checkPermission} with
* {@code RuntimePermission("getClassLoader")} permission
* denies access;</li>
* <li> for each proxy interface, {@code intf},
* the caller's class loader is not the same as or an
* ancestor of the class loader for {@code intf} and
* invocation of {@link SecurityManager#checkPackageAccess
* s.checkPackageAccess()} denies access to {@code intf};</li>
* <li> any of the given proxy interfaces is non-public and the
* caller class is not in the same {@linkplain Package runtime package}
* as the non-public interface and the invocation of
* {@link SecurityManager#checkPermission s.checkPermission} with
* {@code ReflectPermission("newProxyInPackage.{package name}")}
* permission denies access.</li>
* </ul>
* @throws NullPointerException if the {@code interfaces} array
* argument or any of its elements are {@code null}, or
* if the invocation handler, {@code h}, is
* {@code null}
*/
@CallerSensitive
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
throws IllegalArgumentException
{
Objects.requireNonNull(h);
final Class<?>[] intfs = interfaces.clone();
// Android-removed: SecurityManager calls
/*
final SecurityManager sm = System.getSecurityManager();
if (sm != null) {
checkProxyAccess(Reflection.getCallerClass(), loader, intfs);
}
*/
/*
* Look up or generate the designated proxy class.
*/
Class<?> cl = getProxyClass0(loader, intfs);
/*
* Invoke its constructor with the designated invocation handler.
*/
try {
// Android-removed: SecurityManager / permission checks.
/*
if (sm != null) {
checkNewProxyPermission(Reflection.getCallerClass(), cl);
}
*/
final Constructor<?> cons = cl.getConstructor(constructorParams);
final InvocationHandler ih = h;
if (!Modifier.isPublic(cl.getModifiers())) {
// BEGIN Android-removed: Excluded AccessController.doPrivileged call.
/*
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
cons.setAccessible(true);
return null;
}
});
*/
cons.setAccessible(true);
// END Android-removed: Excluded AccessController.doPrivileged call.
}
return cons.newInstance(new Object[]{h});
} catch (IllegalAccessException|InstantiationException e) {
throw new InternalError(e.toString(), e);
} catch (InvocationTargetException e) {
Throwable t = e.getCause();
if (t instanceof RuntimeException) {
throw (RuntimeException) t;
} else {
throw new InternalError(t.toString(), t);
}
} catch (NoSuchMethodException e) {
throw new InternalError(e.toString(), e);
}
}
从Proxy.newInstance()的源码我们可以看到首先调用了getProxyClass0方法，该方法返回了一个class实列对象。接着获取其构造方法对象，最后生成该Class对象的实列。
/**
* Generate a proxy class. Must call the checkProxyAccess method
* to perform permission checks before calling this.
*/
private static Class<?> getProxyClass0(ClassLoader loader,
Class<?>... interfaces) {
if (interfaces.length > 65535) {
throw new IllegalArgumentException("interface limit exceeded");
}
// If the proxy class defined by the given loader implementing
// the given interfaces exists, this will simply return the cached copy;
// otherwise, it will create the proxy class via the ProxyClassFactory
return proxyClassCache.get(loader, interfaces);
}
getProxyClass0()方法首先是做了一些参数校验，之后从proxyClassCache参数中取出Class对象。其实proxyClassCache是一个Map对象，缓存了所有动态创建的Class对象。从源码注释中可以知道，如果从Map中取出的对象为空，那么其会调用ProxyClassFactory生成对应的Class对象。
/**
* A factory function that generates, defines and returns the proxy class given
* the ClassLoader and array of interfaces.
*/
private static final class ProxyClassFactory
implements BiFunction<ClassLoader, Class<?>[], Class<?>>
{
// prefix for all proxy class names
private static final String proxyClassNamePrefix = "$Proxy";
// next number to use for generation of unique proxy class names
private static final AtomicLong nextUniqueNumber = new AtomicLong();
@Override
public Class<?> apply(ClassLoader loader, Class<?>[] interfaces) {
Map<Class<?>, Boolean> interfaceSet = new IdentityHashMap<>(interfaces.length);
for (Class<?> intf : interfaces) {
/*
* Verify that the class loader resolves the name of this
* interface to the same Class object.
*/
Class<?> interfaceClass = null;
try {
interfaceClass = Class.forName(intf.getName(), false, loader);
} catch (ClassNotFoundException e) {
}
if (interfaceClass != intf) {
throw new IllegalArgumentException(
intf + " is not visible from class loader");
}
/*
* Verify that the Class object actually represents an
* interface.
*/
if (!interfaceClass.isInterface()) {
throw new IllegalArgumentException(
interfaceClass.getName() + " is not an interface");
}
/*
* Verify that this interface is not a duplicate.
*/
if (interfaceSet.put(interfaceClass, Boolean.TRUE) != null) {
throw new IllegalArgumentException(
"repeated interface: " + interfaceClass.getName());
}
}
String proxyPkg = null; // package to define proxy class in
int accessFlags = Modifier.PUBLIC | Modifier.FINAL;
/*
* Record the package of a non-public proxy interface so that the
* proxy class will be defined in the same package. Verify that
* all non-public proxy interfaces are in the same package.
*/
for (Class<?> intf : interfaces) {
int flags = intf.getModifiers();
if (!Modifier.isPublic(flags)) {
accessFlags = Modifier.FINAL;
String name = intf.getName();
int n = name.lastIndexOf('.');
String pkg = ((n == -1) ? "" : name.substring(0, n + 1));
if (proxyPkg == null) {
proxyPkg = pkg;
} else if (!pkg.equals(proxyPkg)) {
throw new IllegalArgumentException(
"non-public interfaces from different packages");
}
}
}
if (proxyPkg == null) {
// if no non-public proxy interfaces, use the default package.
proxyPkg = "";
}
{
// Android-changed: Generate the proxy directly instead of calling
// through to ProxyGenerator.
List<Method> methods = getMethods(interfaces);
Collections.sort(methods, ORDER_BY_SIGNATURE_AND_SUBTYPE);
validateReturnTypes(methods);
List<Class<?>[]> exceptions = deduplicateAndGetExceptions(methods);
Method[] methodsArray = methods.toArray(new Method[methods.size()]);
Class<?>[][] exceptionsArray = exceptions.toArray(new Class<?>[exceptions.size()][]);
/*
* Choose a name for the proxy class to generate.
*/
long num = nextUniqueNumber.getAndIncrement();
String proxyName = proxyPkg + proxyClassNamePrefix + num;
return generateProxy(proxyName, interfaces, loader, methodsArray,
exceptionsArray);
}
}
}
@FastNative
private static native Class<?> generateProxy(String name, Class<?>[] interfaces,
ClassLoader loader, Method[] methods,
Class<?>[][] exceptions);
// END Android-changed: How proxies are generated.
在 ProxyClassFactory 类的源码中，最终是调用了 genrateProxy() Native方法生成了对应的 class 字节码文件。
到这里，我们已经把动态代理的Java源代码都解析完了，现在思路就很清晰了。Proxy.newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h) 方法简单来说执行了以下操作：
1.生成一个实现了参数interfaces里所有接口且继承了Proxy的代理类的字节码，然后用参数里的classLoader加载这个代理类。
2.使用代理类的构造函数Proxy(InvocaitonHandler h)来创建一个代理类的实现，将我们自定义的InvocationHandler的子类传入。
3.返回这个代理类实列，因为我们构造的代理类实现了interfaces(也就是我们程序中传入的fruitCakeMachine.getClass().getInterfaces
（）)里的所有接口，因此返回的代理类可以强制转成MachineCake类型来调用接口中定义的方法。
6.代理模式和装饰模式区别
对装饰器模式来说，装饰者（Decorator）和被装饰者（Decoratee）都实现一个接口。对代理模式来说，代理类（Proxy Class）和真实处理的类（Real Class）都实现同一个接口。此外，不论我们使用哪一个模式，都可以很容易地在真实对象的方法前面或者后面加上自定义的方法。那他们之间有什么区别呢？
-
首先代理模式和装饰者模式的意图是不一样的。装饰器模式关注于在一个对象上动态的添加方法，然而代理模式关注于控制对对象的访问。换句话说，用代理模式，代理类（proxy class）可以对它的客户隐藏一个对象的具体信息。
-
装饰器模式是使用的调用者从外部传入的被装饰对象，调用者只想要你把他给你的对象装饰（加强）一下。而代理模式使用的是代理对象在自己的构造方法里面new的一个被代理的对象，不是调用者传入的。调用者不知道你找了其他人，他也不关心这些事，只要你把事情做对了即可。
-
装饰器模式关注于在一个对象上动态地添加方法，而代理模式关注于控制对对象的访问。换句话说，用代理模式，代理类可以对它的客户隐藏一个对象的具体信息。因此当使用代理模式的时候，我们常常在一个代理类中创建一个对象的实例；当使用装饰器模式的时候，我们通常的做法是将原始对象作为一个参数传给装饰器的构造器。
-
装饰器模式和代理模式的使用场景不一样，比如IO流使用的是装饰者模式，可以层层增加功能。而代理模式则一般是用于增加特殊的功能，有些动态代理不支持多层嵌套。
使用代理模式，代理和真实对象之间的的关系通常在编译时就已经确定了，而装饰者能够在运行时递归地被构造。
网友评论