7.5 最佳实践

单例模式是23个模式中比较简单的模式，应用也非常广泛，如在Spring中，每个Bean默认就是单例的，这样做的优点是Spring容器可以管理这些Bean的生命期，决定什么时候创建出来，什么时候销毁，销毁的时候要如何处理，等等。如果采用非单例模式（Prototype类型），则Bean初始化后的管理交由J2EE容器，Spring容器不再跟踪管理Bean的生命周期。

7.4 单例模式的扩展

如果一个类可以产生多个对象，对象的数量不受限制，则是非常容易实现的，直接使用new关键字就可以了，如果只需要一个对象，使用单例模式就可以了，但是如果要求一个类只能产生两三个对象呢？该怎么实现？我们还以皇帝为例来说明。

一般情况下，一个朝代的同一个时代只有一个皇帝，那有没有出现两个皇帝的情况呢？ 确实有，就出现在明朝，那三国期间的算不算？不算，各自称帝，各有各的地盘，国号不同。大家还记得《石灰吟》这首诗吗？作者是谁？于谦。他是被谁杀死的？明英宗朱祁镇。 对，就是那个在土木堡之变中被瓦剌俘虏的皇帝，被俘虏后，他弟弟朱祁钰当上了皇帝，就是明景帝，估计刚当上皇帝乐疯了，忘记把他哥哥朱祁镇升级为太上皇，在那个时期就出现了两个皇帝，这期间的大臣是非常郁闷的，为什么呀？因为可能出现今天参拜的皇帝和昨天的皇帝不相同，昨天给那个皇帝汇报，今天还要给这个皇帝汇报一遍，该情况的类图如图7-3所示。

这个类图看起来还算简单，但是实现就有点复杂了。Emperor类如代码清单7-5所示。

代码清单7-5 固定数量的皇帝类

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

public class Emperor {
    //定义最多能产生的实例数量
    private static int maxNumOfEmperor = 2;
    //每个皇帝都有名字，使用一个ArrayList来容纳，每个对象的私有属性
    private static ArrayList<String> nameList=new ArrayList<String>();
    //定义一个列表，容纳所有的皇帝实例
    private static ArrayList<Emperor> emperorList=new ArrayList<Emperor>();
    //当前皇帝序列号
    private static int countNumOfEmperor =0;
    //产生所有的对象
    static{
        for(int i=0;i<maxNumOfEmperor;i++){
            emperorList.add(new Emperor("皇"+(i+1)+"帝"));
        }
    }
    private Emperor(){
        //世俗和道德约束你，目的就是不产生第二个皇帝
    }
    //传入皇帝名称，建立一个皇帝对象
    private Emperor(String name){
        nameList.add(name);
    }
    //随机获得一个皇帝对象
    public static Emperor getInstance(){
        Random random = new Random();
        //随机拉出一个皇帝，只要是个精神领袖就成
        countNumOfEmperor = random.nextInt(maxNumOfEmperor);
        return emperorList.get(countNumOfEmperor);
    }
    //皇帝发话了
    public static void say(){
        System.out.println(nameList.get(countNumOfEmperor));
    }
}

在Emperor中使用了两个ArrayList分别存储实例和实例变量。当然，如果考虑到线程安全问题可以使用Vector来代替。臣子参拜皇帝的过程如代码清单7-6所示。

代码清单7-6 臣子参拜皇帝的过程

1
2
3
4
5
6
7
8
9
10
11

public class Minister {
    public static void main(String[] args) {
        //定义5个大臣
        int ministerNum =5;
        for(int i=0;i<ministerNum;i++){
            Emperor emperor = Emperor.getInstance();
            System.out.print("第"+(i+1)+"个大臣参拜的是：");
            emperor.say();
        }
    }
}

大臣参拜皇帝的结果如下所示。

1
2
3
4
5

第1个大臣参拜的是：皇1帝 
第2个大臣参拜的是：皇2帝 
第3个大臣参拜的是：皇1帝 
第4个大臣参拜的是：皇1帝 
第5个大臣参拜的是：皇2帝

