18.4 策略模式的扩展

先给出一道小学的题目：输入3个参数，进行加减法运算，参数中两个是int型的，剩下的一个参数是String型的，只有“+”、“-”两个符号可以选择，不要考虑什么复杂的校验，我们做的是白箱测试，输入的就是标准的int类型和合规的String类型，各位大侠，想想看，怎么做，简单得很！

有非常多的实现方式，我今天来说四种。先说第一种，写一个类，然后进行加减法运算，类图也不用画了，太简单了，如代码清单18-11所示。

代码清单18-11 最直接的加减法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class Calculator {
    //加符号
    private final static String ADD_SYMBOL = "+";
    //减符号
    private final static String SUB_SYMBOL = "-";
    public int exec(int a,int b,String symbol){
        int result =0;
        if(symbol.equals(ADD_SYMBOL)){
            result = this.add(a, b);
        }
        else if(symbol.equals(SUB_SYMBOL)){
            result = this.sub(a, b);
        }
        return result;
    }
    //加法运算
    private int add(int a,int b){
        return a+b;
    }
    //减法运算
    private int sub(int a,int b){
        return a-b;
    }
}

算法太简单了，每个程序员都会写。再写一个场景类如18-12所示。

代码清单18-12 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Client {
    public static void main(String[] args) {
        //输入的两个参数是数字
        int a = Integer.parseInt(args[0]);
        String symbol = args[1];
        //符号
        int b = Integer.parseInt(args[2]);
        System.out.println("输入的参数为："+Arrays.toString(args));
        //生成一个运算器
        Calculator cal = new Calculator();
        System.out.println("运行结果为："+a + symbol + b + "=" + cal.exec(a, b, symbol));
    }
}

输入3个参数，分别是100 + 200，运行结果如下所示：

1
2

输入的参数为：[100, +, 200] 
运行结果为：100+200=300

这个方案是非常简单的，能够解决问题，我相信这是大家最容易想到的方案，我们不评论这个方案的优劣，等把四个方案全部讲完了，你自己就会发现孰优孰劣。

我们再来看第二个方案，Calculator类太嗦了，简化算法如代码清单18-13所示。

代码清单18-13 简化算法

1
2
3
4
5
6
7
8
9

public class Calculator {
    //加符号
    private final static String ADD_SYMBOL = "+";
    //减符号
    private final static String SUB_SYMBOL = "-";
    public int exec(int a,int b,String symbol){
        return symbol.equals(ADD_SYMBOL)?a+b:a-b;
    }
}

这也非常简单，就是一个三目运算符，确实简化了很多。有缺陷先别管，我们主要讲设计，你在实际项目应用中要处理该程序中的缺陷。

该方案的场景类与方案一相同，如代码清单18-12所示，运行结果也相同，不再赘述。

我们再来思考第三个方案，本章介绍策略模式，那把策略模式应用到该需求是不是很合适啊？是的，非常合适！加减法就是一个具体的策略，非常简单，省略类图，直接看源码， 我们先来看抽象策略，定义每个策略必须实现的方法，如代码清单18-14所示。

代码清单18-14 引入策略模式

1
2
3

interface Calculator {
    public int exec(int a,int b);
}

抽象策略定义了一个唯一的方法来执行运算。至于具体执行的是加法还是减法，运算时由上下文角色决定。我们再来看两个具体的策略，如代码清单18-15所示。

代码清单18-15 具体策略

1
2
3
4
5
6
7
8
9
10
11
12

public class Add implements Calculator {
    //加法运算
    public int exec(int a, int b) {
        return a+b;
    }
}
public class Sub implements Calculator {
    //减法运算
    public int exec(int a, int b) {
        return a-b;
    }
}

封装角色的责任是保证策略时可以相互替换，如代码清单18-15所示。

代码清单18-16 上下文

1
2
3
4
5
6
7
8
9

public class Context {
    private Calculator cal = null;
    public Context(Calculator _cal){
        this.cal = _cal;
    }
    public int exec(int a,int b,String symbol){
        return this.cal.exec(a, b);
    }
}

代码都非常简单，该部分就不再增加注释信息了。上下文类负责把策略封装起来，具体怎么自由地切换策略则是由高层模块负责声明的，如代码清单18-17所示。

