21.3 组合模式的应用

21.3.1 组合模式的优点

• 高层模块调用简单

一棵树形机构中的所有节点都是Component，局部和整体对调用者来说没有任何区别， 也就是说，高层模块不必关心自己处理的是单个对象还是整个组合结构，简化了高层模块的代码。

• 节点自由增加

使用了组合模式后，我们可以看看，如果想增加一个树枝节点、树叶节点是不是都很容易，只要找到它的父节点就成，非常容易扩展，符合开闭原则，对以后的维护非常有利。

21.3.2 组合模式的缺点

组合模式有一个非常明显的缺点，看到我们在场景类中的定义，提到树叶和树枝使用时的定义了吗？直接使用了实现类！这在面向接口编程上是很不恰当的，与依赖倒置原则冲突，读者在使用的时候要考虑清楚，它限制了你接口的影响范围。

21.3.3 组合模式的使用场景

• 维护和展示部分-整体关系的场景，如树形菜单、文件和文件夹管理。
• 从一个整体中能够独立出部分模块或功能的场景。

21.3.4 组合模式的注意事项

只要是树形结构，就要考虑使用组合模式，这个一定要记住，只要是要体现局部和整体的关系的时候，而且这种关系还可能比较深，考虑一下组合模式吧。

20.4 最佳实践

如果你是做Java开发，尽量不要自己写迭代器模式！省省吧，使用Java提供的Iterator一般就能满足你的要求了。

20.3 迭代器模式的应用

我们在例子中使用了迭代器模式后为什么使原本简单的应用变得复杂起来了呢？那是因为我们在简单的应用中使用了迭代器，在哪？请看代码清单20-3，注意这段话：for(IProject project:projectList)，它为什么能够运行起来？还不是因为ArrayList已经实现了iterator()方法， 我们才能如此简单地应用。

从JDK 1.2版本开始增加java.util.Iterator这个接口，并逐步把Iterator应用到各个聚集类 （Collection）中，我们来看JDK 1.5的API帮助文件，你会看到有一个叫java.util.Iterable的接口，看看有多少个接口继承了它：

1

BeanContext,BeanContextServices,BlockingQueue<E>,Collection<E>,List<E>,Queue<E>,Set<E>,SortedSet<E>

， 再看看有它多少个实现类：

1

AbstractCollection,AbstractList,AbstractQueue,AbstractSequentialList,AbstractSet,ArrayBlockingQueue,ArrayList,AttributeList,BeanContextServicesSupport,BeanContextSupport,ConcurrentLinkedQueue,CopyOnWriteArrayList,CopyOnWriteArraySet,DelayQueue,EnumSet,HashSet,JobStateReasons,LinkedBlockingQueue,LinkedHashSet,LinkedList,PriorityBlockingQueue,PriorityQueue,RoleList,RoleUnresolvedList,Stack,SynchronousQueue,TreeSet,Vector

， 基本上我们经常使用的类都在这个表中了，也正是因为Java把迭代器模式已经融入到基本 API中了，我们才能如此轻松、便捷。

我们再来看看Iterable接口。java.util.Iterable接口只有一个方法：iterator()，也就说，通过iterator()这个方法去遍历聚集类中的所有方法或属性，基本上现在所有的高级语言都有Iterator这个接口或者实现，Java已经把迭代器给我们准备好了，我们再去写迭代器，就有点多余了。所以呀，这个迭代器模式也有点没落了，基本上很少有项目再独立写迭代器了，直接使用Collection下的实现类就可以完美地解决问题。

迭代器现在应用得越来越广泛了，甚至已经成为一个最基础的工具。一些大师级人物甚至建议把迭代器模式从23个模式中删除，为什么呢？就是因为现在它太普通了，已经融入到各个语言和工具中了，比如PHP中你能找到它的身影，Perl也有它的存在，甚至是前台的页面技术AJAX也可以有它的出现（如在Struts2中就可以直接使用iterator）。基本上，只要你不是在使用那些古董级（指版本号）的编程语言的话，都不用自己动手写迭代器。

19.5 最佳实践

适配器模式是一个补偿模式，或者说是一个“补救”模式，通常用来解决接口不相容的问题，在百分之百的完美设计中是不可能使用到的，什么是百分之百的完美设计？“千虑”而没有“一失”的设计，但是，再完美的设计也会遇到“需求”变更这个无法逃避的问题，就以我们上面的人力资源管理系统为例来说，不管系统设计得多么完美，都无法逃避新业务的发生， 技术只是一个工具而已，是因为它推动了其他行业的进步和发展而具有了价值，通俗地说， 技术是为业务服务的，因此业务在日新月异变化的同时，也对技术提出了同样的要求，在这种要求下，就需要我们有一种或一些这样的补救模式诞生，使用这些补救模式可以保证我们的系统在生命周期内能够稳定、可靠、健壮的运行，而适配器模式就是这样的一个“救世主”，它在需求巨变、业务飞速而导致你极度郁闷、烦躁、崩溃的时候横空出世，它通过把非本系统接口的对象包装成本系统可以接受的对象，从而简化了系统大规模变更风险的存在。