看，果然每个大臣参拜的皇帝都可能不一样，大臣们就开始糊涂了，A大臣给皇1帝汇报了一件事情，皇2帝不知道，然后就开始怀疑大臣A是皇1帝的亲信，然后就想办法开始整……

这种需要产生固定数量对象的模式就叫做有上限的多例模式，它是单例模式的一种扩展，采用有上限的多例模式，我们可以在设计时决定在内存中有多少个实例，方便系统进行扩展，修正单例可能存在的性能问题，提供系统的响应速度。例如读取文件，我们可以在系统启动时完成初始化工作，在内存中启动固定数量的reader实例，然后在需要读取文件时就可以快速响应。

7.3 单例模式的应用

7.3.1 单例模式的优点

• 由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
• 由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永久驻留内存的方式来解决（在Java EE中采用单例模式时需要注意JVM 垃圾回收机制）。
• 单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
• 单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。

7.3.2 单例模式的缺点

• 单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本上没有第二种途径可以实现。单例模式为什么不能增加接口呢？因为接口对单例模式是没有任何意义的，它要求“自行实例化”，并且提供单一实例、接口或抽象类是不可能被实例化的。当然，在特殊情况下，单例模式可以实现接口、被继承等，需要在系统开发中根据环境判断。
• 单例模式对测试是不利的。在并行开发环境中，如果单例模式没有完成，是不能进行测试的，没有接口也不能使用mock的方式虚拟一个对象。
• 单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。

7.3.3 单例模式的使用场景

在一个系统中，要求一个类有且仅有一个对象，如果出现多个对象就会出现“不良反应”，可以采用单例模式，具体的场景如下：

• 要求生成唯一序列号的环境；
• 在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
• 创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；
• 需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。

7.3.4 单例模式的注意事项

首先，在高并发情况下，请注意单例模式的线程同步问题。单例模式有几种不同的实现方式，上面的例子不会出现产生多个实例的情况，但是如代码清单7-4所示的单例模式就需要考虑线程同步。

代码清单7-4 线程不安全的单例

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

public class Singleton {
    private static Singleton singleton = null;
    //限制产生多个对象
    private Singleton(){
    }
    //通过该方法获得实例对象
    public static Singleton getSingleton(){
        if(singleton == null){
            singleton = new Singleton();
        }
        
        return singleton;
    }
}

该单例模式在低并发的情况下尚不会出现问题，若系统压力增大，并发量增加时则可能在内存中出现多个实例，破坏了最初的预期。为什么会出现这种情况呢？如一个线程A执行到singleton = new Singleton()，但还没有获得对象（对象初始化是需要时间的），第二个线程B也在执行，执行到（singleton == null）判断，那么线程B获得判断条件也是为真，于是继续运行下去，线程A获得了一个对象，线程B也获得了一个对象，在内存中就出现两个对象！

解决线程不安全的方法有很多，可以在getSingleton方法前加synchronized关键字，也可以在getSingleton方法内增加synchronized来实现，但都不是最优秀的单例模式，建议读者使用如代码清单7-3所示的方式（有的书上把代码清单7-3中的单例称为饿汉式单例，在代码清单7-4 中增加了synchronized的单例称为懒汉式单例）。

其次，需要考虑对象的复制情况。在Java中，对象默认是不可以被复制的，若实现了Cloneable接口，并实现了clone方法，则可以直接通过对象复制方式创建一个新对象，对象复制是不用调用类的构造函数的，因此即使是私有的构造函数，对象仍然可以被复制。在一般情况下，类复制的情况不需要考虑，很少会出现一个单例类会主动要求被复制的情况，解决该问题的最好方法就是单例类不要实现Cloneable接口。

5.1.2 对象的产生和使用

创建对象的根本途径是构造器,通过new关键字来调用某个类的构造器即可创建这个类的实例。
创建对象之后,接下来即可使用该对象了,Java的对象大致有如下作用。

• 访问对象的实例变量。

• 调用对象的方法。

