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