您的位置: 首页  >  文章  >  设计模式笔记--设计模式比较

设计模式笔记--设计模式比较

分类: 文章 • 2023-11-16 13:21:13

一、创建类模式大PK

创建类模式包括工厂方法模式、建造者模式、抽象工厂模式、单例模式和原型模式，它们都能够提供对象的创建和管理职责。其中的单例模式和原型模式非常容易理解，单例模式是要保持在内存中只有一个对象，原型模式是要求通过复制的方式产生一个新的对象，这两个不容易混淆。剩下的就是工厂方法模式、抽象工厂模式和建造者模式了，这三个之间有较多的相似性。  

1、工厂方法模式VS建造者模式


工厂方法模式注重的是整体对象的创建方法，而建造者模式注重的是部件构建的过程，旨在通过一步一步地精确构造创建出一个复杂的对象。

我们举个简单例子来说明两者的差异，如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

   1）按工厂方法建造超人  
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
超人制造工厂  
[java] view plain copy
  1. 代码清单30-4 超人制造工厂  
  2. public class SuperManFactory {  
  3. //定义一个生产超人的工厂  
  4. public static ISuperMan createSuperMan(String type){  
  5. //根据输入参数产生不同的超人  
  6. if(type.equalsIgnoreCase("adult")){  
  7. //生产成人超人  
  8. return new AdultSuperMan();  
  9. }else if(type.equalsIgnoreCase("child")){  
  10. //生产未成年超人  
  11. return new ChildSuperMan();  
  12. }else{  
  13. return null;  
  14. }  
  15. }  
  16. }  


建立了一个超人生产工厂，年复一年地生产超人，对于具体生产出的产品，不管是成年超人还是未成年超人，都是一个模样：深蓝色紧身衣、胸前S标记、内裤外穿，没有特殊的地方。

但是我们的目的达到了——生产出超人，拯救全人类，这就是我们的意图。具体怎么生产、怎么组装，这不是工厂方法模式要考虑的，

也就是说，工厂模式关注的是一个产品整体，生产出的产品应该具有相似的功能和架构。  
注意　通过工厂方法模式生产出对象，然后由客户端进行对象的其他操作，但是并不代表所有生产出的对象都必须具有相同的状态和行为，它是由产品所决定。  


2）按建造者模式建造超人  
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
成年超人建造者  
[java] view plain copy
  1. 代码清单30-8 成年超人建造者  
  2. public class AdultSuperManBuilder extends Builder {  
  3. @Override  
  4. public SuperMan getSuperMan() {  
  5. super.setBody("强壮的躯体");  
  6. super.setSpecialTalent("会飞行");  
  7. super.setSpecialSymbol("胸前带S标记");  
  8. return super.superMan;  
  9. }  
  10. }  


我们在抽象建造者上使用了模板方法模式，每一个建造者都必须返回一个产品，但是产品是如何制造的，则由各个建造者自己负责  

建造者模式的意图：通过不同的部件、不同装配产生不同的复杂对象  


区别
工厂方法模式和建造者模式都属于对象创建类模式，都用来创建类的对象。但它们之间的区别还是比较明显的。

● 意图不同
在工厂方法模式里，我们关注的是一个产品整体，如超人整体，无须关心产品的各部分是如何创建出来的；
但在建造者模式中，一个具体产品的产生是依赖各个部件的产生以及装配顺序，它关注的是“由零件一步一步地组装出产品对象”。
简单地说，工厂模式是一个对象创建的粗线条应用，建造者模式则是通过细线条勾勒出一个复杂对象，关注的是产品组成部分的创建过程。

● 产品的复杂度不同
工厂方法模式创建的产品一般都是单一性质产品，如成年超人，都是一个模样，而建造者模式创建的则是一个复合产品，它由各个部件复合而成，部件不同产品对象当然不同。这
不是说工厂方法模式创建的对象简单，而是指它们的粒度大小不同。一般来说，工厂方法模式的对象粒度比较粗，建造者模式的产品对象粒度比较细。

两者的区别有了，那在具体的应用中，我们该如何选择呢？
是用工厂方法模式来创建对象，还是用建造者模式来创建对象，这完全取决于我们在做系统设计时的意图
如果需要详细关注一个产品部件的生产、安装步骤，则选择建造者，否则选择工厂方法模式。  

2、抽象工厂模式VS建造者模式  


抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。

而建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品，

两者的区别还是比较明显的，
1）按抽象工厂模式生产车辆  

按照抽象工厂模式，首先需要定义一个抽象的产品接口即汽车接口，然后宝马和奔驰分别实现该接口，由于它们只具有了一个品牌属性，还没有定义一个具体的型号，属于对象的

抽象层次，每个具体车型由其子类实现，如R系列的奔驰车是商务车，X系列的宝马车属于SUV
设计模式笔记--设计模式比较
 
设计模式笔记--设计模式比较
对外界调用者来说，只要更换一个具备相同结构的对象，即可发生非常大的改变，如我们原本使用BenzFactory生产汽车，但是过了一段时间后，我们的系统需要生产宝马汽车，这
对系统来说不需要很大的改动，只要把工厂类使用BMWFactory代替即可，立刻可以生产出宝马车，注意这里生产的是一辆完整的车，对于一个产品，只要给出产品代码（车类型）即可生产，
抽象工厂模式把一辆车认为是一个完整的、不可拆分的对象。它注重完整性，一个产品一旦找到一个工厂生产，那就是固定的型号，不会出现一个宝马工厂生产奔驰车的情况。

那现在的问题是我们就想要一辆混合的车型，如奔驰的引擎，宝马的车轮，那该怎么处理呢？使用我们的建造者模式！  

2）按建造者模式生产车辆  

按照建造者模式设计一个生产车辆需要把车辆进行拆分，拆分成引擎和车轮两部分，然后由建造者进行建造，想要什么车，你只要有设计图纸就成，马上可以制造一辆车出来。

它注重的是对零件的装配、组合、封装，它从一个细微构件装配角度看待一个对象。

设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
抽象建造者 
[java] view plain copy
  1. public abstract class CarBuilder {  
  2. //待建造的汽车  
  3. private ICar car;  
  4. //设计蓝图  
  5. private Blueprint bp;  
  6. public Car buildCar(){  
  7. //按照顺序生产一辆车  
  8. return new Car(buildEngine(),buildWheel());  
  9. }  
  10. //接收一份设计蓝图  
  11. public void receiveBlueprint(Blueprint _bp){  
  12. this.bp = _bp;  
  13. }  
  14. //查看蓝图，只有真正的建造者才可以查看蓝图  
  15. protected Blueprint getBlueprint(){  
  16. return bp;  
  17. }  
  18. //建造车轮  
  19. protected abstract String buildWheel();  
  20. //建造引擎  
  21. protected abstract String buildEngine();  
  22. }  

导演类   
[java] view plain copy
  1. public class Director {  
  2. //声明对建造者的引用  
  3. private CarBuilder benzBuilder = new BenzBuilder();  
  4. private CarBuilder bmwBuilder = new BMWBuilder();  
  5. //生产奔驰SUV  
  6. public ICar createBenzSuv(){  
  7. //制造出汽车  
  8. return createCar(benzBuilder, "benz的引擎", "benz的轮胎");  
  9. }  
  10. //生产出一辆宝马商务车  
  11. public ICar createBMWVan(){  
  12. return createCar(benzBuilder, "BMW的引擎", "BMW的轮胎");  
  13. }  
  14. //生产出一个混合车型  
  15. public ICar createComplexCar(){  
  16. return createCar(bmwBuilder, "BMW的引擎", "benz的轮胎");  
  17. }  
  18. //生产车辆  
  19. private ICar createCar(CarBuilder _carBuilder,String engine,String wheel){  
  20. //导演怀揣蓝图  
  21. Blueprint bp = new Blueprint();  
  22. bp.setEngine(engine);  
  23. bp.setWheel(wheel);  
  24. System.out.println("获得生产蓝图");  
  25. _carBuilder.receiveBlueprint(bp);  
  26. return _carBuilder.buildCar();  
  27. }  
  28. }  