19.4 适配器模式的扩展

我们刚刚讲的人力资源管理的例子中，其实是一个比较幸运的例子，为什么呢？如果劳动服务公司提供的人员接口不止一个，也就是说，用户基本信息是一个接口，工作信息是一个接口，家庭信息是一个接口，总共有三个接口三个实现类，想想看如何处理呢？不能再使用我们上面的方法了，为什么呢？Java是不支持多继承的，你难道想让OuterUserInfo继承三个实现类？此路不通，再想一个办法，对哦，可以使用类关联的办法嘛！声明一个OuterUserInfo实现类，实现IUserInfo接口，通过再关联其他三个实现类不就可以解决这个问题了吗？是的，是的，好方法，我们先画出类图，如图19-8所示。

OuterUserInfo通过关联的方式与外界的三个实现类通讯，当然也可以理解为是聚合关系。IUserInfo和UserInfo代码如代码清单19-1和代码清单19-2所示，不再赘述。我们来看看拆分后的三个接口和实现类，用户基本信息接口如代码清单19-13所示。

代码清单19-13 用户基本信息接口

1
2
3
4

public interface IOuterUserBaseInfo {
    //基本信息，比如名称、性别、手机号码等
    public Map getUserBaseInfo();
}

用户家庭信息接口如代码清单19-14所示。

代码清单19-14 用户家庭信息接口

1
2
3
4
5

public interface IOuterUserHomeInfo {
    //用户的家庭信息
    public Map getUserHomeInfo();
    
}

用户工作信息接口如代码清单19-15所示。

代码清单19-15 用户工作信息接口

1
2
3
4

public interface IOuterUserOfficeInfo {
    //工作区域信息
    public Map getUserOfficeInfo();
}

读到这里，读者应该想到这样一个问题：系统这样设计是否合理呢？合理，绝对合理！ 想想单一职责原则是怎么说的，类和接口要保持职责单一，在实际的应用中类可以有多重职责，但是接口一定要职责单一，因此，我们上面拆分接口的假想也是非常合乎逻辑的。我们来看三个相关的实现类，用户基本信息如代码清单19-16所示。

代码清单19-16 用户基本信息

1
2
3
4
5
6
7
8
9
10
11

public class OuterUserBaseInfo implements IOuterUserBaseInfo {
    /*
    * 用户的基本信息 
    */
    public Map getUserBaseInfo() {
        HashMap baseInfoMap = new HashMap();
        baseInfoMap.put("userName", "这个员工叫混世魔王...");
        baseInfoMap.put("mobileNumber", "这个员工电话是...");
        return baseInfoMap;
    }
}

用户家庭信息如代码清单19-17所示。

代码清单19-17 用户家庭信息

1
2
3
4
5
6
7
8
9
10
11

public class OuterUserHomeInfo implements IOuterUserHomeInfo {
    /*
    * 员工的家庭信息 
    */
    public Map getUserHomeInfo() {
        HashMap homeInfo = new HashMap();
        homeInfo.put("homeTelNumbner", "员工的家庭电话是...");
        homeInfo.put("homeAddress", "员工的家庭地址是...");
        return homeInfo;
    }
}

用户工作信息如代码清单19-18所示。

代码清单19-18 用户工作信息

1
2
3
4
5
6
7
8
9
10
11

public class OuterUserOfficeInfo implements IOuterUserOfficeInfo {
    /*
    * 员工的工作信息，比如，职位等 
    */
    public Map getUserOfficeInfo() {
        HashMap officeInfo = new HashMap();
        officeInfo.put("jobPosition","这个人的职位是BOSS...");
        officeInfo.put("officeTelNumber", "员工的办公电话是...");
        return officeInfo;
    }
}

这里又到我们的核心了——适配器。好，我们来看适配器代码，如代码清单19-19所示。

代码清单19-19 适配器

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