代码清单18-17 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class Client {
    //加符号
    public final static String ADD_SYMBOL = "+";
    //减符号
    public final static String SUB_SYMBOL = "-";
    public static void main(String[] args) {
        //输入的两个参数是数字
        int a = Integer.parseInt(args[0]);
        String symbol = args[1];
        //符号
        int b = Integer.parseInt(args[2]);
        System.out.println("输入的参数为："+Arrays.toString(args));
        //上下文
        Context context = null;
        //判断初始化哪一个策略
        if(symbol.equals(ADD_SYMBOL)){
            context = new Context(new Add());
        }
        else if(symbol.equals(SUB_SYMBOL)){
            context = new Context(new Sub());
        }
        System.out.println("运行结果为："+a+symbol+b+"="+context.exec(a,b,symbol));
    }
}

运行结果与方案一相同。我们想想看，在该策略模式的一个具体应用中，我们使用Context准备了一组算法（加法和减法），并封装了起来，具体使用哪一个策略（加法还是减法）则由上层模块声明，这样扩展性非常好。

现在只剩最后一个方案了，一般最后出场的都是重量级的人物，压场嘛！那就请出我们最后一个重量级角色，音乐响起，一个黑影站定舞台中央，所有灯光突然聚焦，主角缓缓抬起头，它就是——策略枚举！我们来看看其真实实力，如代码清单18-18所示。

代码清单18-18 策略枚举

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public enum Calculator {
    //加法运算
    ADD("+"){
        public int exec(int a,int b){
            return a+b;
        }
    }
    ,
    //减法运算
    SUB("-"){
        public int exec(int a,int b){
            return a - b;
        }
    }
    ;
    String value = "";
    //定义成员值类型
    private Calculator(String _value){
        this.value = _value;
    }
    
    //获得枚举成员的值
    public String getValue(){
        return this.value;
    }
    //声明一个抽象函数
    public abstract int exec(int a,int b);
}

先想一想它的名字，为什么叫做策略枚举？枚举没有问题，它就是一个Enum类型，那为什么又叫做策略呢？找找看能不能找到策略的影子在里面？是的，我们定义了一个抽象的方法exec，然后在每个枚举成员中进行了实现，如果不实现会怎么样呢？你试试看看，不实现该方法就不能编译，现在是不是清楚了？把原有定义在抽象策略中的方法移植到枚举中， 每个枚举成员就成为一个具体策略。简单吧，总结一下，策略枚举定义如下：

• 它是一个枚举。
• 它是一个浓缩了的策略模式的枚举。

当然，读者可能要反思了，我使用内置类也可以实现相同的功能，写一个Context类，然后把抽象策略、具体策略都内置进去，不就可以解决问题了，是的，可以解决，但是扩展性如何？可读性如何？代码是让人读的，然后才是让机器执行，别把顺序搞反了！

我们继续完善方案四，场景类稍有改动，如代码清单18-19所示。

代码清单18-19 场景类

1
2
3
4
5
6
7
8
9
10
11

public class Client {
    public static void main(String[] args) {
        //输入的两个参数是数字
        int a = Integer.parseInt(args[0]);
        String symbol = args[1];
        //符号
        int b = Integer.parseInt(args[2]);
        System.out.println("输入的参数为："+Arrays.toString(args));
        System.out.println("运行结果为："+a+symbol+b+"="+Calculator.ADD.exec(a,b));
    }
}

运行结果与方案一相同。看这个场景类，代码量非常少，而且还有一个显著的优点：真实地面向对象，看看这条语句：

1

Calculator.ADD.exec(a, b)

是不是类似于“拿出计算器（Calculator），对a和b进行加法运算（ADD），并立刻执行 (exec)”，这与我们日常接触逻辑是不是非常相似，这也正是我们架构师要担当的职责！

注意策略枚举是一个非常优秀和方便的模式，但是它受枚举类型的限制，每个枚举项都是public、final、static的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。

18.3 策略模式的应用

18.3.1 策略模式的优点

• 算法可以自由切换

这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。

• 避免使用多重条件判断

如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。

• 扩展性良好

这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。

18.3.2 策略模式的缺点

• 策略类数量增多

每一个策略都是一个类，复用的可能性很小，类数量增多。

• 所有的策略类都需要对外暴露

上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷， 如工厂方法模式、代理模式或享元模式。

18.3.3 策略模式的使用场景

• 多个类只有在算法或行为上稍有不同的场景。
• 算法需要自由切换的场景。