场景类只要找到导演类（也就是车间主任了）说给我制造一辆这样的宝马车，车间主任马上通晓你的意图，设计了一个蓝图，然后命令建造车间拼命加班加点建造，最终返回给你一件最新出品的产品  

我们只要有设计蓝图，可以立刻生产出一辆混合车型。

反观我们的抽象工厂模式，它是不可能实现该功能的，因为它更关注的是整体，而不关注到底用的是奔驰引擎还是宝马引擎，

而我们的建造者模式却可以很容易地实现该设计，市场信息变更了，我们就可以立刻跟进，生产出客户需要的产品。  
区别

注意看上面的描述，我们在抽象工厂模式中使用“工厂”来描述构建者，而在建造者模式中使用“车间”来描述构建者，其实我们已经在说它们两者的区别了，

抽象工厂模式就好比是一个一个的工厂，宝马车工厂生产宝马SUV和宝马VAN，奔驰车工厂生产奔驰车SUV和奔驰VAN，它是从一个更高层次去看对象的构建，具体到工厂内部还有很多的车间，如制造引擎的车间、装配引擎的车间等，但这些都是隐藏在工厂内部的细节，对外不公布。也就是对领导者来说，他只要关心一个工厂到底是生产什么产品的，不用关心具体怎么生产。

而建造者模式就不同了，它是由车间组成，不同的车间完成不同的创建和装配任务，一个完整的汽车生产过程需要引擎制造车间、引擎装配车间的配合才能完成，它们配合的基础就是设计蓝图，而这个蓝图是掌握在车间主任（导演类）手中，它给建造车间什么蓝图就能生产什么产品，建造者模式更关心建造过程。

虽然从外界看来一个车间还是生产车辆，但是这个车间的转型是非常快的，只要重新设计一个蓝图，即可产生不同的产品，这有赖于建造者模式的功劳。

相对来说，抽象工厂模式比建造者模式的尺度要大，它关注产品整体，而建造者模式关注构建过程，因此建造者模式可以很容易地构建出一个崭新的产品，只要导演类能够提供具体的工艺流程。

也正因为如此，两者的应用场景截然不同，

如果希望屏蔽对象的创建过程，只提供一个封装良好的对象，则可以选择抽象工厂方法模式。

而建造者模式可以用在构件的装配方面，如通过装配不同的组件或者相同组件的不同顺序，可以产生出一个新的对象，它可以产生一个非常灵活的架构，方便地扩展和维护系统。  

二、结构类模式大PK  


结构类模式包括适配器模式、桥梁模式、组合模式、装饰模式、门面模式、享元模式和代理模式。
为什么叫结构类模式呢？因为它们都是通过组合类或对象产生更大结构以适应更高层次的逻辑需求。
 
1、代理模式VS装饰模式  

首先要说的是，装饰模式就是代理模式的一个特殊应用，
两者的共同点是都具有相同的接口，
不同点则是代理模式着重对代理过程的控制，而装饰模式则是对类的功能进行加强或减弱，它着重类的功能变化
  
1)代理模式  

一个著名的短跑运动员有自己的代理人
设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
代理人
[java] view plain copy
  1. public class RunnerAgent implements IRunner {  
  2. private IRunner runner;  
  3. public RunnerAgent(IRunner _runner){  
  4. this.runner = _runner;  
  5. }  
  6. //代理人是不会跑的  
  7. public void run() {  
  8. Random rand = new Random();  
  9. if(rand.nextBoolean()){  
  10. System.out.println("代理人同意安排运动员跑步");  
  11. runner.run();  
  12. }else{  
  13. System.out.println("代理人心情不好，不安排运动员跑步");  
  14. }  
  15. }  
  16. }  


我们只是定义了一个代理人，并没有明确定义是哪一个运动员的代理，需要在运行时指定被代理者，而且我们还在代理人的run方法中做了判断，想让被代理人跑步就跑步，不乐意就拒绝，对于主题类的行为是否可以发生，代理类有绝对的控制权  

2)装饰模式  

装饰模式是对类功能的加强，怎么加强呢？增强跑步速度！

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

很惊讶？这个代理模式完全一样的类图？是的，完全一样！不过其实现的意图却不同，

装饰类RunnerWithJet  

[java] view plain copy
  1. public class RunnerWithJet implements IRunner {  
  2. private IRunner runner;  
  3. public RunnerWithJet(IRunner _runner){  
  4. this.runner = _runner;  
  5. }  
  6. public void run() {  
  7. System.out.println("加快运动员的速度：为运动员增加喷气装置");  
  8. runner.run();  
  9. }  
  10. }  


这和代理模式中的代理类也是非常相似的，只是装饰类对类的行为没有决定权，只有增强作用，也就是说它不决定被代理的方法是否执行，它只是再次增加被代理的功能  

区别分析
通过例子，我们可以看出代理模式和装饰模式有非常相似的地方，甚至代码实现都非常相似，特别是装饰模式中省略抽象装饰角色后，两者代码基本上相同，但是还是有细微的差别。

代理模式是把当前的行为或功能委托给其他对象执行，代理类负责接口限定：是否可以调用真实角色，以及是否对发送到真实角色的消息进行变形处理，它不对被主题角色（也就是被代理类）的功能做任何处理，保证原汁原味的调用。代理模式使用到极致开发就是AOP，这是各位采用Spring架构开发必然要使用到的技术，它就是使用了代理和反射的技术。

装饰模式是在要保证接口不变的情况下加强类的功能，它保证的是被修饰的对象功能比原始对象丰富（当然，也可以减弱），但不做准入条件判断和准入参数过滤，如是否可以执行类的功能，过滤输入参数是否合规等，这不是装饰模式关心的。

代理模式在Java的开发中俯拾皆是，是大家非常熟悉的模式，应用非常广泛，

而装饰模式是一个比较拘谨的模式，在实际应用中接触比较少，但是也有不少框架项目使用了装饰模式，例如在JDK的java.io.*包中就大量使用装饰模式，类似如下的代码：
OutputStream out = new DataOutputStream（new FileOutputStream（"test.txt"））
这是装饰模式的一个典型应用，使用DataOutputStream封装了一个FileOutputStream，以方便进行输出流处理。  


2、装饰模式VS适配器模式  

装饰模式和适配器模式在通用类图上没有太多的相似点，差别比较大，
但是它们的功能有相似的地方：都是包装作用，都是通过委托方式实现其功能。
不同点是：装饰模式包装的是自己的兄弟类，隶属于同一个家族（相同接口或父类），适配器模式则修饰非血缘关系类，把一个非本家族的对象伪装成本家族的对象，注意是伪装，因此它的本质还是非相同接口的对象。  

1)用装饰模式描述丑小鸭  

先设计一个丑小鸭，然后根据时间先后来进行不同的美化处理  
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

丑小鸭是一只白天鹅，但是初期的时候和鸭子很像
[java] view plain copy
  1. 代码清单31-8 丑小鸭  
  2. public class UglyDuckling implements Swan {  
  3. //丑小鸭的叫声  
  4. public void cry() {  
  5. System.out.println("叫声是克噜——克噜——克噜");  
  6. }  
  7. //丑小鸭的外形  
  8. public void desAppaearance() {  
  9. System.out.println("外形是脏兮兮的白色，毛茸茸的大脑袋");  
  10. }  
  11. //丑小鸭还比较小，不能飞  
  12. public void fly() {  
  13. System.out.println("不能飞行");  
  14. }  
  15. }  

抽象装饰类  
[java] view plain copy
  1. public class Decorator implements Swan {  
  2. private Swan swan;  
  3. //修饰的是谁  
  4. public Decorator(Swan _swan){  
  5. this.swan =_swan;  
  6. }  
  7. public void cry() {  
  8. swan.cry();  
  9. }  
  10. public void desAppaearance() {  
  11. swan.desAppaearance();  
  12. }  
  13. public void fly() {  
  14. swan.fly();  
  15. }  
  16. }  


