设计模式最简理解之代理模式

初次接触设计模式的时候，我们都以为它是一种魔法，像一本武林秘籍，研究透了就能成为一方高手。现在就来看看它有什么”魔力“。

代理模式

首先，在我们开发的时候归根结底，只有一种范式，那就是先创建对象，再调用对象的方法。即：

A a = new A();

a.method();

现在引入代理模式，先看看要引入代理模式需要做哪些额外的工作。

既然是代理模式，肯定少不了代理类A'，而对于调用方来说，代理类A'和被代理类A是没有区别的，所以A'和A应该属于同一个抽象，那么需要引入接口Subject，A和A'都属于这个接口的实现。

可以看到，本身很简单的调用，要引入代理模式需要增加两个类或接口。那么增加的代码量一定能够带来什么吧？不然得不偿失。

先看看，此时要调用A的方法应该怎么做

A a = new A();

A' a' = new A'(a);

a'.method();

什么？！居然相比原来没有区别，反而需要增增加代码？确实得不偿失。

很显然，由以上可知，设计模式会带来额外的工作量、引入更多的复杂度。这就是设计模式的缺点，并且是必然的，只要引入设计模式，就必然要面临这些缺点。

但是设计模式被这么推崇，大概率不是浪得虚名，那么现在要怎么分析它带来的好处呢？

再仔细看一下，发现A和A'有一个共同的接口Subject，所以调用方式可以再改一下

Subject a = new A();

Subject a' = new A'(a);

a'.method();

引入代理模式就做了两件事，一是新建一个类A'，二是新增接口Subject。接下来使用一问一答得模式来分析。

问：首先，为什么要新建一个类A'？

答：因为需要添加新的功能。

问：那为什么不直接在A中改？

答：因为因为A不能改。

问：为什么A不能改？

答：因为A已经在其他地方使用，改了后会对其他地方造成影响。

问：所以，使用代理模式只是因为迫不得已？

答：完全正确，所有设计模式的使用都有一个迫不得已使用的原因，如果没有，就不应该使用，或者说没必要花费代价来使用。

问：继续说代理模式，问什么要引入Subject抽象？然后让A和A'实现它。

答：因为调用方既可能使用A也可能使用A'，但不论是A还是A'，调用方只需要使用Subject，代码不会根据A和A'而改变。

问：为什么要让调用方的代码不必改变？

答：因为这样就能带来灵活性。可以想象，当要给A添加新功能，而A又不能改变时，就可以使用代理模式，此时A的代码和调用方的代码都不需要改变，这就叫灵活性。

问：不对，A改变了，A本身没有父接口Subject，现在有了。
答：所以要根据情况而定，假如A本身就有父接口，就使用基于接口的代理模式。如果没有就要使用基于继承的代理模式，即A'继承A，此时就不需要添加Subject接口了。

问：原来如此，现在一切都明晰了，使用代理模式不需要改变任何已有代码，就能增加新功能了！

答：不完全正确，在编程中，该有的代码一行都不会少，复杂度也只会转移，不会凭空消失。此时只是将复杂度转移到了构造A的地方，现在是构造A'。

综上，代理模式的功能是可以根据构造的是原类A还是增强类A'来动态决定使用原功能还是增强功能。