设计模式总结篇系列：代理模式（Proxy）

时代在发展，我们发现，现在不少明星都开始进行微访谈之类的，有越来越多的参与捐赠等。新的一天开始了，首先看下新的一天的日程安排：

1 interface Schedule{ 2     
3     public void weiTalk(); 4     
5     public void donation(); 6     
7 }

Schedule接口定义了今天的形成安排，主要包括微访谈和捐款。那么看一下实现此接口的明星类定义：

 1 class Star implements Schedule {  2 
 3  @Override  4     public void weiTalk() {  5         System.out.println("开始微访谈");  6  }  7 
 8  @Override  9     public void donation() { 10         System.out.println("开始捐款"); 11  } 12 
13 }

我们知道，现在明星一般的身边都有一个人，称之为经纪人，负责明星的工作安排及各种事物处理等。一般明星到哪，相应的经纪人也就到哪。我们来定义一个经纪人：

 1 class Broker implements Schedule {  2     private Schedule star;  3 
 4     public Broker() {  5         star = new Star();  6  }  7 
 8     public Broker(Schedule star) {  9         this.star = star; 10  } 11 
12  @Override 13     public void weiTalk() { 14         System.out.println("陪着明星参加为访谈"); 15  star.weiTalk(); 16  } 17 
18  @Override 19     public void donation() { 20         System.out.println("陪着明星捐款"); 21  star.donation(); 22  } 23 
24 }

我们知道，Broker虽然也需要参加微访谈和捐款，但都是陪着明星的，例如现在正在微博访谈，网友问了一个问题：你希望你的小neinei尽快长大呢？WZ回答，当然不是很希望啦。于是经纪人在WZ的微博中回复网友：当然不是很希望啦。

我们发现，Broker对象实现的方法中实际上调用的还是相应所持有的Star对象引用中相应的方法。好，假如正在微访谈过程中，小neinei睡醒了，嚷嚷着爸爸去哪了，于是WZ只得马上跑过去哄自己心爱的小neinei。可这时候网友们还在提问啊，怎么办呢，经纪人总不能擅自做主张的直接回答网友问题吧，于是向网友解释：小neinei醒了，WZ去哄她睡觉了，微访谈顺延到21：30。

又或者在去参与捐赠会的路上，突然剧组那边有更重要的发布会要Star过去，这时候捐赠会主办方打电话过来询问代理们是不是快要到了，代理当即回答，Star临时有更重要的事情要处理，就不去参加了，当然，钱肯定还是会给的。

在外界看来，一般情况下无论是接商务广告还是友情出演，首先都是联系Broker的，等Broker和Star商量后作出决定并有Broker对外回复。

上面整个过程中，外界与Star是不能直接接触的，或者说要先有代理的安排，Broker和Star之间的关系是代理和被代理的关系。这种设计模式我们称之为代理模式。可能有人会说，怎么感觉跟装饰器模式那么像呢？确实，在代码层次而言，两者确实比较接近。而主要的不同在于两个模式背后所蕴含的思想：

装饰器模式主要用来替代继承，为的是给一个现有的类增加新的功能，客户端关心的是装饰后的类所具有的功能；而代理模式为的是对被代理对象提供访问控制，客户端关心的实际上还是被代理对象所具有的功能。