• static修饰的方法和成员变量,既可通过类来调用,也可通过实例来调用;

• 没有使用static修饰的普通方法和成员变量,只可通过实例来调用。

5.1 类和对象

• 可以把类当成一种自定义类型,
• 可以使用类来定义变量,
• 类定义的变量统称为引用变量。
• 所有类是引用类型。

5.1.1 定义类

Java语言里定义类的简单语法如下:

1
2
3
4
5

修饰符 `class` 类名{
    零个到多个构造器定义,
    零个到多个成员变量定义,
    零个到多个方法定义,
}

类的修饰符

类的修饰符可以是public、final、 abstract,或者省略修饰符。

类名要求

从程序的可读性方面来看,Java类名必须是由一个或多个有意义的单词连缀而成的,每个单词首字母大写,其他字母全部小写,单词与单词之间不要使用任何分隔符。

类的成员

类可以包含三种最常见的成员:构造器、成员变量和方法,三种成员都可以定义零个或多个。

空类

如果三种成员都只定义零个,就是定义了一个空类,这没有太大的实际意义。

类里各成员之间的定义顺序没有任何影响,各成员之间可以相互调用,但需要指出的是,** static修饰的成员不能访问没有static修饰的成员**。

成员变量由来干什么

成员变量用于定义该类或该类的实例所包含的状态数据,

方法用来干什么

方法则用于定义该类或该类的实例的行为特征或者功能实现。

构造器干什么

构造器用于构造该类的实例,Java语言通过new关键字来调用构造器,从而返回该类的实例。

什么时候系统提供默认构造器

构造器是一个类创建对象的根本途径,如果一个类没有构造器,这个类通常无法创建实例。因此,Java语言提供了一个功能:如果程序员没有为一个类编写构造器,则系统会为该类提供一个默认的构造器。一旦程序员为一个类提供了构造器,系统将不再为该类提供构造器。

成员变量详解

定义成员变量的语法格式如下:

1

[修饰符] 类型 成员变量名[=默认值];

对定义成员变量语法格式的详细说明如下。

成员变量的修饰符

修饰符可以省略,也可以是public、 protected、 private、 static、 final,其中public、 protected、private三个最多只能出现其中之一,可以与static、 final组合起来修饰成员变量。

成员变量的类型

可以是Java语言允许的任何数据类型,包括基本类型和现在介绍的引用类型。

成员变量名

如果从程序可读性角度来看,成员变量名应该由一个或多个有意义的单词连缀而成,第一个单词首字母小写,后面每个单词首字母大写,其他字母全部小写,单词与单词之间不要使用任何分隔符,成员变量用于描述类或对象包含的状态数据,因此成员变量名建议使用英文名词。

默认值

定义成员变量还可以指定一个可选的默认值

方法详解

定义方法的语法格式如下:

1
2
3
4

[修饰符] 方法返回值类型 方法名(形参列表)
{
    //由零条到多条可执行性语句组成的方法体
}

对定义方法语法格式的详细说明如下。

方法的修饰符

修饰符:修饰符可以省略,也可以是public、 protected、 private、 static、 final、 abstract,其中public、protected、 private三个最多只能出现其中之一; abstract和final最多只能出现其中之一,它们可以与static组合起来修饰方法。

方法返回值类型

返回值类型可以是Java语言允许的任何数据类型,包括基本类型和引用类型.

如果声明了方法返回值类型,则方法体内必须有一个有效的return语句,该语句返回一个变量或一个表达式,这个变量或者表达式的类型必须与此处声明的类型匹配。
除此之外,如果一个方法没有返回值,则必须使用void来声明没有返回值。

方法名

方法名的命名规则与成员变量的命名规则基本相同,但由于方法用于描述该类或该类的实例的行为特征或功能实现,因此通常建议方法名以英文动词开头。

形参列表

形参列表用于定义该方法可以接受的参数,形参列表由零组到多组"参数类型 形参名"组合而成,多组参数之间以英文逗号(,)隔开,形参类型和形参名之间以英文空格隔开,一旦在定义方法时指定了形参列表,则调用该方法时必须传入对应的参数值,谁调用方法谁负责为形参赋值。