场景类中通过装饰方法让它变为天鹅()
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //很久很久以前，这里有一个丑陋的小鸭子  
  4. System.out.println("===很久很久以前，这里有一只丑陋的小鸭子===");  
  5. Swan duckling = new UglyDuckling();  
  6. //展示一下小鸭子  
  7. duckling.desAppaearance(); //小鸭子的外形  
  8. duckling.cry(); //小鸭子的叫声  
  9. duckling.fly(); //小鸭子的行为  
  10. System.out.println("\n===小鸭子终于发现自己是一只天鹅====");  
  11. //首先外形变化了  
  12. duckling = new BeautifyAppearance(duckling);  
  13. //其次行为也发生了改变  
  14. duckling = new StrongBehavior(duckling);  
  15. //虽然还是叫丑小鸭，但是已经发生了很大变化  
  16. duckling.desAppaearance(); //小鸭子的新外形  
  17. duckling.cry(); //小鸭子的新叫声  
  18. duckling.fly(); //小鸭子的新行为  
  19. }  
  20. }  


2)用适配器模式实现丑小鸭  

采用适配器模式实现丑小鸭变成白天鹅的过程要从鸭妈妈的角度来分析。通过分析，我们要做的就是要设计两个对象：鸭和天鹅，然后鸭妈妈把一只天鹅看成了小鸭子，最终时间到来的时候丑小鸭变成了白天鹅  
设计模式笔记--设计模式比较

设计模式笔记--设计模式比较

把白天鹅当做小鸭子看待  
[java] view plain copy
  1. public class UglyDuckling extends WhiteSwan implements Duck {  
  2. //丑小鸭的叫声  
  3. public void cry() {  
  4. super.cry();  
  5. }  
  6. //丑小鸭的外形  
  7. public void desAppearance() {  
  8. super.desAppaearance();  
  9. }  
  10. //丑小鸭的其他行为  
  11. public void desBehavior(){  
  12. //丑小鸭不仅会游泳  
  13. System.out.println("会游泳");  
  14. //还会飞行  
  15. super.fly();  
  16. }  
  17. }  


场景类 
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //鸭妈妈有5个孩子，其中4个都是一个模样  
  4. System.out.println("===妈妈有五个孩子，其中四个模样是这样的：===");  
  5. Duck duck = new Duckling();  
  6. duck.cry(); //小鸭子的叫声  
  7. duck.desAppearance(); //小鸭子的外形  
  8. duck.desBehavior(); //小鸭子的其他行为  
  9. System.out.println("\n===一只独特的小鸭子，模样是这样的：===");  
  10. Duck uglyDuckling = new UglyDuckling();  
  11. uglyDuckling.cry(); //丑小鸭的叫声  
  12. uglyDuckling.desAppearance(); //丑小鸭的外形  
  13. uglyDuckling.desBehavior(); //丑小鸭的其他行为  
  14. }  
  15. }  


区别分析

● 意图不同
装饰模式的意图是加强对象的功能，例子中就是把一个怯弱的小天鹅强化成了一个美丽、自信的白天鹅，它不改变类的行为和属性，只是增加（当然了，减弱类的功能也是可能存在的）功能，使美丽更加美丽，强壮更加强壮，安全更加安全；
而适配器模式关注的则是转化，它的主要意图是两个不同对象之间的转化，它可以把一个天鹅转化为一个小鸭子看待，也可以把一只小鸭子看成是一只天鹅(那估计要在小鸭子的背上装个螺旋桨了)，它关注转换。

● 施与对象不同
装饰模式装饰的对象必须是自己的同宗，也就是相同的接口或父类，只要在具有相同的属性和行为的情况下，才能比较行为是增加还是减弱；
适配器模式则必须是两个不同的对象，因为它着重于转换，只有两个不同的对象才有转换的必要，如果是相同对象还转换什么？！

● 场景不同
装饰模式在任何时候都可以使用，只要是想增强类的功能，
而适配器模式则是一个补救模式，一般出现在系统成熟或已经构建完毕的项目中，作为一个紧急处理手段采用。

● 扩展性不同
装饰模式很容易扩展！今天不用这个修饰，好，去掉；明天想再使用，好，加上。这都没有问题。而且装饰类可以继续扩展下去；
但是适配器模式就不同了，它在两个不同对象之间架起了一座沟通的桥梁，建立容易，去掉就比较困难了，需要从系统整体考虑是否能够撤销。  

三、   行为类模式大PK  

行为类模式包括责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。行为类模式的11个模式基本上都是大家耳熟能详的，而且它们之间还有很多的相似点，特别是一些扩展部分就更加相似了，我们挑选几个比较重要的模式进行对比说明。  

1、命令模式VS策略模式  

命令模式和策略模式的类图确实很相似，只是命令模式多了一个接收者（Receiver）角色。
它们虽然同为行为类模式，但是两者的区别还是很明显的。
策略模式的意图是封装算法，它认为“算法”已经是一个完整的、不可拆分的原子业务（注意这里是原子业务，而不是原子对象），即其意图是让这些算法独立，并且可以相互替，让行为的变化独立于拥有行为的客户；
而命令模式则是对动作的解耦，把一个动作的执行分为执行对象（接收者角色）、执行行为（命令角色），让两者相互独立而不相互影响。

zip压缩和gzip压缩（这里的压缩指的是压缩和解压缩两种对应的操作行为，下同）  

1)策略模式实现压缩算法  

策略模式中我们的侧重点是zip压缩算法和gzip压缩算法可以互相替换 

设计模式笔记--设计模式比较 

设计模式笔记--设计模式比较
两个具体的算法实现了同一个接口，完全遵循依赖倒转原则 

环境角色 
[java] view plain copy
  1. public class Context {  
  2. //指向抽象算法  
  3. private Algorithm al;  
  4. //构造函数传递具体的算法  
  5. public Context(Algorithm _al){  
  6. this.al = _al;  
  7. }  
  8. //执行压缩算法  
  9. public boolean compress(String source,String to){  
  10. return al.compress(source, to);  
  11. }  
  12. //执行解压缩算法  
  13. public boolean uncompress(String source,String to){  
  14. return al.uncompress(source, to);  
  15. }  
  16. }  


指定一个算法，执行该算法，一个标准的策略模式就编写完毕了  

策略模式关心的是算法是否可以相互替换  


2)命令模式实现压缩算法  

命令模式的主旨是封装命令，使请求者与实现者解耦。

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

类图看着复杂，但是还是一个典型的命令模式，通过定义具体命令完成文件的压缩、解压缩任务，注意我们这里对文件的每一个操作都是封装好的命令，对于给定的请求，命令不同，处理的结果当然也不同，这就是命令模式要强调的。

抽象命令定义了两个接收者的引用：zip接收者和gzip接收者，大家可以想象一下这两个“受气包”，它们完全是受众，人家让它干啥它就干啥，具体使用哪个接收者是命令决定的。具体命令有4个：zip压缩、zip解压缩、gzip压缩、gzip解压缩，  

调用者  
[java] view plain copy
  1. public class Invoker {  
  2. //抽象命令的引用  
  3. private AbstractCmd cmd;  
  4. public Invoker(AbstractCmd _cmd){  
  5. this.cmd = _cmd;  
  6. }  
  7. //执行命令  
  8. public boolean execute(String source,String to){  
  9. return cmd.execute(source, to);  
  10. }  
  11. }  


场景类  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //定义一个命令,压缩一个文件  
  4. AbstractCmd cmd = new ZipCompressCmd();  
  5. /* 
  6. * 想换一个？执行解压命令 
  7. * AbstractCmd cmd = new ZipUncompressCmd(); 
  8. */  
  9. //定义调用者  
  10. Invoker invoker = new Invoker(cmd);  
  11. //我命令你对这个文件进行压缩  
  12. System.out.println("========执行压缩命令========");  
  13. invoker.execute("c:\\windows", "d:\\windows.zip");  
  14. }  
  15. }  

想新增一个命令？当然没有问题，只要重新定义一个命令就成，命令改变了，高层模块只要调用它就成

它的实现是关注了命令的封装，是请求者与执行者彻底分开，执行者根本就不用了解命令的具体执行者，它只要封装一个命令——“给我用zip格式压缩这个文件”就可以了，具体由谁来执行，则由调用者负责，如此设计后，就可以保证请求者和执行者之间可以相互独立，各自发展而不相互影响。