例如，算法的选择是由使用者决定的，或者算法始终在进化，特别是一些站在技术前沿的行业，连业务专家都无法给你保证这样的系统规则能够存在多长时间，在这种情况下策略模式是你最好的助手。

• 需要屏蔽算法规则的场景。

现在的科技发展得很快，人脑的记忆是有限的（就目前来说是有限的），太多的算法你只要知道一个名字就可以了，传递相关的数字进来，反馈一个运算结果，万事大吉。

18.3.4 策略模式的注意事项

如果系统中的一个策略家族的具体策略数量超过4个，则需要考虑使用混合模式，解决策略类膨胀和对外暴露的问题，否则日后的系统维护就会成为一个烫手山芋，谁都不想接。

17.4 最佳实践

装饰模式是对继承的有力补充。你要知道继承不是万能的，继承可以解决实际的问题， 但是在项目中你要考虑诸如易维护、易扩展、易复用等，而且在一些情况下（比如上面那个成绩单例子）你要是用继承就会增加很多子类，而且灵活性非常差，那当然维护也不容易了，也就是说装饰模式可以替代继承，解决我们类膨胀的问题。同时，你还要知道继承是静态地给类增加功能，而装饰模式则是动态地增加功能，在上面的那个例子中，我不想要SortDecorator这层的封装也很简单，于是直接在Father中去掉就可以了，如果你用继承就必须修改程序。

装饰模式还有一个非常好的优点：扩展性非常好。在一个项目中，你会有非常多的因素考虑不到，特别是业务的变更，不时地冒出一个需求，尤其是提出一个令项目大量延迟的需求时，那种心情是相当的难受！装饰模式可以给我们很好的帮助，通过装饰模式重新封装一个类，而不是通过继承来完成，简单点说，三个继承关系Father、Son、GrandSon三个类，我要在Son类上增强一些功能怎么办？我想你会坚决地顶回去！不允许，对了，为什么呢？你增强的功能是修改Son类中的方法吗？增加方法吗？对GrandSon的影响呢？特别是GrandSon 有多个的情况，你会怎么办？这个评估的工作量就够你受的，所以这是不允许的，那还是要解决问题的呀，怎么办？通过建立SonDecorator类来修饰Son，相当于创建了一个新的类，这个对原有程序没有变更，通过扩展很好地完成了这次变更。

17.3 装饰模式应用

17.3.1 装饰模式的优点

• 装饰类和被装饰类可以独立发展，而不会相互耦合。换句话说，Component类无须知道Decorator类，Decorator类是从外部来扩展Component类的功能，而Decorator也不用知道具体的构件。
• 装饰模式是继承关系的一个替代方案。我们看装饰类Decorator，不管装饰多少层，返回的对象还是Component，实现的还是is-a的关系。
• 装饰模式可以动态地扩展一个实现类的功能，这不需要多说，装饰模式的定义就是如此。

17.3.2 装饰模式的缺点

对于装饰模式记住一点就足够了：多层的装饰是比较复杂的。为什么会复杂呢？你想想看，就像剥洋葱一样，你剥到了最后才发现是最里层的装饰出现了问题，想象一下工作量吧，因此，尽量减少装饰类的数量，以便降低系统的复杂度。

17.3.3 装饰模式的使用场景

• 需要扩展一个类的功能，或给一个类增加附加功能。
• 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
• 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。

16.4 最佳实践

在例子和通用源码中Handler是抽象类，融合了模板方法模式，每个实现类只要实现两个方法：echo方法处理请求和getHandlerLevel获得处理级别，想想单一职责原则和迪米特法则吧，通过融合模板方法模式，各个实现类只要关注的自己业务逻辑就成了，至于说什么事要自己处理，那就让父类去决定好了，也就是说父类实现了请求传递的功能，子类实现请求的处理，符合单一职责原则，各个实现类只完成一个动作或逻辑，也就是只有一个原因引起类的改变，我建议大家在使用的时候用这种方法，好处是非常明显的了，子类的实现非常简单，责任链的建立也是非常灵活的。