方法体

方法体里多条可执行性语句之间有严格的执行顺序,排在方法体前面的语句总是先执行,排在方法体后面的语句总是后执行

static关键字

static是一个特殊的关键字,它可用于修饰方法、成员变量等成员。

• static修饰的成员表明它属于这个类本身,而不属于该类的单个实例,因为通常把static修饰的成员变量和方法也称为类变量、类方法。
• 不使用static修饰的普通方法、成员变量则属于该类的单个实例,而不属于该类。
• 因为通常把不使用static修饰的成员变量和方法也称为实例变量、实例方法。

有时也把static修饰的成员变量和方法称为静态变量和静态方法,把不使用static修饰的成员变量和方法称为非静态变量和非静态方法。
静态成员不能直接访问非静态成员。

再说一遍

static相当于一个标志,有static修饰的成员属于类本身,没有static修饰的成员属于该类的实例。

构造器

构造器是一个特殊的方法,定义构造器的语法格式与定义方法的语法格式很像,定义构造器的语法格式如下:

1
2
3
4

[修饰符]  构造器名(形参列表)
{
    //由零条到多条可执行性语句组成的构造器执行体
}

构造器的修饰符

可以省略,也可以是public、 protected、 private其中之一。

构造器名

构造器名必须和类名相同。

形参列表

和定义方法形参列表的格式完全相同。

构造器不能定义返回值类型 不能用void修饰

构造器既不能定义返回值类型,也不能使用void声明。如果为构造器定义了返回值类型,或使用void声明构造器没有返回值,编译时不会出错,但Java会把这个所谓的构造器当成方法来处理，它将不再是构造器。

第5章 面向对象(上) 本章要点

• 定义类、成员变量和方法
• 创建并使用对象
• 对象和引用
• 方法必须属于类或对象
• Java方法的参数传递机制
• 递归方法
• 方法的重载
• 实现良好的封装
• 使用package和import
• 构造器的作用和构造器重载
• 继承的特点和用法
• 重写父类方法
• super关键字的用法
• 继承和多态
• 向上转型和强制类型转换
• 继承和组合的关系
• 使用组合来实现复用
• 构造器和初始化块的作用及区别
• 静态初始化块

类可被认为是一种自定义的数据类型,所有使用类定义的变量都是引用变量。
类用于描述客观世界里某一类对象的共同特征,而对象则是类的具体存在,
Java程序使用类的构造器来创建该类的对象。

面向对象的三大特征

封装、继承和多态.

访问控制修饰符

Java提供了private、 protected和public三个访问控制修饰符来实现良好的封装,

extends关键字

提供了extends关键字来让子类继承父类,子类继承父类就可以继承到父类的成员变量和方法,如果访问控制允许,子类实例可以直接调用父类里定义的方法。

继承和组合

继承是实现类复用的重要手段,除此之外,也可通过组合关系来实现这种复用,从某种程度上来看,继承和组合具有相同的功能。

继承和组合的区别

• 使用继承关系来实现复用时,子类对象可以直接赋给父类变量,这个变量具有多态性,编程更加灵活:
• 而利用组合关系来实现复用时,则不具备这种灵活性。

构造器和普通初始化块

构造器用于对类实例进行初始化操作,构造器支持重载,如果多个重载的构造器里包含了相同的初始化代码,则可以把这些初始化代码放置在普通初始化块里完成,初始化块总在构造器执行之前被调用。

静态初始化块

除此之外,Java还提供了一种静态初始化块,静态初始化块用于初始化类,在类初始化阶段被执行。

静态初始块 普通初始化块 构造器的区别

执行顺序不同

最先执行静态初始化块,然后执行初始化块,然后执行构造器

执行时机和次数不同

• 静态初始化块只会在类初始化阶段执行一次
• 创建一个对象,就会执行一次初始化块和构造器.

先初始化父类

