时代在发展，我们发现，现在不少明星都开始进行微访谈之类的，有越来越多的参与捐赠等。新的一天开始了，首先看下新的一天的日程安排：
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之间的关系是代理和被代理的关系。这种设计模式我们称之为代理模式。可能有人会说，怎么感觉跟装饰器模式那么像呢？确实，在代码层次而言，两者确实比较接近。而主要的不同在于两个模式背后所蕴含的思想：
装饰器模式主要用来替代继承，为的是给一个现有的类增加新的功能，客户端关心的是装饰后的类所具有的功能；而代理模式为的是对被代理对象提供访问控制，客户端关心的实际上还是被代理对象所具有的功能。
设计模式总结篇系列：代理模式（Proxy）,布布扣,bubuko.com