public class OuterUserInfo implements IUserInfo {
    //源目标对象
    private IOuterUserBaseInfo baseInfo = null;
    //员工的基本信息
    private IOuterUserHomeInfo homeInfo = null;
    //员工的家庭信息
    private IOuterUserOfficeInfo officeInfo = null;
    //工作信息
    //数据处理
    private Map baseMap = null;
    private Map homeMap = null;
    private Map officeMap = null;
    //构造函数传递对象
    public OuterUserInfo(IOuterUserBaseInfo _baseInfo,IOuterUserHomeInfo _homeInfo,IOuterUserOfficeInfo _officeInfo){
        this.baseInfo = _baseInfo;
        this.homeInfo = _homeInfo;
        this.officeInfo = _officeInfo;
        //数据处理
        this.baseMap = this.baseInfo.getUserBaseInfo();
        this.homeMap = this.homeInfo.getUserHomeInfo();
        this.officeMap = this.officeInfo.getUserOfficeInfo();
    }
    //家庭地址
    public String getHomeAddress() {
        String homeAddress = (String)this.homeMap.get("homeAddress");
        System.out.println(homeAddress);
        return homeAddress;
    }
    //家庭电话号码
    public String getHomeTelNumber() {
        String homeTelNumber = (String)this.homeMap.get("homeTelNumber");
        System.out.println(homeTelNumber);
        return homeTelNumber;
        
    }
    //职位信息
    public String getJobPosition() {
        String jobPosition = (String)this.officeMap.get("jobPosition");
        System.out.println(jobPosition);
        return jobPosition;
    }
    //手机号码
    public String getMobileNumber() {
        String mobileNumber = (String)this.baseMap.get("mobileNumber");
        System.out.println(mobileNumber);
        return mobileNumber;
    }
    //办公电话
    public String getOfficeTelNumber() {
        String officeTelNumber= (String)this.officeMap.get("officeTelNumber");
        System.out.println(officeTelNumber);
        return officeTelNumber;
    }
    // 员工的名称
    public String getUserName() {
        String userName = (String)this.baseMap.get("userName");
        System.out.println(userName);
        return userName;
    }
}

大家只要注意一下黑色字体的构造函数就可以了，它接收三个对象，其他部分变化不大，只是变量名称进行了修改，我们再来看场景类，如代码清单19-20所示。

代码清单19-20 场景类

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

public class Client {
    public static void main(String[] args) {
        //外系统的人员信息
        IOuterUserBaseInfo baseInfo = new OuterUserBaseInfo();
        IOuterUserHomeInfo homeInfo = new OuterUserHomeInfo();
        IOuterUserOfficeInfo officeInfo = new OuterUserOfficeInfo();
        //传递三个对象
        IUserInfo youngGirl = new OuterUserInfo(baseInfo,homeInfo,officeInfo);
        //从数据库中查到101个
        for(int i=0;i<101;i++){
            youngGirl.getMobileNumber();
        }
    }
}

运行的结果还是相同的。大家想想看，OuterUserInfo变成了委托服务，把IUserInfo接口需要的所有的操作都委托给其他三个接口下的实现类，它的委托是通过对象层次的关联关系进行委托的，而不是继承关系。好了，讲了这么多，我们需要给这种适配器起个名字，就是对象适配器，我们之前讲的通过继承进行的适配，叫做类适配器。对象适配器的通用类图， 如图19-9所示。

19.3 适配器模式的应用

19.3.1 适配器模式的优点

• 适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。
• 增加了类的透明性

想想看，我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块是透明的，也是它不需要关心的。

• 提高了类的复用度

当然了，源角色在原有的系统中还是可以正常使用，而在目标角色中也可以充当新的演员。

• 灵活性非常好

某一天，突然不想要适配器，没问题，删除掉这个适配器就可以了，其他的代码都不用修改，基本上就类似一个灵活的构件，想用就用，不想就卸载。

19.3.2 适配器模式的使用场景

适配器应用的场景只要记住一点就足够了：你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。

19.3.3 适配器模式的注意事项

适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题， 而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用中，就像我们上面的那个例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。

再次提醒一点，项目一定要遵守依赖倒置原则和里氏替换原则，否则即使在适合使用适配器的场合下，也会带来非常大的改造。

18.5 最佳实践

策略模式是一个非常简单的模式。它在项目中使用得非常多，但它单独使用的地方就比较少了，因为它有致命缺陷：所有的策略都需要暴露出去，这样才方便客户端决定使用哪一个策略。例如，在例子中的赵云，实际上不知道使用哪个策略，他只知道拆第一个锦囊，而不知道是BackDoor这个妙计。是的，诸葛亮已经在规定了在适当的场景下拆开指定的锦囊， 我们的策略模式只是实现了锦囊的管理，但是我们没有严格地定义“适当的场景”拆开“适当的锦囊”，在实际项目中，我们一般通过工厂方法模式来实现策略类的声明，读者可以参考混编模式。

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，相当于创建了一个新的类，这个对原有程序没有变更，通过扩展很好地完成了这次变更。