责任链模式屏蔽了请求的处理过程，你发起一个请求到底是谁处理的，这个你不用关心，只要你把请求抛给责任链的第一个处理者，最终会返回一个处理结果（当然也可以不做任何处理），作为请求者可以不用知道到底是需要谁来处理的，这是责任链模式的核心，同时责任链模式也可以作为一种补救模式来使用。举个简单例子，如项目开发的时候，需求确认是这样的：一个请求（如银行客户存款的币种），一个处理者（只处理人民币），但是随着业务的发展（改革开放了嘛，还要处理美元、日元等），处理者的数量和类型都有所增加，那这时候就可以在第一个处理者后面建立一个链，也就是责任链来处理请求，如果是人民币，好，还是第一个业务逻辑来处理；如果是美元，好，传递到第二个业务逻辑来处理； 日元、欧元……这些都不用在对原有的业务逻辑产生很大改变，通过扩展实现类就可以很好地解决这些需求变更的问题。

责任链在实际的项目中使用也是比较多的，我曾经做过这样一个项目，界面上有一个用户注册功能，注册用户分两种，一种是VIP用户，也就是在该单位办理过业务的，一种是普通用户，一个用户的注册要填写一堆信息，VIP用户只比普通用户多了一个输入项：VIP序列号。注册后还需要激活，VIP和普通用户的激活流程也是不同的，VIP是自动发送邮件到用户的邮箱中就算激活了，普通用户要发送短信才能激活，为什么呢？获得手机号码以后好发广告短信啊！项目组就采用了责任链模式，甭管从前台传递过来的是VIP用户信息还是普通用户信息，统一传递到一个处理入口，通过责任链来完成任务的处理，类图如图16-5所示。

其中RegisterAction是继承了Strust2中的ActionSupport，实现HTTP传递过来对象组装，组装出一个HashMap对象UserInfoMap，传递给Handler的两个实现类，具体是哪个实现类来处理的，就由HashMap上的用户标识来做决定了，这个和上面我们举的例子很类似，读者可以自行实现。

16.3 责任链模式的应用

16.3.1 责任链模式的优点

责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌（例如在J2EE项目开发中，可以剥离出无状态Bean由责任链处理），两者解耦，提高系统的灵活性。

16.3.2 责任链模式的缺点

责任链有两个非常显著的缺点：一是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不很方便，特别是链条比较长， 环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。

16.3.3 责任链模式的注意事项

链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在setNext方法中判断是否已经是超过其阈值，超过则不允许该链建立，避免无意识地破坏系统性能。

14.4 中介者模式的实际应用

中介者模式也叫做调停者模式，是什么意思呢？一个对象要和N多个对象交流，就像对象间的战争，很混乱。这时，需要加入一个中心，所有的类都和中心交流，中心说怎么处理就怎么处理，我们举一些在开发和生活中经常会碰到的例子。

• 机场调度中心

大家在每个机场都会看到有一个“××机场调度中心”，它就是具体的中介者，用来调度每一架要降落和起飞的飞机。比如，某架飞机（同事类）飞到机场上空了，就询问调度中心 （中介者）“我是否可以降落”以及“降落到哪个跑道”，调度中心（中介者）查看其他飞机 （同事类）情况，然后通知飞机降落。如果没有机场调度中心，飞机飞到机场了，飞行员要先看看有没有飞机和自己一起降落的，有没有空跑道，停机位是否具备等情况，这种局面是难以想象的！

• MVC框架

大家都应该使用过Struts，MVC框架，其中的C（Controller）就是一个中介者，叫做前端控制器(Front Controller)，它的作用就是把M(Model，业务逻辑)和V（View，视图）隔离开， 协调M和V协同工作，把M运行的结果和V代表的视图融合成一个前端可以展示的页面，减少M和V的依赖关系。MVC框架已经成为一个非常流行、成熟的开发框架，这也是中介者模式的优点的一个体现。

• 媒体网关

媒体网关也是一个典型的中介者模式，比如使用MSN时，张三发消息给李四，其过程应该是这样的：张三发送消息，MSN服务器(中介者)接收到消息，查找李四，把消息发送到李四，同时通知张三，消息已经发送。在这里，MSN服务器就是一个中转站，负责协调两个客户端的信息交流，与此相反的就是IPMsg（也叫飞鸽），它没有使用中介者，而直接使用了UDP广播的方式，每个客户端既是客户端也是服务器端。

• 中介服务

现在中介服务非常多，比如租房中介、出国中介，这些也都是中介模式的具体体现，比如你去租房子，如果没有房屋中介，你就必须一个一个小区去找，看看有没有空房子，有没有适合自己的房子，找到房子后还要和房东签合约，自己检查房屋的家具、水电煤等；有了中介后，你就省心多了，找中介，然后安排看房子，看中了，签合约，中介帮你检查房屋家具、水电煤等等。这也是中介模式的实际应用。

