模式是程序员之间的交流语言,代理(Proxy)和委派(Delegate)是模式中常见的词汇,不过很多人把他们混淆了,甚至等同起来,这会造成很多沟通交流上的误解,下面说说他们的区别,先看一个UML图:
图形已经表述的很直白了,如果还不清晰,可以看看下面的代码:
01 interface Subject
02 {
03 public function DoAction();
04 }
05
06 class RealSubject implements Subject
07 {
08 public function DoAction()
09 {
10 echo '_RealSubject::DoAction_';
11 }
12 }
13
14 class Proxy implements Subject
15 {
16 public function __construct()
17 {
18 $this->subject = new RealSubject();
19 }
20
21 public function DoAction()
22 {
23 echo 'Proxy::DoAction';
24 $this->subject->DoAction();
25 echo 'Proxy::DoAction';
26 }
27 }
28
29 $proxy = new Proxy();
30 $proxy->DoAction();
运行结果输出:Proxy::DoAction_RealSubject::DoAction_Proxy::DoAction
如果你还没有看出端倪,我就再废话几句:首先从词性来看,代理(Proxy)是名词,委派(Delegate)是动词,其次代理说明了若干个对象实现了一个共同的接口,而委派只是说明一个对象引用了另一个对象,并不牵扯接口。
既然说到这了,就再唠叨几句:什么时候适合使用Proxy模式呢?对PHP而言,一般是当需要给对象附加额外的逻辑时,而这些逻辑和原有逻辑又分属不同的 层次,此时就可以考虑使用Proxy模式。听起来有点拗口,说一个实际的例子,比如说我们实现了Article对象,里面封装了CRUD方法,现在我们要 加入权限判断,控制CRUD的访问限制,这些新加入的逻辑属于应用逻辑,而原有的逻辑属于持久化逻辑,从分层角度看它们不应该放在一个对象里,此时就可以 创建一个ArticleProxy代理对象,用来实现权限判断,至于CRUD操作,则通过委派给Article对象来完成。
当年的JIVE论坛大量使用了此类方法,不过现在JIVE论坛早已销声匿迹,但思想还是可以借鉴的。通过使用代理模式,可以把不同侧重点的逻辑分别封装到 不同的对象里去(和装饰模式有点像,至于如何区分就是另一个话题了),从而避免God Class的产生,不过这样设计的结果会产生大量的类,孰重孰轻还得视客观情况而定。
图形已经表述的很直白了,如果还不清晰,可以看看下面的代码:
01 interface Subject
02 {
03 public function DoAction();
04 }
05
06 class RealSubject implements Subject
07 {
08 public function DoAction()
09 {
10 echo '_RealSubject::DoAction_';
11 }
12 }
13
14 class Proxy implements Subject
15 {
16 public function __construct()
17 {
18 $this->subject = new RealSubject();
19 }
20
21 public function DoAction()
22 {
23 echo 'Proxy::DoAction';
24 $this->subject->DoAction();
25 echo 'Proxy::DoAction';
26 }
27 }
28
29 $proxy = new Proxy();
30 $proxy->DoAction();
运行结果输出:Proxy::DoAction_RealSubject::DoAction_Proxy::DoAction
如果你还没有看出端倪,我就再废话几句:首先从词性来看,代理(Proxy)是名词,委派(Delegate)是动词,其次代理说明了若干个对象实现了一个共同的接口,而委派只是说明一个对象引用了另一个对象,并不牵扯接口。
既然说到这了,就再唠叨几句:什么时候适合使用Proxy模式呢?对PHP而言,一般是当需要给对象附加额外的逻辑时,而这些逻辑和原有逻辑又分属不同的 层次,此时就可以考虑使用Proxy模式。听起来有点拗口,说一个实际的例子,比如说我们实现了Article对象,里面封装了CRUD方法,现在我们要 加入权限判断,控制CRUD的访问限制,这些新加入的逻辑属于应用逻辑,而原有的逻辑属于持久化逻辑,从分层角度看它们不应该放在一个对象里,此时就可以 创建一个ArticleProxy代理对象,用来实现权限判断,至于CRUD操作,则通过委派给Article对象来完成。
当年的JIVE论坛大量使用了此类方法,不过现在JIVE论坛早已销声匿迹,但思想还是可以借鉴的。通过使用代理模式,可以把不同侧重点的逻辑分别封装到 不同的对象里去(和装饰模式有点像,至于如何区分就是另一个话题了),从而避免God Class的产生,不过这样设计的结果会产生大量的类,孰重孰轻还得视客观情况而定。