同时，由于是一个命令模式，接收者的处理可以进行排队处理，在排队处理的过程中，可以进行撤销处理，比如客人点了一个菜，厨师还没来得及做，那要撤回很简单，撤回也是命令，这是策略模式所不能实现的。  

区别分析

策略模式和命令模式相似，特别是命令模式退化时，比如无接收者（接收者非常简单或者接收者是一个Java的基础操作，无需专门编写一个接收者），在这种情况下，命令模式和策略模式的类图完全一样，代码实现也比较类似，但是两者还是有区别的。

● 关注点不同
策略模式关注的是算法替换的问题，一个新的算法投产，旧算法退休，或者提供多种算法由调用者自己选择使用，算法的自由更替是它实现的要点。换句话说，策略模式关注的是算法的完整性、封装性，只有具备了这两个条件才能保证其可以自由切换。

命令模式则关注的是解耦问题，如何让请求者和执行者解耦是它需要首先解决的，解耦的要求就是把请求的内容封装为一个一个的命令，由接收者执行。由于封装成了命令，就同时可以对命令进行多种处理，例如撤销、记录等。

● 角色功能不同
在我们的例子中，策略模式中的抽象算法和具体算法与命令模式的接收者非常相似，但是它们的职责不同。
策略模式中的具体算法是负责一个完整算法逻辑，它是不可再拆分的原子业务单元，一旦变更就是对算法整体的变更。
而命令模式则不同，它关注命令的实现，也就是功能的实现。例如我们在分支中也提到接收者的变更问题，它只影响到命令族的变更，对请求者没有任何影响，从这方面来说，接收者对命令负责，而与请求者无关。命令模式中的接收者只要符合六大设计原则，完全不用关心它是否完成了一个具体逻辑，它的影响范围也仅仅是抽象命令和具体命令，对它的修改不会扩散到模式外的模块。当然，如果在命令模式中需要指定接收者，则需要考虑接收者的变化和封装，例如一个老顾客每次吃饭都点同一个厨师的饭菜，那就必须考虑接收者的抽象化问题。

● 使用场景不同
策略模式适用于算法要求变换的场景，而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。  

2、策略模式VS状态模式  


在行为类设计模式中，状态模式和策略模式是亲兄弟，两者非常相似，我们先看看两者的通用类图，把两者放在一起比较一下  
设计模式笔记--设计模式比较
  设计模式笔记--设计模式比较
两个类图非常相似，都是通过Context类封装一个具体的行为，都提供了一个封装的方法，是高扩展性的设计模式。但根据两者的定义，我们发现两者的区别还是很明显的：

策略模式封装的是不同的算法，算法之间没有交互，以达到算法可以自由切换的目的；

而状态模式封装的是不同的状态，以达到状态切换行为随之发生改变的目的。

这两种模式虽然都有变换的行为，但是两者的目标却是不同的。

举例来说明 ： 
人只要生下来就有工作可做，人在孩童时期的主要工作就是玩耍（学习只是在人类具有了精神意识行为后才产生的）；成人时期的主要工作是养活自己，然后为社会做贡献；老年时期的主要工作就是享受天伦之乐。
按照策略模式来分析，这三种不同的工作方式就是三个不同的具体算法，随着时光的推移工作内容随之更替，这和对一堆数组的冒泡排序、快速排序、插入排序一样，都是一系列的算法；
而按照状态模式进行设计，则认为人的状态（孩童、成人、老人）产生了不同的行为结果，这里的行为都相同，都是工作，但是它们的实现方式确实不同，也就是产生的结果不同，看起来就像是类改变了。  
1)策略模式实现人生  

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
这是非常典型的策略模式，没有太多的玄机，它定义了一个工作算法，然后有三个实现类：孩童工作、成年人工作和老年人工作。  
环境角色  
[java] view plain copy
  1. public class Context {  
  2. private WorkAlgorithm workMethod;  
  3. public WorkAlgorithm getWork() {  
  4. return workMethod;  
  5. }  
  6. public void setWork(WorkAlgorithm work) {  
  7. this.workMethod = work;  
  8. }  
  9. //每个算法都有必须具有的功能  
  10. public void work(){  
  11. workMethod.work();  
  12. }  
  13. }  


模拟该场景  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //定义一个环境角色  
  4. Context context=new Context();  
  5. System.out.println("====儿童的主要工作=====");  
  6. context.setWork(new ChildWork());  
  7. context.work();  
  8. System.out.println("\n====成年人的主要工作=====");  
  9. context.setWork(new AdultWork());  
  10. context.work();  
  11. System.out.println("\n====老年人的主要工作=====");  
  12. context.setWork(new OldWork());  
  13. context.work();  
  14. }  
  15. }  


通过采用策略模式我们实现了“工作”这个策略的三种不同算法，算法可以自由切换，到底用哪个算法由调用者（高层模块）决定。策略模式的使用重点是算法的自由切换——老的算法退休，新的算法上台，对模块的整体功能没有非常大的改变，非常灵活。而如果想要增加一个新的算法，比如未出生婴儿的工作，只要继承WorkAlgorithm就可以了。  

2)状态模式实现人生  

随着时间的变化，人的状态变化了，同时引起了人的工作行为改变，完全符合状态模式  

设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
抽象状态类  
[java] view plain copy
  1. 代码清单32-25 人的抽象状态  
  2. public abstract class HumanState {  
  3. //指向一个具体的人  
  4. protected Human human;  
  5. //设置一个具体的人  
  6. public void setHuman(Human _human){  
  7. this.human = _human;  
  8. }  
  9. //不管人是什么状态都要工作  
  10. public abstract void work();  
  11. }  


孩童状态  
[java] view plain copy
  1. public class ChildState extends HumanState{  
  2. //儿童的工作就是玩耍  
  3. public void work(){  
  4. System.out.println("儿童的工作是玩耍！");  
  5. super.human.setState(Human.ADULT_STATE);  
  6. }  
  7. }  
work有两个职责：完成工作逻辑和定义下一状态。  

成年人状态和老年人状态  
[java] view plain copy
  1. 代码清单32-27 成年人状态  
  2. public class AdultState extends HumanState {  
  3. //成年人的工作就是先养活自己，然后为社会做贡献  
  4. @Override  
  5. public void work() {  
  6. System.out.println("成年人的工作就是先养活自己，然后为社会做贡献！");  
  7. super.human.setState(Human.OLD_STATE);  
  8. }  
  9. }  
  10. 代码清单32-28 老年人状态  
  11. public class OldState extends HumanState {  
  12. //老年人的工作就是享受天伦之乐  
  13. @Override  
  14. public void work() {  
  15. System.out.println("老年人的工作就是享受天伦之乐！");  
  16. }  
  17. }  
每一个HumanState的子类都代表了一种状态，虽然实现的方法名work都相同，但是实现的内容却不同，也就是在不同的状态下行为随之改变。  

环境角色  
[java] view plain copy
  1. public class Human {  
  2. //定义人类都具备哪些状态  
  3. public static final HumanState CHIILD_STATE = new ChildState();  
  4. public static final HumanState ADULT_STATE = new AdultState();  
  5. public static final HumanState OLD_STATE = new OldState();  
  6. //定义一个人的状态  
  7. private HumanState state;  
  8. //设置一个状态  
  9. public void setState(HumanState _state){  
  10. this.state = _state;  
  11. this.state.setHuman(this);  
  12. }  
  13. //人类的工作  
  14. public void work(){  
  15. this.state.work();  
  16. }  
  17. }  



场景类  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //定义一个普通的人  
  4. Human human = new Human();  
  5. //设置一个人的初始状态  
  6. human.setState(new ChildState());  
  7. System.out.println("====儿童的主要工作=====");  
  8. human.work();  
  9. System.out.println("\n====成年人的主要工作=====");  
  10. human.work();  
  11. System.out.println("\n====老年人的主要工作=====");  
  12. human.work();  
  13. }  
  14. }  


运行结果与策略模式相同，但是两者的分析角度是大相径庭的。

策略模式的实现是通过分析每个人的工作方式的不同而得出三个不同的算法逻辑，

