32.3 观察者模式VS责任链模式
为什么要把观察者模式和责任链模式放在一起对比呢?看起来这两个模式没有太多的相似性,真没有吗?回答是有。我们在观察者模式中也提到了触发链(也叫做观察者链)的问题,一个具体的角色既可以是观察者,也可以是被观察者,这样就形成了一个观察者链。这与责任链模式非常类似,它们都实现了事务的链条化处理,比如说在上课的时候你睡着了,打鼾声音太大,盖过了老师讲课声音,老师火了,捅到了校长这里,校长也处理不了,然后告状给你父母,于是你的魔鬼日子来临了,这是责任链模式,老师、校长、父母都是链中的一个具体角色,事件(你睡觉)在链中传递,最终由一个具体的节点来处理,并将结果反馈给调用者(你挨揍了)。那什么是触发链?你还是在课堂上睡觉,还是打鼾声音太大,老师火了,但是老师掏出个扩音器来讲课,于是你睡不着了,同时其他同学的耳朵遭殃了,这就是触发链,其中老师既是观察者(相对你)也是被观察者(相对其他同学),事件从“你睡觉”到老师这里转化为“扩音器放大声音”,这也是一个链条结构,但是链结构中传递的事件改变了。
我们还是以一个具体的例子来说明两者的区别,DNS协议相信大家都听说过,只要在“网络设置”中设置一个DNS服务器地址就可以把我们需要的域名翻译成IP地址。DNS协议还是比较简单的,传递过去一个域名以及记录标志(比如是要A记录还是要MX记录),DNS就开始查找自己的记录树,找到后把IP地址反馈给请求者。我们可以在Windows操作系统中了解一下DNS解析过程,在DOS窗口下输入nslookup命令后,结果如图32-6所示。
![](https://box.kancloud.cn/2016-08-14_57b0036e2208b.jpg)
图32-6 DNS服务器解析域名
我们的意图就是要DNS服务器192.168.10.1解析出www.xxx.com.cn的IP地址,DNS服务器是如何工作的呢?图32-6中的192.168.10.1这个DNS Server存储着全球的域名和IP之间的对应关系吗?不可能,目前全球的域名数量是1.7亿个,如此庞大的数字,每个DNS服务器都存储一份,还怎么快速响应?DNS解析的响应时间一般都是毫秒级别的,如此高的性能要求还怎么让DNS服务器遍地开花呢?而且域名变更非常频繁,数据读写的量也非常大,不可能每个DNS服务器都保留这1.7亿数据,那么是怎么设计的呢?DNS协议还是很聪明的,它规定了每个区域的DNS服务器(Local DNS)只保留自己区域的域名解析,对于不能解析的域名,则提交上级域名解析器解析,最终由一台位于美国洛杉矶的顶级域名服务器进行解析,返回结果。很明显这是一个事务的链结构处理,我们使用两种模式来实现该解析过程。
32.3.1 责任链模式实现DNS解析过程
本小节我们用责任链模式来实现DNS解析过程。首先我们定义一下业务场景,这里有三个DNS服务器:上海DNS服务器(区域服务器)、中国顶级DNS服务器(父服务器)、全球顶级DNS服务器,其示意图如图32-7所示。
![](https://box.kancloud.cn/2016-08-14_57b0036e397fb.jpg)
图32-7 DNS解析示意图
假设有请求者发出请求,由上海DNS进行解析,如果能够解析,则返回结果,若不能解析,则提交给父服务器(中国顶级DNS)进行解析,若还不能解析,则提交到全球顶级DNS进行解析,若还不能解析呢?那就返回该域名无法解析。确实,这与责任链模式非常相似,我们把这一过程抽象一下,类图如图32-8所示。
![](https://box.kancloud.cn/2016-08-14_57b0036e4d62c.jpg)
图32-8 责任链模式实现DNS解析的类图
我们来解释一下类图,Recorder是一个BO对象,它记录DNS服务器解析后的结果,包括域名、IP地址、属主(即由谁解析的),除此之外还有getter/setter方法。DnsServer抽象类中的resolve方法是一个基本方法,每个DNS服务器都必须拥有该方法,它对DNS进行解析,如何解析呢?具体是由echo方法来实现的,每个DNS服务器独自实现。类图还是比较简单的,我们首先看一下解析记录Recorder类,如代码清单32-31所示。
代码清单32-31 解析记录
public class Recorder {
//域名
private String domain;
//IP地址
private String ip;
//属主
private String owner;
public String getDomain() {
return domain;
}
public void setDomain(String domain) {
this.domain = domain;
}
public String getIp() {
return ip;
}
public void setIp(String ip) {
this.ip = ip;
}
public String getOwner() {
return owner;
}
public void setOwner(String owner) {
this.owner = owner;
}
//输出记录信息
@Override
public String toString(){
String str= "域名:" + this.domain;
str = str + "\nIP地址:" + this.ip;
str = str + "\n解析者:" + this.owner;
return str;
}
}
为什么要覆写toString方法呢?是为了打印展示的需要,可以直接把Recorder的信息打印出来。我们再来看抽象域名服务器,如代码清单32-32所示。
代码清单32-32 抽象域名服务器
public abstract class DnsServer {
//上级DNS是谁
private DnsServer upperServer;
//解析域名
public final Recorder resolve(String domain){
Recorder recorder=null;
if(isLocal(domain)){//是本服务器能解析的域名
recorder = echo(domain);
}else{//本服务器不能解析
//提交上级DNS进行解析
recorder = upperServer.resolve(domain);
}
return recorder;
}
//指向上级DNS
public void setUpperServer(DnsServer _upperServer){
this.upperServer = _upperServer;
}
//每个DNS都有一个数据处理区(ZONE),检查域名是否在本区中
protected abstract boolean isLocal(String domain);
//每个DNS服务器都必须实现解析任务
protected Recorder echo(String domain){
Recorder recorder = new Recorder();
//获得IP地址
recorder.setIp(genIpAddress());
recorder.setDomain(domain);
return recorder;
}
//随机产生一个IP地址,工具类
private String genIpAddress(){
Random rand = new Random();
String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ rand.nextInt(255);
return address;
}
}
在该类中有一个方法——genIpAddress方法——没有在类图中展现出来,它用于实现随机生成IP地址,这是我们为模拟DNS解析场景而建立的一个虚拟方法,在实际的应用中是不可能出现的。抽象DNS服务器编写完成,我们再来看具体的DNS服务器,先看上海的DNS服务器,如代码清单32-33所示。
代码清单32-33 上海DNS服务器
public class SHDnsServer extends DnsServer {
@Override
protected Recorder echo(String domain) {
Recorder recorder= super.echo(domain);
recorder.setOwner("上海DNS服务器");
return recorder;
}
//定义上海的DNS服务器能处理的级别
@Override
protected boolean isLocal(String domain) {
return domain.endsWith(".sh.cn");
}
}
为什么要覆写echo方法?各具体的DNS服务器实现自己的解析过程,属于个性化处理,它代表的是每个DNS服务器的不同处理逻辑。还要注意一下,我们在这里做了一个简化处理,所有以".sh.cn"结尾的域名都由上海DNS服务器解析。其他的中国顶级DNS和全球顶级DNS实现过程类似,如代码清单32-34、32-35所示。
代码清单32-34 中国顶级DNS服务器
public class ChinaTopDnsServer extends DnsServer {
@Override
protected Recorder echo(String domain) {
Recorder recorder = super.echo(domain);
recorder.setOwner("中国顶级DNS服务器");
return recorder;
}
@Override
protected boolean isLocal(String domain) {
return domain.endsWith(".cn");
}
}
代码清单32-35 全球顶级DNS服务器
public class TopDnsServer extends DnsServer {
@Override
protected Recorder echo(String domain) {
Recorder recorder = super.echo(domain);
recorder.setOwner("全球顶级DNS服务器");
return recorder;
}
@Override
protected boolean isLocal(String domain) {
//所有的域名最终的解析地点
return true;
}
}
所有的DNS服务器都准备好了,下面我们写一个客户端来模拟一下IP地址是怎么解析的,如代码清单32-36所示。
代码清单32-36 场景类
public class Client {
public static void main(String[] args) throws Exception {
//上海域名服务器
DnsServer sh = new SHDnsServer();
//中国顶级域名服务器
DnsServer china = new ChinaTopDnsServer();
//全球顶级域名服务器
DnsServer top = new TopDnsServer();
//定义查询路径
china.setUpperServer(top);
sh.setUpperServer(china);
//解析域名
System.out.println("=====域名解析模拟器=====");
while(true){
System.out.print("\n请输入域名(输入N退出):");
String domain = (new BufferedReader(new InputStreamReader (System.in))).readLine();
if(domain.equalsIgnoreCase("n")){
return;
}
Recorder recorder = sh.resolve(domain);
System.out.println("----DNS服务器解析结果----");
System.out.println(recorder);
}
}
}
我们来模拟一下,运行结果如下所示:
=====域名解析模拟器=====
请输入域名(输入N退出):www.xxx.sh.cn
----DNS服务器解析结果----
域名:www. xxx.sh.cn
IP地址:69.224.162.154
解析者:上海DNS服务器
请输入域名(输入N退出):www. xxx.com.cn
----DNS服务器解析结果----
域名:www. xxx.com.cn
IP地址:51.28.66.140
解析者:中国顶级DNS服务器
请输入域名(输入N退出):www. xxx.com
----DNS服务器解析结果----
域名:www. xxx.com
IP地址:73.247.80.117
解析者:全球顶级DNS服务器
请输入域名(输入N退出):n
请注意看运行结果,以".sh.cn"结尾的域名确实由上海DNS服务器解析了,以".cn"结尾的域名由中国顶级DNS服务器解析了,其他域名都由全球顶级DNS服务器解析。这个模拟过程看起来很完整,它完全就是责任链模式的一个具体应用,把一个请求放置到链中的首节点,然后由链中的某个节点进行解析并将结果反馈给调用者。但是,我可以负责任地告诉你:这个解析过程是有缺陷的,什么缺陷?后面会说明。
32.3.2 触发链模式实现DNS解析过程
上面说到使用责任链模式模拟DNS解析过程是有缺陷的,究竟有什么缺陷?大家是不是觉得这个解析过程很完美了,没什么问题了?那说明你对DNS协议了解得还不太深入。我们来做一个实验,在dos窗口下输入nslookup命令,然后输入多个域名,注意观察返回值有哪些数据是相同的。可以看出,解析者都相同,都是由同一个DNS服务器解析的,准确地说都是由本机配置的DNS服务器做的解析。这与我们上面的模拟过程是不相同的,看看我们模拟的过程,对请求者来说,".sh.cn"是由区域DNS解析的,".com"却是由全球顶级DNS解析的,与真实的过程不相同,这是怎么回事呢?
肯定地说,采用责任链模式模拟DNS解析过程是不完美的,或者说是有缺陷的,怎么来修复这个缺陷呢?我们先来看看真实的DNS解析过程,如图32-9所示。
![](https://box.kancloud.cn/2016-08-14_57b0036e8989a.jpg)
图32-9 真实的DNS解析示意图
解析一个域名的完整路径如图32-9中的标号①~⑥所示,首先由请求者发送一个请求,然后由上海DNS服务器尝试解析,若不能解析再通过路径②转发给中国顶级DNS进行解析,解析后的结果通过路径⑤返回给上海DNS服务器,然后由上海DNS服务器通过路径⑥返回给请求者。同样,若中国顶级DNS不能解析,则通过路径③转由全球顶级DNS进行解析,通过路径④把结果返回给中国顶级DNS,然后再通过路径⑤返回给上海DNS。注意看标号⑥,不管一个域名最终由谁解析,最终反馈到请求者的还是第一个节点,也就是说首节点负责对请求者应答,其他节点都不与请求者交互,而只与自己的左右节点交互。实际上我们的DNS服务器确实是如此处理的,例如本机请求查询一个www.abcdefg.com的域名,上海DNS服务器解析不到这个域名,于是提交到中国顶级DNS服务器,如果中国顶级DNS服务器有该域名的记录,则找到该记录,反馈到上海DNS服务器,上海DNS服务器做两件事务处理:一是响应请求者,二是存储该记录,以备其他请求者再次查询,这类似于数据缓存。
整个场景我们已经清晰,想想看,我们把请求者看成是被观察者,它的行为或属性变更通知了观察者——上海DNS,上海DNS又作为被观察者出现了自己不能处理的行为(行为改变),通知了中国顶级DNS,依次类推,这是不是一个非常标准的触发链?而且还必须是同步的触发,异步触发已经在该场景中失去了意义(读者可以想想为什么)。
分析了这么多,我们用触发链来模拟DNS的解析过程,如图32-10所示。
![](https://box.kancloud.cn/2016-08-14_57b0036e9c8e5.jpg)
图32-10 触发链模式实现DNS解析的类图
与责任链模式很相似,仅仅多了一个Observable父类和Observer接口,但是在实现上这两种模式有非常大的差异。我们先来解释一下抽象DnsServer的作用。
● 标示声明
表示所有的DNS服务器都具备双重身份:既是观察者也是被观察者,这很重要,它声明所有的服务器都具有相同的身份标志,具有该标志后就可以在链中随意移动,而无需固定在链中的某个位置(这也是链的一个重要特性)。
● 业务抽象
方法setUpperServer的作用是设置父DNS,也就是设置自己的观察者,update方法不仅仅是一个事件的处理者,也同时是事件的触发者。
我们来看代码,首先是最简单的,Recorder类与责任链模式中的记录相同,这里不再赘述。那我们就先看看该模式的核心抽象DnsServer,如代码清单32-37所示。
代码清单32-37 抽象DNS服务器
public abstract class DnsServer extends Observable implements Observer {
//处理请求,也就是接收到事件后的处理
public void update(Observable arg0, Object arg1) {
Recorder recorder = (Recorder)arg1;
//如果本机能解析
if(isLocal(recorder)){
recorder.setIp(genIpAddress());
}else{//本机不能解析,则提交到上级DNS
responsFromUpperServer(recorder);
}
//签名
sign(recorder);
}
//作为被观察者,允许增加观察者,这里上级DNS一般只有一个
public void setUpperServer(DnsServer dnsServer){
//先清空,然后再增加
super.deleteObservers();
super.addObserver(dnsServer);
}
//向父DNS请求解析,也就是通知观察者
private void responsFromUpperServer(Recorder recorder){
super.setChanged();
super.notifyObservers(recorder);
}
//每个DNS服务器签上自己的名字
protected abstract void sign(Recorder recorder);
//每个DNS服务器都必须定义自己的处理级别
protected abstract boolean isLocal(Recorder recorder);
//随机产生一个IP地址,工具类
private String genIpAddress(){
Random rand = new Random();
String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ rand.nextInt(255) + "."+ rand.nextInt(255);
return address;
}
}
注意看一下responseFromUpperServer方法,它只允许设置一个观察者,因为一般的DNS服务器都只有一个上级DNS服务器。sign方法是签名,这个记录是由谁解析出来的,就由各个实现类独自来实现。三个DnsServer的实现类都比较简单,如代码清单32-38、32-39、32-40所示。
代码清单32-38 上海DNS服务器
public class SHDnsServer extends DnsServer {
@Override
protected void sign(Recorder recorder) {
recorder.setOwner("上海DNS服务器");
}
//定义上海的DNS服务器能处理的级别
@Override
protected boolean isLocal(Recorder recorder) {
return recorder.getDomain().endsWith(".sh.cn");
}
}
代码清单32-39 中国顶级DNS服务器
public class ChinaTopDnsServer extends DnsServer {
@Override
protected void sign(Recorder recorder) {
recorder.setOwner("中国顶级DNS服务器");
}
@Override
protected boolean isLocal(Recorder recorder) {
return recorder.getDomain().endsWith(".cn");
}
}
代码清单32-40 全球顶级DNS服务器
public class TopDnsServer extends DnsServer {
@Override
protected void sign(Recorder recorder) {
recorder.setOwner("全球顶级DNS服务器");
}
@Override
protected boolean isLocal(Recorder recorder) {
//所有的域名最终的解析地点
return true;
}
}
我们再建立一个场景类模拟一下DNS解析过程,如代码清单32-41所示。
代码清单32-41 场景类
public class Client {
public static void main(String[] args) throws Exception {
//上海域名服务器
DnsServer sh = new SHDnsServer();
//中国顶级域名服务器
DnsServer china = new ChinaTopDnsServer();
//全球顶级域名服务器
DnsServer top = new TopDnsServer();
//定义查询路径
china.setUpperServer(top);
sh.setUpperServer(china);
//解析域名
System.out.println("=====域名解析模拟器=====");
while(true){
System.out.print("\n请输入域名(输入N退出):");
String domain = (new BufferedReader(new InputStreamReader (System.in))).readLine();
if(domain.equalsIgnoreCase("n")){
return;
}
Recorder recorder = new Recorder();
recorder.setDomain(domain);
sh.update(null,recorder);
System.out.println("----DNS服务器解析结果----");
System.out.println(recorder);
}
}
}
与责任链模式中的场景类很相似。读者请注意sh.update(null,recorder)这句代码,这是我们虚拟了观察者触发动作,完整的做法是把场景类作为一个被观察者,然后设置观察者为上海DNS服务器,再进行测试,其结果完全相同,我们这里为减少代码量采用了简化处理,有兴趣的读者可以扩充实现。
我们来看看运行结果如何,结果如下所示:
=====域名解析模拟器=====
请输入域名(输入N退出):www.xxx.sh.cn
----DNS服务器解析结果----
域名:www.xxx.sh.cn
IP地址:197.15.34.227
解析者:上海DNS服务器
请输入域名(输入N退出):www.xxx.com.cn
----DNS服务器解析结果----
域名:www.xxx.com.cn
IP地址:201.177.148.99
解析者:上海DNS服务器
请输入域名(输入N退出):www.xxx.com
----DNS服务器解析结果----
域名:www.xxx.com
IP地址:251.41.14.230
解析者:上海DNS服务器
请输入域名(输入N退出):n
可以看出,所有的解析结果都是由上海DNS服务器返回的,这才是真正的DNS解析过程。如何知道它是由上海DNS服务器解析的还是由别的DNS服务器解析的呢?很好办,把代码拷贝过去,然后调试跟踪一下就可以了。或者仔细看看代码,理解一下代码逻辑也可以非常清楚地知道它是如何解析的。
再仔细看一下我们的代码逻辑,上下两个节点之间的关系很微妙,很有意思。
● 下级节点对上级节点顶礼膜拜
比如我们输入的这个域名www.xxx.com,上海域名服务器只知道它是由父节点(中国顶级DNS服务器)解析的,而不知道父节点把该请求转发给了更上层节点(全球顶级DNS服务器),也就是说下级节点关注的是上级节点的响应,只要是上级反馈的结果就认为是上级的。www.xxx.com这个域名最终是由最高节点(全球顶级DNS服务器)解析的,它把解析结果传递给第二个节点(中国顶级DNS服务器)时的签名为“全球顶级DNS服务器”,而第二个节点把请求传递给首节点(上海DNS服务器)时的签名被修改为“中国顶级DNS服务器”。所有从上级节点反馈的响应都认为是上级节点处理的结果,而不追究到底是不是真的是上级节点处理的。
● 上级节点对下级节点绝对信任
上级节点只对下级节点负责,它不关心下级节点的请求从何而来,只要是下级发送的请求就认为是下级的。还是以www.xxx.com域名为例,当最高节点(全球顶级DNS服务器)获得解析请求时,它认为这个请求是谁的?当然是第二个节点(中国顶级DNS服务器)的,否则它也不会把结果反馈给它,但是这个请求的源头却是首节点(上海DNS服务器)的。
32.3.3 小结
通过对DNS解析过程的实现,我们发现触发链和责任链虽然都是链结构,但是还是有区别的。
● 链中的消息对象不同
从首节点开始到最终的尾节点,两个链中传递的消息对象是不同的。责任链模式基本上不改变消息对象的结构,虽然每个节点都可以参与消费(一般是不参与消费),类似于“雁过拔毛”,但是它的结构不会改变,比如从首节点传递进来一个String对象或者Person对象,不会到链尾的时候成了int对象或者Human对象,这在责任链模式中是不可能的,但是在触发链模式中是允许的,链中传递的对象可以自由变化,只要上下级节点对传递对象了解即可,它不要求链中的消息对象不变化,它只要求链中相邻两个节点的消息对象固定。
● 上下节点的关系不同
在责任链模式中,上下节点没有关系,都是接收同样的对象,所有传递的对象都是从链首传递过来,上一节点是什么没有关系,只要按照自己的逻辑处理就成。而触发链模式就不同了,它的上下级关系很亲密,下级对上级顶礼膜拜,上级对下级绝对信任,链中的任意两个相邻节点都是一个牢固的独立团体。
● 消息的分销渠道不同
在责任链模式中,一个消息从链首传递进来后,就开始沿着链条向链尾运动,方向是单一的、固定的;而触发链模式则不同,由于它采用的是观察者模式,所以有非常大的灵活性,一个消息传递到链首后,具体怎么传递是不固定的,可以以广播方式传递,也可以以跳跃方式传递,这取决于处理消息的逻辑。
- 前言
- 第一部分 大旗不挥,谁敢冲锋——6大设计原则全新解读
- 第1章 单一职责原则
- 1.2 绝杀技,打破你的传统思维
- 1.3 我单纯,所以我快乐
- 1.4 最佳实践
- 第2章 里氏替换原则
- 2.2 纠纷不断,规则压制
- 2.3 最佳实践
- 第3章 依赖倒置原则
- 3.2 言而无信,你太需要契约
- 3.3 依赖的三种写法
- 3.4 最佳实践
- 第4章 接口隔离原则
- 4.2 美女何其多,观点各不同
- 4.3 保证接口的纯洁性
- 4.4 最佳实践
- 第5章 迪米特法则
- 5.2 我的知识你知道得越少越好
- 5.3 最佳实践
- 第6章 开闭原则
- 6.2 开闭原则的庐山真面目
- 6.3 为什么要采用开闭原则
- 6.4 如何使用开闭原则
- 6.5 最佳实践
- 第二部分 真刀实枪 ——23种设计模式完美演绎
- 第7章 单例模式
- 7.2 单例模式的定义
- 7.3 单例模式的应用
- 7.4 单例模式的扩展
- 7.5 最佳实践
- 第8章 工厂方法模式
- 8.2 工厂方法模式的定义
- 8.3 工厂方法模式的应用
- 8.4 工厂方法模式的扩展
- 8.5 最佳实践
- 第9章 抽象工厂模式
- 9.2 抽象工厂模式的定义
- 9.3 抽象工厂模式的应用
- 9.4 最佳实践
- 第10章 模板方法模式
- 10.2 模板方法模式的定义
- 10.3 模板方法模式的应用
- 10.4 模板方法模式的扩展
- 10.5 最佳实践
- 第11章 建造者模式
- 11.2 建造者模式的定义
- 11.3 建造者模式的应用
- 11.4 建造者模式的扩展
- 11.5 最佳实践
- 第12章 代理模式
- 12.2 代理模式的定义
- 12.3 代理模式的应用
- 12.4 代理模式的扩展
- 12.5 最佳实践
- 第13章 原型模式
- 13.2 原型模式的定义
- 13.3 原型模式的应用
- 13.4 原型模式的注意事项
- 13.5 最佳实践
- 第14章 中介者模式
- 14.2 中介者模式的定义
- 14.3 中介者模式的应用
- 14.4 中介者模式的实际应用
- 14.5 最佳实践
- 第15章 命令模式
- 15.2 命令模式的定义
- 15.3 命令模式的应用
- 15.4 命令模式的扩展
- 15.5 最佳实践
- 第16章 责任链模式
- 16.2 责任链模式的定义
- 16.3 责任链模式的应用
- 16.4 最佳实践
- 第17章 装饰模式
- 17.2 装饰模式的定义
- 17.3 装饰模式应用
- 17.4 最佳实践
- 第18章 策略模式
- 18.2 策略模式的定义
- 18.3 策略模式的应用
- 18.4 策略模式的扩展
- 18.5 最佳实践
- 第19章 适配器模式
- 19.2 适配器模式的定义
- 19.3 适配器模式的应用
- 19.4 适配器模式的扩展
- 19.5 最佳实践
- 第20章 迭代器模式
- 20.2 迭代器模式的定义
- 20.3 迭代器模式的应用
- 20.4 最佳实践
- 第21章 组合模式
- 21.2 组合模式的定义
- 21.3 组合模式的应用
- 21.4 组合模式的扩展
- 21.5 最佳实践
- 第22章 观察者模式
- 22.2 观察者模式的定义
- 22.3 观察者模式的应用
- 22.4 观察者模式的扩展
- 22.5 最佳实践
- 第23章 门面模式
- 23.2 门面模式的定义
- 23.3 门面模式的应用
- 23.4 门面模式的注意事项
- 23.5 最佳实践
- 第24章 备忘录模式
- 24.2 备忘录模式的定义
- 24.3 备忘录模式的应用
- 24.4 备忘录模式的扩展
- 24.5 最佳实践
- 第25章 访问者模式
- 25.2 访问者模式的定义
- 25.3 访问者模式的应用
- 25.4 访问者模式的扩展
- 25.5 最佳实践
- 第26章 状态模式
- 26.2 状态模式的定义
- 26.3 状态模式的应用
- 第27章 解释器模式
- 27.2 解释器模式的定义
- 27.3 解释器模式的应用
- 27.4 最佳实践
- 第28章 享元模式
- 28.2 享元模式的定义
- 28.3 享元模式的应用
- 28.4 享元模式的扩展
- 28.5 最佳实践
- 第29章 桥梁模式
- 29.2 桥梁模式的定义
- 29.3 桥梁模式的应用
- 29.4 最佳实践
- 第三部分 谁的地盘谁做主 ——设计模式PK
- 第30章 创建类模式大PK
- 30.1 工厂方法模式VS建造者模式
- 30.2 抽象工厂模式VS建造者模式
- 第31章 结构类模式大PK
- 31.1 代理模式VS装饰模式
- 31.2 装饰模式VS适配器模式
- 第32章 行为类模式大PK
- 32.1 命令模式VS策略模式
- 32.2 策略模式VS状态模式
- 32.3 观察者模式VS责任链模式
- 第33章 跨战区PK
- 33.1 策略模式VS桥梁模式
- 33.2 门面模式VS中介者模式
- 33.3 包装模式群PK
- 第四部分 完美世界 ——设计模式混编
- 第34章 命令模式+责任链模式
- 34.2 混编小结
- 第35章 工厂方法模式+策略模式
- 35.2 混编小结
- 第36章 观察者模式+中介者模式
- 36.2 混编小结
- 第五部分 扩展篇
- 第37章 MVC框架
- 37.2 最佳实践
- 第38章 新模式
- 38.1 规格模式
- 38.2 对象池模式
- 38.3 雇工模式
- 38.4 黑板模式
- 38.5 空对象模式
- 附录 23种设计模式彩图