如果继承树里的某一个类需要被初始化时,系统将会同时初始化该类的所有父类。

7.2 单例模式的定义

单例模式（Singleton Pattern）是一个比较简单的模式，其定义如下：

Ensure a class has only one instance, and provide a global point of access to it.（确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。）

单例模式的通用类图如图7-2所示。

Singleton类称为单例类，通过使用private的构造函数确保了在一个应用中只产生一个实例，并且是自行实例化的（在Singleton中自己使用new Singleton()）。单例模式的通用源代码如代码清单7-3所示。

代码清单7-3 单例模式通用代码

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

public class Singleton {
    private static final Singleton singleton = new Singleton();
    //限制产生多个对象
    private Singleton(){
    }
    //通过该方法获得实例对象
    public static Singleton getSingleton(){
        return singleton;
    }
    //类中其他方法，尽量是static
    public static void doSomething(){
        
    }
}

7.1 我是皇帝我独苗

自从秦始皇确立了皇帝这个位置以后，同一时期基本上就只有一个人孤零零地坐在这个位置。这种情况下臣民们也好处理，大家叩拜、谈论的时候只要提及皇帝，每个人都知道指的是谁，而不用在皇帝前面加上特定的称呼，如张皇帝、李皇帝。这一个过程反应到设计领域就是，要求一个类只能生成一个对象（皇帝），所有对象对它的依赖都是相同的，因为只有一个对象，大家对它的脾气和习性都非常了解，建立健壮稳固的关系，我们把皇帝这种特殊职业通过程序来实现。

皇帝每天要上朝接待臣子、处理政务，臣子每天要叩拜皇帝，皇帝只能有一个，也就是一个类只能产生一个对象，该怎么实现呢？对象产生是通过new关键字完成的（当然也有其他方式，比如对象复制、反射等），这个怎么控制呀，但是大家别忘记了构造函数，使用new关键字创建对象时，都会根据输入的参数调用相应的构造函数，如果我们把构造函数设置为private私有访问权限不就可以禁止外部创建对象了吗？臣子叩拜唯一皇帝的过程类图如图7-1所示。

代码清单7-1 皇帝类

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

public class Emperor {
    private static final Emperor emperor =new Emperor();
    //初始化一个皇帝
    private Emperor(){
        //世俗和道德约束你，目的就是不希望产生第二个皇帝
    }
    public static Emperor getInstance(){
        return emperor;
    }
    //皇帝发话了
    public static void say(){
        System.out.println("我就是皇帝某某某....");
    }
}

通过定义一个私有访问权限的构造函数，避免被其他类new出来一个对象，而Emperor自己则可以new一个对象出来，其他类对该类的访问都可以通过getInstance获得同一个对象。

皇帝有了，臣子要出场，其类如代码清单7-2所示。

代码清单7-2 臣子类

1
2
3
4
5
6
7
8
9

public class Minister {
    public static void main(String[] args) {
        for(int day=0;day<3;day++){
            Emperor emperor=Emperor.getInstance();
            emperor.say();
        }
        //三天见的皇帝都是同一个人，荣幸吧！
    }
}

臣子参拜皇帝的运行结果如下所示。

1
2
3

我就是皇帝某某某.... 
我就是皇帝某某某.... 
我就是皇帝某某某....

臣子天天要上朝参见皇帝，今天参拜的皇帝应该和昨天、前天的一样（过渡期的不考虑，别找茬哦），大臣磕完头，抬头一看，嗨，还是昨天那个皇帝，老熟人了，容易讲话，这就是单例模式。

6.5 最佳实践

软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。 我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化，我们在前5章中讲过如下设计原则。

• Single Responsibility Principle：单一职责原则
• Open Closed Principle：开闭原则
• Liskov Substitution Principle：里氏替换原则
• Law of Demeter：迪米特法则
• Interface Segregation Principle：接口隔离原则
• Dependence Inversion Principle：依赖倒置原则

把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID（solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。

开闭原则也只是一个原则