状态模式则是从人的生长规律来分析，每个状态对应了不同的行为，状态改变后行为也随之改变。

从以上示例中我们也可以看出，对于相同的业务需求，有很多种实现方法，问题的重点是业务关注的是什么，是人的生长规律还是工作逻辑？找准了业务的焦点，才能选择一个好的设计模式。  

区别分析
从例子中我们可以看出策略模式和状态模式确实非常相似，称之为亲兄弟亦不为过，但是这两者还是存在着非常大的差别，而且也是很容易区分的。

● 环境角色的职责不同
两者都有一个叫做Context环境角色的类，但是两者的区别很大：
策略模式的环境角色只是一个委托作用，负责算法的替换；
而状态模式的环境角色不仅仅是委托行为，它还具有登记状态变化的功能，与具体的状态类协作，共同完成状态切换行为随之切换的任务。

● 解决问题的重点不同
策略模式旨在解决内部算法如何改变的问题，也就是将内部算法的改变对外界的影响降低到最小，它保证的是算法可以自由地切换；
而状态模式旨在解决内在状态的改变而引起行为改变的问题，它的出发点是事物的状态，封装状态而暴露行为，一个对象的状态改变，从外界来看就好像是行为改变。

● 解决问题的方法不同
策略模式只是确保算法可以自由切换，但是什么时候用什么算法它决定不了；
而状态模式对外暴露的是行为，状态的变化一般是由环境角色和具体状态共同完成的，也就是说状态模式封装了状态的变化而暴露了不同的行为或行为结果。

● 应用场景不同
两者都能实现前面例子中的场景，但并不表示两者的应用场景相同，这只是为了更好地展示出两者的不同而设计的一个场景。
我们来想一下策略模式和状态模式的使用场景有什么不同，
策略模式只是一个算法的封装，可以是一个有意义的对象，也可以是一个无意义的逻辑片段，比如MD5加密算法，它是一个有意义的对象吗？不是，它只是我们数学上的一个公式的相关实现，它是一个算法，同时DES算法、RSA算法等都是具体的算法，也就是说它们都是一个抽象算法的具体实现类，从这点来看策略模式是一系列平行的、可相互替换的算法封装后的结果，这就限定了它的应用场景：算法必须是平行的，否则策略模式就封装了一堆垃圾，产生了“坏味道”。
状态模式则要求有一系列状态发生变化的场景，它要求的是有状态且有行为的场景，也就是一个对象必须具有二维（状态和行为）描述才能采用状态模式，如果只有状态而没有行为，则状态的变化就失去了意义。

● 复杂度不同
通常策略模式比较简单，这里的简单指的是结构简单，扩展比较容易，而且代码也容易阅读。当然，一个具体的算法也可以写得很复杂，只有具备很高深的数学、物理等知识的人才可以看懂，这也是允许的，我们只是说从设计模式的角度来分析，它是很容易被看懂的。
而状态模式则通常比较复杂，因为它要从两个角色看到一个对象状态和行为的改变，也就是说它封装的是变化，要知道变化是无穷尽的，因此相对来说状态模式通常都比较复杂，涉及面很多，虽然也很容易扩展，但是一般不会进行大规模的扩张和修正。  

3、观察者模式VS责任链模式  


看起来这两个模式没有太多的相似性，真没有吗？回答是有。

我们在观察者模式中也提到了触发链（也叫做观察者链）的问题，一个具体的角色既可以是观察者，也可以是被观察者，这样就形成了一个观察者链。这与责任链模式非常类似，它们都实现了事务的链条化处理，比如说在上课的时候你睡着了，打鼾声音太大，盖过了老师讲课声音，老师火了，捅到了校长这里，校长也处理不了，然后告状给你父母，于是你的魔鬼日子来临了，这是责任链模式，老师、校长、父母都是链中的一个具体角色，事件（你睡觉）在链中传递，最终由一个具体的节点来处理，并将结果反馈给调用者（你挨揍）。

那什么是触发链？
你还是在课堂上睡觉，还是打鼾声音太大，老师火了，但是老师掏出个扩音器来讲课，于是你睡不着了，同时其他同学的耳朵遭殃了，这就是触发链，其中老师既是观察者（相对你）也是被观察者（相对其他同学），事件从“你睡觉”到老师这里转化为“扩音器放大声音”，这也是一个链条结构，但是链结构中传递的事件改变了。

我们还是以一个具体的例子来说明两者的区别，DNS协议相信大家都听说过，只要在“网络设置”中设置一个DNS服务器地址就可以把我们需要的域名翻译成IP地址。
我们的意图就是要DNS服务器192.168.10.1解析出www.xxx.com.cn的IP地址，DNS服务器是如何工作的呢？DNS规定了每个区域的DNS服务器（Local DNS）只保留自己区域的域名解析，对于不能解析的域名，则提交上级域名解析器解析，最终由一台位于美国洛杉矶的顶级域名服务器进行解析，返回结果。很明显这是一个事务的链结构处理，我们使用两种模式来实现该解析过程。 

1)责任链模式实现DNS解析过程  
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

我们来解释一下类图，
Recorder是一个BO对象，它记录DNS服务器解析后的结果，包括域名、IP地址、属主（即由谁解析的），除此之外还有getter/setter方法。
DnsServer抽象类中的resolve方法是一个基本方法，每个DNS服务器都必须拥有该方法，它对DNS进行解析，如何解析呢？具体是由echo方法来实现的，每个DNS服务器独自实现。
抽象域名服务器  
[java] view plain copy
  1. public abstract class DnsServer {  
  2. //上级DNS是谁  
  3. private DnsServer upperServer;  
  4. //解析域名  
  5. public final Recorder resolve(String domain){  
  6. Recorder recorder=null;  
  7. if(isLocal(domain)){//是本服务器能解析的域名  
  8. recorder = echo(domain);  
  9. }else{//本服务器不能解析  
  10. //提交上级DNS进行解析  
  11. recorder = upperServer.resolve(domain);  
  12. }  
  13. return recorder;  
  14. }  
  15. //指向上级DNS  
  16. public void setUpperServer(DnsServer _upperServer){  
  17. this.upperServer = _upperServer;  
  18. }  
  19. //每个DNS都有一个数据处理区（ZONE）,检查域名是否在本区中  
  20. protected abstract boolean isLocal(String domain);  
  21. //每个DNS服务器都必须实现解析任务  
  22. protected Recorder echo(String domain){  
  23. Recorder recorder = new Recorder();  
  24. //获得IP地址  
  25. recorder.setIp(genIpAddress());  
  26. recorder.setDomain(domain);  
  27. return recorder;  
  28. }  
  29. //随机产生一个IP地址，工具类  
  30. private String genIpAddress(){  
  31. Random rand = new Random();  
  32. String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ return address;  
  33. }  
  34. }  
genIpAddress方法——没有在类图中展现出来，它用于实现随机生成IP地址，这是我们为模拟DNS解析场景而建立的一个虚拟方法  


上海DNS服务器  
[java] view plain copy
  1. public class SHDnsServer extends DnsServer {  
  2. @Override  
  3. protected Recorder echo(String domain) {  
  4. Recorder recorder= super.echo(domain);  
  5. recorder.setOwner("上海DNS服务器");  
  6. return recorder;  
  7. }  
  8. //定义上海的DNS服务器能处理的级别  
  9. @Override  
  10. protected boolean isLocal(String domain) {  
  11. return domain.endsWith(".sh.cn");  
  12. }  
  13. }  
覆写echo方法，各具体的DNS服务器实现自己的解析过程，属于个性化处理，它代表的是每个DNS服务器的不同处理逻辑。  

