设计模式总结篇系列:代理模式(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之间的关系是代理和被代理的关系。这种设计模式我们称之为代理模式。可能有人会说,怎么感觉跟装饰器模式那么像呢?确实,在代码层次而言,两者确实比较接近。而主要的不同在于两个模式背后所蕴含的思想:

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

 

你可能感兴趣的:(proxy)