开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但是遵循这6大设计原则基本上可以应对大多数变化。因此，我们在项目中应尽量采用这6大原则，适当时候可以进行扩充，例如通过类文件替换的方式完全可以解决系统中的一些缺陷。 大家在开发中比较常用的修复缺陷的方法就是类替换，比如一个软件产品已经在运行中，发现了一个缺陷，需要修正怎么办？如果有自动更新功能，则可以下载一个.class文件直接覆盖原有的class，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

项目规章非常重要

如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提高技术成员水平，等等。

预知变化

在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求，还要适应可能发生的变化，这才是一个优良的架构。

开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向努力，可以非常显著地改善一个系统的架构，真正做到“拥抱变化”。

6.4 如何使用开闭原则

开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，但是开闭原则并不局限于这么多，它“虚”得没有边界，就像“好好学习，天天向上”的口号一样，告诉我们要好好学习，但是学什么，怎么学并没有告诉我们，需要去体会和掌握，开闭原则也是一个口号，那我们怎么把这个口号应用到实际工作中呢？

1. 抽象约束

抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性， 可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。还是以书店为例，目前只是销售小说类书籍，单一经营毕竟是有风险的，于是书店新增加了计算机书籍，它不仅包含书籍名称、作者、价格等信息，还有一个独特的属性：面向的是什么领域，也就是它的范围，比如是和编程语言相关的，还是和数据库相关的，等等，修改后的类图如图6-3所示。

增加了一个接口IComputerBook和实现类ComputerBook，而BookStore不用做任何修改就可以完成书店销售计算机书籍的业务。计算机书籍接口如代码清单6-8所示。

代码清单6-8 计算机书籍接口

1
2
3
4

public interface IComputerBook extends IBook{
    //计算机书籍是有一个范围
    public String getScope();
}

很简单，计算机书籍增加了一个方法，就是获得该书籍的范围，同时继承IBook接口， 毕竟计算机书籍也是书籍，其实现如代码清单6-9所示。

代码清单6-9 计算机书籍类

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 ComputerBook implements IComputerBook {
    private String name;
    private String scope;
    private String author;
    private int price;
    public ComputerBook(String _name,int _price,String _author,String _scope){
        this.name=_name;
        this.price = _price;
        this.author = _author;
        this.scope = _scope;
    }
    public String getScope() {
        return this.scope;
    }
    public String getAuthor() {
        return this.author;
    }
    public String getName() {
        return this.name;
    }
    public int getPrice() {
        return this.price;
    }
}

这也很简单，实现IComputerBook就可以，而BookStore类没有做任何的修改，只是在static静态模块中增加一条数据，如代码清单6-10所示。

代码清单6-10 书店销售计算机书籍

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

public class BookStore {
    private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
    //static静态模块初始化数据，实际项目中一般是由持久层完成
    static{
        bookList.add(new NovelBook("天龙八部",3200,"金庸"));
        bookList.add(new NovelBook("巴黎圣母院",5600,"雨果"));
        bookList.add(new NovelBook("悲惨世界",3500,"雨果"));
        bookList.add(new NovelBook("金瓶梅",4300,"兰陵笑笑生"));
        //增加计算机书籍
        bookList.add(new ComputerBook("Think in Java",4300,"Bruce Eckel","编程语言"));
    }
    //模拟书店卖书
    public static void main(String[] args) {
        NumberFormat formatter = NumberFormat.getCurrencyInstance();
        formatter.setMaximumFractionDigits(2);
        System.out.println("-----------书店卖出去的书籍记录如下：-----------");
        for(IBook book:bookList){
            System.out.println("书籍名称：" + book.getName()+"\t书籍作者：" + book.getAuthor()+ "\t书籍价格：" + formatter.format (book.getPrice()/100.0)+"元");
        }
    }
}

书店开始销售计算机书籍，运行结果如下所示。

1
2
3
4
5
6