场景类 
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) throws Exception {  
  3. //上海域名服务器  
  4. DnsServer sh = new SHDnsServer();  
  5. //中国顶级域名服务器  
  6. DnsServer china = new ChinaTopDnsServer();  
  7. //全球顶级域名服务器  
  8. DnsServer top = new TopDnsServer();  
  9. //定义查询路径  
  10. china.setUpperServer(top);  
  11. sh.setUpperServer(china);  
  12. //解析域名  
  13. System.out.println("=====域名解析模拟器=====");  
  14. while(true){  
  15. System.out.print("\n请输入域名(输入N退出):");  
  16. String domain = (new BufferedReader(new InputStreamReader (System.if(domain.equalsIgnoreCase("n")){  
  17. return;  
  18. }  
  19. Recorder recorder = sh.resolve(domain);  
  20. System.out.println("----DNS服务器解析结果----");  
  21. System.out.println(recorder);  
  22. }  
  23. }  
  24. }  


这个模拟过程看起来很完整，它完全就是责任链模式的一个具体应用，把一个请求放置到链中的首节点，然后由链中的某个节点进行解析并将结果反馈给调用者  


2)触发链模式实现DNS解析过程  

肯定地说，采用责任链模式模拟DNS解析过程是不完美的，或者说是有缺陷的，我们先来看看真实的DNS解析过程，
 设计模式笔记--设计模式比较设计模式笔记--设计模式比较

也就是说首节点负责对请求者应答，其他节点都不与请求者交互，而只与自己的左右节点交互。  
上海DNS服务器做两件事务处理：一是响应请求者，二是存储该记录，以备其他请求者再次查询，这类似于数据缓存。  
设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
与责任链模式很相似，仅仅多了一个Observable父类和Observer接口，但是在实现上这两种模式有非常大的差异。  

先来解释一下抽象DnsServer的作用  
● 标示声明
表示所有的DNS服务器都具备双重身份：既是观察者也是被观察者，这很重要，它声明所有的服务器都具有相同的身份标志，具有该标志后就可以在链中随意移动，而无需固定在链中的某个位置（这也是链的一个重要特性）。
● 业务抽象
方法setUpperServer的作用是设置父DNS，也就是设置自己的观察者，update方法不仅仅是一个事件的处理者，也同时是事件的触发者。  
DnsServer  
[java] view plain copy
  1. public abstract class DnsServer extends Observable implements Observer {  
  2. //处理请求，也就是接收到事件后的处理  
  3. public void update(Observable arg0, Object arg1) {  
  4. Recorder recorder = (Recorder)arg1;  
  5. //如果本机能解析  
  6. if(isLocal(recorder)){  
  7. recorder.setIp(genIpAddress());  
  8. }else{//本机不能解析，则提交到上级DNS  
  9. responsFromUpperServer(recorder);  
  10. }  
  11. //签名  
  12. sign(recorder);  
  13. }  
  14. //作为被观察者，允许增加观察者，这里上级DNS一般只有一个  
  15. public void setUpperServer(DnsServer dnsServer){  
  16. //先清空，然后再增加  
  17. super.deleteObservers();  
  18. super.addObserver(dnsServer);  
  19. }  
  20. //向父DNS请求解析，也就是通知观察者  
  21. private void responsFromUpperServer(Recorder recorder){  
  22. super.setChanged();  
  23. super.notifyObservers(recorder);  
  24. }  
  25. //每个DNS服务器签上自己的名字  
  26. protected abstract void sign(Recorder recorder);  
  27. //每个DNS服务器都必须定义自己的处理级别  
  28. protected abstract boolean isLocal(Recorder recorder);  
  29. //随机产生一个IP地址，工具类  
  30. private String genIpAddress(){  
  31. Random rand = new Random();  
  32. String address = rand.nextInt(255) + "." + rand.nextInt(255) + "."+ return address;  
  33. }  
  34. }  
注意看一下responseFromUpperServer方法，它只允许设置一个观察者，因为一般的DNS服务器都只有一个上级DNS服务器。sign方法是签名，这个记录是由谁解析出来的，就由各个实现类独自来实现


上海DNS服务器  
[java] view plain copy
  1. public class SHDnsServer extends DnsServer {  
  2. @Override  
  3. protected void sign(Recorder recorder) {  
  4. recorder.setOwner("上海DNS服务器");  
  5. }  
  6. //定义上海的DNS服务器能处理的级别  
  7. @Override  
  8. protected boolean isLocal(Recorder recorder) {  
  9. return recorder.getDomain().endsWith(".sh.cn");  
  10. }  
  11. }  


场景类模拟一下DNS解析过程  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) throws Exception {  
  3. //上海域名服务器  
  4. DnsServer sh = new SHDnsServer();  
  5. //中国顶级域名服务器  
  6. DnsServer china = new ChinaTopDnsServer();  
  7. //全球顶级域名服务器  
  8. DnsServer top = new TopDnsServer();  
  9. //定义查询路径  
  10. china.setUpperServer(top);  
  11. sh.setUpperServer(china);  
  12. //解析域名  
  13. System.out.println("=====域名解析模拟器=====");  
  14. while(true){  
  15. System.out.print("\n请输入域名(输入N退出):");  
  16. String domain = (new BufferedReader(new InputStreamReader (System.if(domain.equalsIgnoreCase("n")){  
  17. return;  
  18. }  
  19. Recorder recorder = new Recorder();  
  20. recorder.setDomain(domain);  
  21. sh.update(null,recorder);  
  22. System.out.println("----DNS服务器解析结果----");  
  23. System.out.println(recorder);  
  24. }  
  25. }  
  26. }  


与责任链模式中的场景类很相似。读者请注意sh.update(null,recorder)这句代码，这是我们虚拟了观察者触发动作，完整的做法是把场景类作为一个被观察者，然后设置观察者为上海DNS服务器，再进行测试，其结果完全相同

区别分析

通过对DNS解析过程的实现，我们发现触发链和责任链虽然都是链结构，但是还是有区别的。

● 链中的消息对象不同
从首节点开始到最终的尾节点，两个链中传递的消息对象是不同的。
责任链模式基本上不改变消息对象的结构，虽然每个节点都可以参与消费（一般是不参与消费），类似于“雁过拔毛”，但是它的结构不会改变，比如从首节点传递进来一个String对象或者Person对象，不会到链尾的时候成了int对象或者Human对象，这在责任链模式中是不可能的，但是在触发链模式中是允许的，
链中传递的对象可以自由变化，只要上下级节点对传递对象了解即可，它不要求链中的消息对象不变化，它只要求链中相邻两个节点的消息对象固定。


● 上下节点的关系不同
在责任链模式中，上下节点没有关系，都是接收同样的对象，所有传递的对象都是从链首传递过来，上一节点是什么没有关系，只要按照自己的逻辑处理就成。
触发链模式就不同了，它的上下级关系很亲密，下级对上级顶礼膜拜，上级对下级绝对信任，链中的任意两个相邻节点都是一个牢固的独立团体。

● 消息的分销渠道不同
在责任链模式中，一个消息从链首传递进来后，就开始沿着链条向链尾运动，方向是单一的、固定的；
而触发链模式则不同，由于它采用的是观察者模式，所以有非常大的灵活性，一个消息传递到链首后，具体怎么传递是不固定的，可以以广播方式传递，也可以以跳跃方式传递，这取决于处理消息的逻辑。  


四、跨战区PK  

创建类模式描述如何创建对象，行为类模式关注如何管理对象的行为，结构类模式则着重于如何建立一个软件结构，虽然三种模式的着重点不同，但是在实际应用中还是有重叠的，会出现一种模式适用、另外一种模式也适用的情况，我们到底该选用哪一个设计模式呢？本章就带领读者进入不同类设计模式PK的世界中，让你清晰地认识到各个模式的不同点以及它们的特长。  

1、策略模式VS桥梁模式  

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
两者之间确实很相似。如果把策略模式的环境角色变更为一个抽象类加一个实现类，或者桥梁模式的抽象角色未实现，只有修正抽象化角色，想想看，这两个类图有什么地方不一样？完全一样！正是由于类似场景的存在才导致了两者在实际应用中经常混淆的情况发生  

大家都知道邮件有两种格式：文本邮件（Text Mail）和超文本邮件（HTML MaiL）,  

1)策略模式实现邮件发送  

  使用策略模式发送邮件，我们认为这两种邮件是两种不同的封装格式
设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
我们定义了一个邮件模板，它有两个实现类：TextMail（文本邮件）和HtmlMail（超文本邮件），分别实现两种不同格式的邮件封装。MailServer是一个环境角色，它接收一个MailTemplate对象，然后通过sendMail方法发送出去。  
我们使用策略模式实现两种算法的自由切换，它提供了这样的保证：封装邮件的两种行为是可选择的，至于选择哪个算法是由上层模块决定的。策略模式要完成的任务就是提供两种可以替换的算法  


2)桥梁模式实现邮件发送  