14.5 最佳实践

本章讲述的中介者模式很少用到接口或者抽象类，这与依赖倒置原则是冲突的，这是什么原因呢？首先，既然是同事类而不是兄弟类（有相同的血缘），那就说明这些类之间是协作关系，完成不同的任务，处理不同的业务，所以不能在抽象类或接口中严格定义同事类必须具有的方法（从这点也可以看出继承是高侵入性的）。这是不合适的，就像你我是同事， 虽然我们大家都是朝九晚五地上班，但是你跟我干的活肯定不同，不可能抽象出一个父类统一定义同事所必须有的方法。当然，每个同事都要吃饭、上厕所，可以把这些最基本的信息封装到抽象中，但这些最基本的行为或属性是中介者模式要关心的吗？如果两个对象不能提炼出共性，那就不要刻意去追求两者的抽象，抽象只要定义出模式需要的角色即可。当然如果严格遵守面向接口编程的话，则是需要抽象的，这就需要读者在实际开发中灵活掌握。其次，在一个项目中，中介者模式可能被多个模块采用，每个中介者所围绕的同事类各不相同，你能抽象出一个具有共性的中介者吗？不可能，一个中介者抽象类一般只有一个实现者，除非中介者逻辑非常复杂，代码量非常大，这时才会出现多个中介者的情况。所以，对于中介者来说，抽象已经没有太多的必要。

中介者模式是一个非常好的封装模式，也是一个很容易被滥用的模式，一个对象依赖几个对象是再正常不过的事情，但是纯理论家就会要求使用中介者模式来封装这种依赖关系， 这是非常危险的！使用中介模式就必然会带来中介者的膨胀问题，这在一个项目中是很不恰当的。大家可以在如下的情况下尝试使用中介者模式：

• N个对象之间产生了相互的依赖关系（N＞2）。
• 多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散。
• 产品开发。一个明显的例子就是MVC框架，把中介者模式应用到产品中，可以提升产品的性能和扩展性，但是对于项目开发就未必，因为项目是以交付投产为目标，而产品则是以稳定、高效、扩展为宗旨。

14.3 中介者模式的应用

14.3.1 中介者模式的优点

中介者模式的优点就是减少类间的依赖，把原有的一对多的依赖变成了一对一的依赖， 同事类只依赖中介者，减少了依赖，当然同时也降低了类间的耦合。

14.3.2 中介者模式的缺点

中介者模式的缺点就是中介者会膨胀得很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。

14.3.3 中介者模式的使用场景

中介者模式简单，但是简单不代表容易使用，很容易被误用。在面向对象的编程中，对象和对象之间必然会有依赖关系，如果某个类和其他类没有任何相互依赖的关系，那这个类就是一个“孤岛”，在项目中就没有存在的必要了！就像是某个人如果永远独立生活，与任何人都没有关系，那这个人基本上就算是野人了——排除在人类这个定义之外。

类之间的依赖关系是必然存在的，一个类依赖多个类的情况也是存在的，存在即合理， 那是否可以说只要有多个依赖关系就考虑使用中介者模式呢？答案是否定的。中介者模式未必能帮你把原本凌乱的逻辑整理得清清楚楚，而且中介者模式也是有缺点的，这个缺点在使用不当时会被放大，比如原本就简单的几个对象依赖关系，如果为了使用模式而加入了中介者，必然导致中介者的逻辑复杂化，因此中介者模式的使用需要“量力而行”！中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构。在这种情况下一定要考虑使用中介者模式，这有利于把蜘蛛网梳理为星型结构，使原本复杂混乱的关系变得清晰简单。

13.5 最佳实践

原型模式先产生出一个包含大量共有信息的类，然后可以拷贝出副本，修正细节信息， 建立了一个完整的个性对象。不知道大家有没有看过施瓦辛格演的《第六日》这部电影，电影的主线也就是一个人被复制，然后正本和副本对掐。我们今天讲的原型模式也就是由一个正本可以创建多个副本的概念。可以这样理解：一个对象的产生可以不由零起步，直接从一个已经具备一定雏形的对象克隆，然后再修改为生产需要的对象。也就是说，产生一个人， 可以不从1岁长到2岁，再到3岁……也可以直接找一个人，从其身上获得DNA，然后克隆一个，直接修改一下就是30岁了！我们讲的原型模式也就是这样的功能。