-----------书店卖出去的书籍记录如下：-----------
书籍名称：天龙八部	书籍作者：金庸	书籍价格：￥32.00元
书籍名称：巴黎圣母院	书籍作者：雨果	书籍价格：￥56.00元
书籍名称：悲惨世界	书籍作者：雨果	书籍价格：￥35.00元
书籍名称：金瓶梅	书籍作者：兰陵笑笑生	书籍价格：￥43.00元
书籍名称：Think in Java	书籍作者：Bruce Eckel	书籍价格：￥43.00元

如果我是负责维护的，我就非常乐意做这样的事情，简单而且不需要与其他的业务进行耦合。我唯一需要做的事情就是在原有的代码上添砖加瓦，然后就可以实现业务的变化。我们来看看这段代码有哪几层含义。

首先，ComputerBook类必须实现IBook的三个方法，是通过IComputerBook接口传递进来的约束，也就是我们制定的IBook接口对扩展类ComputerBook产生了约束力，正是由于该约束力，BookStore类才不需要进行大量的修改。

其次，如果原有的程序设计采用的不是接口，而是实现类，那会出现什么问题呢？我们把BookStore类中的私有变量bookList修改一下，如下面的代码所示。

1

private final static ArrayList<NovelBook> bookList = new ArrayList<NovelBook>();

把原有IBook的依赖修改为对NovelBook实现类的依赖，想想看，我们这次的扩展是否还能继续下去呢？一旦这样设计，我们就根本没有办法扩展，需要修改原有的业务逻辑（也就是main方法），这样的扩展基本上就是形同虚设。

最后，如果我们在IBook上增加一个方法getScope，是否可以呢？答案是不可以，因为原有的实现类NovelBook已经在投产运行中，它不需要该方法，而且接口是与其他模块交流的契约，修改契约就等于让其他模块修改。因此，接口或抽象类一旦定义，就应该立即执行， 不能有修改接口的思想，除非是彻底的大返工。

所以，要实现对扩展开放，首要的前提条件就是抽象约束。

2. 元数据（metadata）控制模块行为

编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？答案是尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。举个非常简单的例子，login方法中提供了这样的逻辑：先检查IP地址是否在允许访问的列表中，然后再决定是否需要到数据库中验证密码（如果采用SSH架构，则可以通过Struts的拦截器来实现），该行为就是一个典型的元数据控制模块行为的例子，其中达到极致的就是控制反转（Inversion of Control）， 使用最多的就是Spring容器，在SpringContext配置文件中，基本配置如代码清单6-11所示。

代码清单6-11 SpringContext的基本配置文件

1
2
3
4

<bean id="father" class="xxx.xxx.xxx.Father" /> 
<bean id="xx" class="xxx.xxx.xxx.xxx"> 
    <property name="biz" ref="father"></property> 
</bean>

然后，通过建立一个Father类的子类Son，完成一个新的业务，同时修改SpringContext文件，修改后的文件如代码清单6-12所示。

代码清单6-12 扩展后的SpringContext配置文件

1
2
3
4

<bean id="son" class="xxx.xxx.xxx.Son" />
<bean id="xx" class="xxx.xxx.xxx.xxx">
    <property name="biz" ref="son"></property>
</bean>

通过扩展一个子类，修改配置文件，完成了业务变化，这也是采用框架的好处。

3. 制定项目章程

在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。相信大家都做过项目，会发现一个项目会产生非常多的配置文件。举个简单的例子，以SSH项目开发为例，一个项目中的Bean配置文件就非常多， 管理非常麻烦。如果需要扩展，就需要增加子类，并修改SpringContext文件。然而，如果你在项目中指定这样一个章程：所有的Bean都自动注入，使用Annotation进行装配，进行扩展时，甚至只用写一个子类，然后由持久层生成对象，其他的都不需要修改，这就需要项目内约束，每个项目成员都必须遵守，该方法需要一个团队有较高的自觉性，需要一个较长时间的磨合，一旦项目成员都熟悉这样的规则，比通过接口或抽象类进行约束效率更高，而且扩展性一点也没有减少。

4. 封装变化

对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二， 将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行封装的，我们会在各个模式中逐步讲解。