桥梁模式关注的是抽象和实现的分离，它是结构型模式，结构型模式研究的是如何建立一个软件架构
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

类图中我们增加了SendMail和Postfix两个邮件服务器来实现类，在邮件模板中允许增加发送者标记，其他与策略模式都相同。
在这里已经完成了一个独立的架构，邮件有了，发送邮件的服务器也具备了，是一个完整的邮件发送程序。
需要读者注意的是，SendMail类不是一个动词行为（发送邮件），它指的是一款开源邮件服务器产品，

邮件模板仅仅增加了一个add方法  

邮件服务器，也就是桥梁模式的抽象化角色  ，该类相对于策略模式的环境角色有两个改变：
[java] view plain copy
  1. public abstract class MailServer {  
  2. //发送的是哪封邮件  
  3. protected final MailTemplate m;  
  4. public MailServer(MailTemplate _m){  
  5. this.m = _m;  
  6. }  
  7. //发送邮件  
  8. public void sendMail(){  
  9. System.out.println("====正在发送的邮件信息====");  
  10. //发件人  
  11. System.out.println("发件人：" + m.getFrom());  
  12. //收件人  
  13. System.out.println("收件人：" + m.getTo());  
  14. //标题  
  15. System.out.println("邮件标题：" + m.getSubject());  
  16. //邮件内容  
  17. System.out.println("邮件内容：" + m.getContext());  
  18. }  
  19. }  


● 修改为抽象类。为什么要修改成抽象类？因为我们在设计一个架构，邮件服务器是一
个具体的、可实例化的对象吗？“给我一台邮件服务器”能实现吗？不能，只能说“给我一台
Postfix邮件服务器”，这才能实现，必须有一个明确的可指向对象。
● 变量m修改为Protected访问权限，方便子类调用。  


Postfix邮件服务器的实现  
[java] view plain copy
  1. public class Postfix extends MailServer {  
  2. public Postfix(MailTemplate _m) {  
  3. super(_m);  
  4. }  
  5. //修正邮件发送程序  
  6. public void sendMail(){  
  7. //增加邮件服务器信息  
  8. String context ="Received: from XXXX (unknown [xxx.xxx.xxx.xxx]) by super.m.add(context);  
  9. super.sendMail();  
  10. }  
  11. }  

覆写sendMail  ，因为每个邮件服务器在发送邮件时都会在邮件内容上留下自己的标志，一是广告作用，二是为了互联网上统计需要，三是方便同质软件的共振。

区别分析
策略模式和桥梁模式是如此相似，我们只能从它们的意图上来分析。

策略模式是一个行为模式，旨在封装一系列的行为，在例子中我们认为把邮件的必要信息（发件人、收件人、标题、内容）封装成一个对象就是一个行为，封装的格式（算法）不同，行为也就不同。

而桥梁模式则是解决在不破坏封装的情况下如何抽取出它的抽象部分和实现部分，它的前提是不破坏封装，让抽象部分和实现部分都可以独立地变化，在例子中，我们的邮件服务器和邮件模板是不是都可以独立地变化？不管是邮件服务器还是邮件模板，只要继承了抽象类就可以继续扩展，它的主旨是建立一个不破坏封装性的可扩展架构。

简单来说，策略模式是使用继承和多态建立一套可以自由切换算法的模式，桥梁模式是在不破坏封装的前提下解决抽象和实现都可以独立扩展的模式。

桥梁模式必然有两个“桥墩”——抽象化角色和实现化角色，只要桥墩搭建好，桥就有了，而策略模式只有一个抽象角色，可以没有实现，也可以有很多实现。

还是很难区分，是吧？多想想两者的意图，就可以理解为什么要建立两个相似的模式了。

我们在做系统设计时，可以不考虑到底使用的是策略模式还是桥梁模式，只要好用，能够解决问题就成，“不管黑猫白猫，抓住老鼠的就是好猫”。  

2、门面模式VS中介者模式  


门面模式为复杂的子系统提供一个统一的访问界面，它定义的是一个高层接口，该接口使得子系统更加容易使用，避免外部模块深入到子系统内部而产生与子系统内部细节耦合的
问题。
中介者模式使用一个中介对象来封装一系列同事对象的交互行为，它使各对象之间不再显式地引用，从而使其耦合松散，建立一个可扩展的应用架构。  
1)中介者模式实现工资计算  
这里假设工资与职位、税收有关，职位提升工资就会增加，同时税收也增加，职位下降了工资也同步降低，当然税收也降低。而如果税收比率增加了呢？工资自然就减少了  

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

我们主要分析的是三者之间的关系，通过类图可以发现三者之间已经没有耦合，原本在需求分析时我们发现三者有直接的交互，采用中介者模式后，三个对象之间已经相互独立了，全部委托中介者完成  
[java] view plain copy
  1. 代码清单33-11 抽象同事类  
  2. public abstract class AbsColleague {  
  3. //每个同事类都对中介者非常了解  
  4. protected AbsMediator mediator;  
  5. public AbsColleague(AbsMediator _mediator){  
  6. this.mediator = _mediator;  
  7. }  
  8. }  

在抽象同事类中定义了每个同事类对中介者都非常了解，如此才能把请求委托给中介者完成。
三个同事类都具有相同的设计，即定义一个业务接口以及每个对象必须实现的职责，同时既然是同事类就都继承AbsColleague。
抽象同事类只是一个标志性父类，并没有限制子类的业务逻辑，因此每一个同事类并没有违背单一职责原则  
抽象中介者  
[java] view plain copy
  1. public abstract class AbsMediator {  
  2. //工资  
  3. protected final ISalary salary;  
  4. //职位  
  5. protected final IPosition position;  
  6. //税收  
  7. protected final ITax tax;  
  8. public AbsMediator(){  
  9. salary = new Salary(this);  
  10. position = new Position(this);  
  11. tax = new Tax(this);  
  12. }  
  13. //工资增加了  
  14. public abstract void up(ISalary _salary);  
  15. //职位提升了  
  16. public abstract void up(IPosition _position);  
  17. //税收增加了  
  18. public abstract void up(ITax _tax);  
  19. //工资降低了  
  20. public abstract void down(ISalary _salary);  
  21. //职位降低了  
  22. public abstract void down(IPosition _position);  
  23. //税收降低了  
  24. public abstract void down(ITax _tax);  
  25. }  

在抽象中介者中我们定义了6个方法，分别处理职位升降、工资升降以及税收升降的业务逻辑，采用Java多态机制来实现，  
我们回过头来分析一下设计，在接收到需求后我们发现职位、工资、税收之间有着紧密的耦合关系，如果不采用中介者模式，则每个对象都要与其他两个对象进行通信，这势必会增加系统的复杂性，同时也使系统处于僵化状态，很难实现拥抱变化的理想。通过增加一个中介者，每个同事类的职位、工资、税收都只与中介者通信，中介者封装了各个同事类之间的逻辑关系，方便系统的扩展和维护。  

2)门面模式实现工资计算  

对外界的访问者来说，它只要传递进去一个人员名称和月份即可获得工资数，而不用关心其中的计算有多么复杂，这就用得上门面模式了。  
设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
该类图主要实现了工资计算，通过HRFacade门面可以查询用户的工资以及出勤天数等，而不用关心这个工资或者出勤天数是怎么计算出来的，从而屏蔽了外系统对工资计算模块的内部细节依赖。  
我们采用门面模式的目的是要求门面是无逻辑的，与业务无关，只是一个子系统的访问入口。门面模式只是一个技术层次上的实现，全部业务还是在子系统内实现  
[java] view plain copy
  1. 代码清单33-27 HR门面  
  2. public class HRFacade {  
  3. //总工资情况  
  4. private SalaryProvider salaryProvider = new SalaryProvider();  
  5. //考勤情况  
  6. private Attendance attendance = new Attendance();  
  7. //查询一个人的总收入  
  8. public int querySalary(String name,Date date){  
  9. return salaryProvider.totalSalary();  
  10. }  
  11. //查询一个员工一个月工作了多少天  
  12. public int queryWorkDays(String name){  
  13. return attendance.getWorkDays();  
  14. }  
  15. }  

我们使用了门面模式对薪水计算子系统进行封装，避免子系统内部复杂逻辑外泄，确保子系统的业务逻辑的单纯性，即使业务流程需要变更，影响的也是子系统内部功能，比如奖金需要与基本工资挂钩，这样的修改对外系统来说是透明的，只需要子系统内部变更即可。  

区别分析

门面模式和中介者模式之间的区别还是比较明显的，门面模式是以封装和隔离为主要任务，而中介者模式则是以调和同事类之间的关系为主，因为要调和，所以具有了部分的业务
逻辑控制。两者的主要区别如下：

● 功能区别
门面模式只是增加了一个门面，它对子系统来说没有增加任何的功能，子系统若脱离门面模式是完全可以独立运行的。
而中介者模式则增加了业务功能，它把各个同事类中的原有耦合关系移植到了中介者，同事类不可能脱离中介者而独立存在，除非是想增加系统的复杂性和降低扩展性。

● 知晓状态不同
对门面模式来说，子系统不知道有门面存在，而对中介者来说，每个同事类都知道中介者存在，因为要依靠中介者调和同事之间的关系，它们对中介者非常了解。

● 封装程度不同
门面模式是一种简单的封装，所有的请求处理都委托给子系统完成，而中介者模式则需要有一个中心，由中心协调同事类完成，并且中心本身也完成部分业务，它属于更进一步的
业务功能封装。  

3、包装模式群PK  


包装模式是一组模式而不是一个。包装模式包括：装饰模式、适配器模式、门面模式、代理模式、桥梁模式。  
它们只是充当黔首作用，你有问题，找我，但我不处理，我让其他人处理  

1)代理模式  

追星族想找明星签字  

设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

应该非常明确地指出一个经纪人是谁的代理，因此要在构造函数中接收一个明星对象，确定是要做这个明星的代理。
[java] view plain copy
  1. public class Agent implements IStar {  
  2. //定义是谁的经纪人  
  3. private IStar star;  
  4. //构造函数传递明星  
  5. public Agent(IStar _star){  
  6. this.star = _star;  
  7. }  
  8. //经纪人是不会签字的，签字了歌迷也不认  
  9. public void sign() {  
  10. star.sign();  
  11. }  
  12. }  


2)装饰模式  

粉饰一个演员  

设计模式笔记--设计模式比较

设计模式笔记--设计模式比较
抽象装饰类  
[java] view plain copy
  1. public abstract class Decorator implements IStar {  
  2. //粉饰的是谁  
  3. private IStar star;  
  4. public Decorator(IStar _star){  
  5. this.star = _star;  
  6. }  
  7. public void act() {  
  8. this.star.act();  
  9. }  
  10. }  


场景类  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //定义出所谓的明星  
  4. IStar freakStar = new FreakStar();  
  5. //看看他是怎么粉饰自己的  
  6. //演前吹嘘自己无所不能  
  7. freakStar = new HotAir(freakStar);  
  8. //演完后，死不承认自己演的不好  
  9. freakStar = new Deny(freakStar);  
  10. System.out.println("====看看一些虚假明星的形象====");  
  11. freakStar.act();  
  12. }  
  13. }  

3)适配器模式  

替身  被导演认为是明星演员
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较
替身演员   由普通演员来担任
[java] view plain copy
  1. public class Standin implements IStar {  
  2. private IActor actor;  
  3. //替身是谁  
  4. public Standin(IActor _actor){  
  5. this.actor = _actor;  
  6. }  
  7. public void act(String context) {  
  8. actor.playact(context);  
  9. }  
  10. }    


导演类     导演指定演员担任哪个明星的替身  
[java] view plain copy
  1. public class direcotr {  
  2. public static void main(String[] args) {  
  3. System.out.println("=======演戏过程模拟==========");  
  4. //定义一个大明星  
  5. IStar star = new FilmStar();  
  6. star.act("前十五分钟，明星本人演戏");  
  7. //导演把一个普通演员当做明星演员来用  
  8. IActor actor = new UnknownActor();  
  9. IStar standin= new Standin(actor);  
  10. standin.act("中间五分钟，替身在演戏");  
  11. star.act("后十五分钟，明星本人演戏");  
  12. }  
  13. }  


4)桥梁模式  

明星 多元化情形   专辑、 电影、主持等
设计模式笔记--设计模式比较
设计模式笔记--设计模式比较

抽象明星  
[java] view plain copy
  1. public abstract class AbsStar {  
  2. //一个明星参加哪些活动  
  3. protected final AbsAction action;  
  4. //通过构造函数传递具体活动  
  5. public AbsStar(AbstAction _action){  
  6. this.action = _action;  
  7. }  
  8. //每个明星都有自己的主要工作  
  9. public void doJob(){  
  10. action.desc();  
  11. }  
  12. }  


电影明星  
[java] view plain copy
  1. public class FilmStar extends AbsStar {  
  2. //默认的电影明星的主要工作是拍电影  
  3. public FilmStar(){  
  4. super(new ActFilm());  
  5. }  
  6. //也可以重新设置一个新职业  
  7. public FilmStar(AbsAction _action){  
  8. super(_action);  
  9. }  
  10. //细化电影明星的职责  
  11. public void doJob(){  
  12. System.out.println("\n======影星的工作=====");  
  13. super.doJob();  
  14. }  
  15. }  



场景类  
[java] view plain copy
  1. public class Client {  
  2. public static void main(String[] args) {  
  3. //声明一个电影明星  
  4. AbsStar zhangSan = new FilmStar();  
  5. //声明一个歌星  
  6. AbsStar liSi = new Singer();  
  7. //展示一下各个明星的主要工作  
  8. zhangSan.doJob();  
  9. liSi.doJob();  
  10. //当然，也有部分明星不务正业，比如歌星演戏  
  11. liSi = new Singer(new ActFilm());  
  12. liSi.doJob();  
  13. }  
  14. }  


区别分析
包装模式是大家在系统设计中经常会用到的模式，它们具有相似的特征：都是通过委托的方式对一个对象或一系列对象（例如门面模式）施行包装，有了包装，设计的系统才
更加灵活、稳定，并且极具扩展性。从实现的角度来看，它们都是代理的一种具体表现形式，我们来看看它们在使用场景上有什么区别。

代理模式主要用在不希望展示一个对象内部细节的场景中，比如一个远程服务不需要把远程连接的所有细节都暴露给外部模块，通过增加一个代理类，可以很轻松地实现被代理类
的功能封装。此外，代理模式还可以用在一个对象的访问需要限制的场景中，比如AOP。

装饰模式是一种特殊的代理模式，它倡导的是在不改变接口的前提下为对象增强功能，或者动态添加额外职责。就扩展性而言，它比子类更加灵活，例如在一个已经运行的项目
中，可以很轻松地通过增加装饰类来扩展系统的功能。

适配器模式的主要意图是接口转换，把一个对象的接口转换成系统希望的另外一个接口，这里的系统指的不仅仅是一个应用，也可能是某个环境，比如通过接口转换可以屏蔽外
界接口，以免外界接口深入系统内部，从而提高系统的稳定性和可靠性。

桥梁模式是在抽象层产生耦合，解决的是自行扩展的问题，它可以使两个有耦合关系的对象互不影响地扩展，比如对于使用笔画图这样的需求，可以采用桥梁模式设计成用什么笔
（铅笔、毛笔）画什么图（圆形、方形）的方案，至于以后需求的变更，如增加笔的类型，增加图形等，对该设计来说是小菜一碟。

门面模式是一个粗粒度的封装，它提供一个方便访问子系统的接口，不具有任何的业务逻辑，仅仅是一个访问复杂系统的快速通道，没有它，子系统照样运行，有了它，只是更方

便访问而已。  


http://blog.****.net/bihansheng2010/article/details/50524379



相关推荐