设计模式之六大原则（一）

早知道设计模式的妙处，好的架构离不开设计模式的加持来应对无尽的需求变动，所以是时候好好补补课~

设计模式的六大原则（参考书籍：“设计模式之禅（第二版）”）

设计模式原则

1.单一性原则

什么是单一性原则？

单一性原则就是尽量让一个类只做一种事情（当然这是天方夜谭，可能会把程序员累死），但是我们可以尽量来这样设计啊，请看最佳实例：

最佳实例

//我们有一个电话的需求，当然这也可以是智能手机
public interface IPhone{
	//拨通电话
	public void dial(String phoneNumber);
	//通话
	public void chat(Object o);
	//通话完毕，挂电话
	public void hangup();
}

IPhone这个接口可不是只有一个职责，它包含了两个职责：一个是协议管理，一个是数据传送。dial()和hangup()两个方法实现的是协议管理，分别负责拨号接通和挂机；chat()实现的是数据的传送，把我们说的话转换成模拟信号或数字信号传递到对方，然后再把对方传递过来的信号还原成我们听得懂的语言，我们可以这样考虑这个问题，协议接通的变化会引起这个接口或实现类的变化吗？会的！那数据传送（想想看，电话不仅仅可以通话，还可以上网）的变化会引起这个接口或实现类的变化吗？会的！那就很简单了，这里有两个原因都引起了类的变化。这两个职责会相互影响吗？电话拨号，我只要能接通就成，甭管是电信的还是网通的协议；电话连接后还关心传递的是什么数据吗？通过这样的分析，我们发现类图上的IPhone接口包含了两个职责，而且这两个职责的变化不相互影响，那就考虑拆分成两个接口：

//其中一个负责拨\打电话
public interface IConnectionManger{
	//拨通电话
	public void dial(String phoneNumber);
	//通话完毕，挂电话
	public void hangup();
}

//另一个负责数据传输
public interface IDataTransfer{
	// 传输信息
	public void DataTransfer(IConnectionManger cm)
}

这样的设计才是完美的，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了呀，是的，但是别忘记了我们是面向接口编程，我们对外公布的是接口而不是实现类。而且，如果真要实现类的单一职责，这个就必须使用上面的组合模式了，这会引起类间耦合过重、类的数量增加等问题，人为地增加了设计的复杂性。

通过上面的例子，我们来总结一下单一职责原则有什么好处：

● 类的复杂性降低，实现什么职责都有清晰明确的定义；

● 可读性提高，复杂性降低，那当然可读性提高了；

● 可维护性提高，可读性提高，那当然更容易维护了；

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

2.里氏替换原则

什么是里氏替换原则？

首先Java是单继承规则，即一个子类只能使用extends 继承一个父类（亲爹只有一个原则），这样是不是比较符合原理。那什么是氏替换原则？它有两种定义：

● 第一种定义，也是最正宗的定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。）

● 第二种定义：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（所有引用基类的地方必须能透明地使用其子类的对象。）

通俗一些讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

最佳实例

下面我们来实现一个士兵打枪杀敌的需求，我们该怎么做呢？

//1.枪支的抽象类
public abstract class AbstractGun {
     //枪用来干什么的？杀敌！
     public abstract void shoot();
}
//手枪、步枪、机枪的实现类
//1-1 手枪
public class Handgun extends AbstractGun { 
     //手枪的特点是携带方便，射程短
     @Override
     public void shoot() {
             System.out.println("手枪射击...");
     }
}
//1-2 步枪
public class Rifle extends AbstractGun{ 
     //步枪的特点是射程远，威力大
     @Override
     public void shoot(){
             System.out.println("步枪射击...");
     }
}
//1-3 机枪
public class MachineGun extends AbstractGun{   
	@Override 
     public void shoot(){
             System.out.println("机枪扫射...");
     }
}

//有了枪支，还要有能够使用这些枪支的士兵，士兵的实现类：
public class Soldier {
     //定义士兵的枪支
     private AbstractGun gun;
     //给士兵一支枪
     public void setGun(AbstractGun _gun){
             this.gun = _gun; 
     }
     public void killEnemy(){
             System.out.println("士兵开始杀敌人...");
             gun.shoot();
     }
}

//实现场景，现在我们开始让士兵打枪：
public class Client {
     public static void main(String[] args) {
             //产生三毛这个士兵
             Soldier sanMao = new Soldier();
             //给三毛一支枪
             sanMao.setGun(new Rifle());
             sanMao.killEnemy();
     }
}

**有人，有枪，也有场景，运行结果如下所示：**

士兵开始杀敌人...
步枪射击...

那现在有个新需求，仿真枪出现了，那我们来实现一下

//玩具枪
public class ToyGun extends AbstractGun {
     //玩具枪是不能射击的，但是编译器又要求实现这个方法，怎么办？虚构一个呗！
     @Override
     public void shoot() {
             //玩具枪不能射击，这个方法就不实现了
     }
}
//场景类
public class Client {      
     public static void main(String[] args) {
             //产生三毛这个士兵
             Soldier sanMao = new Soldier();
             sanMao.setGun(new ToyGun());
             sanMao.killEnemy();
     }
}

坏了，士兵拿着玩具枪来杀敌人，射不出子弹呀！如果在CS游戏中有这种事情发生，那你就等着被人爆头吧，然后看着自己凄惨地倒地。在这种情况下，我们发现业务调用类已经出现了问题，正常的业务逻辑已经不能运行，那怎么办？好办，有两种解决办法：

● 在Soldier类中增加instanceof的判断，如果是玩具枪，就不用来杀敌人。这个方法可以解决问题，但是你要知道，在程序中，每增加一个类，所有与这个父类有关系的类都必须修改，你觉得可行吗？如果你的产品出现了这个问题，因为修正了这样一个Bug，就要求所有与这个父类有关系的类都增加一个判断，客户非跳起来跟你干架不可！你还想要客户忠诚于你吗？显然，这个方案被否定了。

● ToyGun脱离继承，建立一个独立的父类，为了实现代码复用，可以与AbastractGun建立关联委托关系：
这样，就解决了玩具枪不能杀人的问题。
那到底什么是里氏替换原则呢？？我们继续往下看：
当前又有个新需求，有个狙击手需要用枪，我们来实现一下

// 狙！
public class AUG extends Rifle {   
	 //狙击枪都携带一个精准的望远镜
	     public void zoomOut(){
	             System.out.println("通过望远镜察看敌人...");
	     }
	@Override 
     public void shoot(){
             System.out.println("远程射击~~~");
     }
}

//有狙击枪就有狙击手
public class Snipper {     
     public void killEnemy(AUG aug){
             //首先看看敌人的情况，别杀死敌人，自己也被人干掉
             aug.zoomOut();
             //开始射击
             aug.shoot();
     }
}

根据里氏替换原则，父类出现的地方子类就可以出现，那反过来可以吗，给狙击手一个步枪，额~~~貌似射程达不到啊 。。。。。

覆写或实现父类的方法时输出结果可以被缩小
这是什么意思呢，父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说，要么S和T是同一个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法，天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在里氏替换原则要求下，就是子类的输入参数宽于或等于父类的输入参数，也就是说你写的这个方法是不会被调用的，参考上面讲的前置条件。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！

3.依赖倒置原则

什么是依赖倒置？

你可能会问，依赖 还 TM 倒置，什么鬼东西，我们来看一下官方原版的翻译：
High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

翻译过来，包含三层含义：
● 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
● 抽象不应该依赖细节；
● 细节应该依赖抽象。

最佳实例

下面我们来看一个例子，这是一个老司机开车的列子

//司机源码
public class Driver {      
     //司机的主要职责就是驾驶汽车
     public void drive(Benz benz){
             benz.run();
     }
}
//奔驰车源代码
public class Benz {
     //汽车肯定会跑
     public void run(){
             System.out.println("奔驰汽车开始运行...");
     }
}
//场景类源代码
public class Client {
     public static void main(String[] args) {
             Driver zhangSan = new Driver();
             Benz benz = new Benz();
             //张三开奔驰车
             zhangSan.drive(benz);
     }
}

通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”，我们把这句话移植到技术上就成了“变更才显真功夫”，业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来

//宝马车源代码
public class BMW {
     //宝马车当然也可以开动了
     public void run(){
             System.out.println("宝马汽车开始运行...");
     }
}

宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法呀！(看一下上面的司机开车方法，是不是参数里面的只有奔驰，没法开别的？？？)

下面，为了解决这个问题，我们引入依赖倒置原则：
建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法

//司机接口
public interface IDriver {
     //是司机就应该会驾驶汽车
     public void drive(ICar car);
}

//接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类
//司机类的实现
public class Driver implements IDriver{    
     //司机的主要职责就是驾驶汽车
     public void drive(ICar car){
             car.run();
     }
}

//在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要在高层模块中声明。
//ICar及其两个实现类的实现过程
//汽车接口及两个实现类

public interface ICar {
     //是汽车就应该能跑
     public void run();
}
public class Benz implements ICar{
     //汽车肯定会跑
     public void run(){
             System.out.println("奔驰汽车开始运行...");
     }
}
public class BMW  implements ICar{      
     //宝马车当然也可以开动了
     public void run(){
             System.out.println("宝马汽车开始运行...");
     }
}

//在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用都是抽象，Client的实现过程如下
//业务场景
public class Client {
     public static void main(String[] args) {
             IDriver zhangSan = new Driver();
             ICar benz = new Benz();
             //张三开奔驰车
             zhangSan.drive(benz);
     }
}
//张三驾驶宝马车的实现过程
public class Client {
     public static void main(String[] args) {
             IDriver zhangSan = new Driver();
             ICar bmw = new BMW();
             //张三开奔驰车
             zhangSan.drive(bmw);
     }
}

依赖的三种写法

//1.构造函数传递依赖对象,这个也比较常用
public interface IDriver {
     //是司机就应该会驾驶汽车
     public void drive();
}
public class Driver implements IDriver{
     private ICar car;  
     //构造函数注入
     public Driver(ICar _car){
              this.car = _car;
     }
     //司机的主要职责就是驾驶汽车
     public void drive(){
             this.car.run();
     }
}

//2.Setter方法传递依赖对象

//在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按照这种方式的注入，IDriver和Driver的程序修改

代码清单3-12 Setter依赖注入

public interface IDriver {
     //车辆型号
     public void setCar(ICar car);
     //是司机就应该会驾驶汽车
     public void drive();
}
public class Driver implements IDriver{
     private ICar car;  
     public void setCar(ICar car){
             this.car = car;
     }
     //司机的主要职责就是驾驶汽车
     public void drive(){
             this.car.run();
     }
}

//3.接口声明依赖对象
//在接口的方法中声明依赖对象，3.2节的例子就采用了接口声明依赖的方式，该方法也叫做接口注入。

依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：

● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备

这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

● 变量的表面类型尽量是接口或者是抽象类

很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。

● 任何类都不应该从具体类派生

如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。）

● 尽量不要覆写基类的方法

如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。

● 结合里氏替换原则使用

4.接口隔离原则

什么是接口隔离原则

星探寻找美女~~
定义了一个IPettyGirl接口，声明所有的美女都应该有goodLooking、niceFigure和great-Temperament，然后又定义了一个抽象类AbstractSearcher，其作用就是搜索美女并显示其信息，只要美女都按照这个规范定义，Searcher（星探）就轻松多了

//美女类的实现
美女类

public interface IPettyGirl {
     //要有姣好的面孔
     public void goodLooking();
     //要有好身材
     public void niceFigure();
     //要有气质
     public void greatTemperament();
}

//美女的标准定义完毕，具体的美女实现类
//美女实现类
public class PettyGirl implements IPettyGirl {
     private String name;
     //美女都有名字
     public PettyGirl(String _name){
             this.name=_name;
     }  
     //脸蛋漂亮
     public void goodLooking() {
             System.out.println(this.name + "---脸蛋很漂亮!");
     }
     //气质要好
     public void greatTemperament() {
             System.out.println(this.name + "---气质非常好!");
     }  
     //身材要好
     public void niceFigure() {
             System.out.println(this.name + "---身材非常棒!");
     }
}

//通过三个方法，把对美女的要求都定义出来了，按照这个标准，如花姑娘被排除在美女标准之外了。有美女，就有搜索美女的星探，其具体实现如代码如下
星探抽象类源代码

public abstract class AbstractSearcher {
     protected IPettyGirl pettyGirl;
     public AbstractSearcher(IPettyGirl _pettyGirl){
             this.pettyGirl = _pettyGirl;
     }
     //搜索美女，列出美女信息
     public abstract void show();
}

//星探的实现类就比较简单了，其源代码如代码清单4-4所示。
// 星探类
public class Searcher extends AbstractSearcher{
     public Searcher(IPettyGirl _pettyGirl){
             super(_pettyGirl);
     }
     //展示美女的信息
     public void show(){
             System.out.println("--------美女的信息如下：---------------");
             //展示面容
             super.pettyGirl.goodLooking();
             //展示身材
             super.pettyGirl.niceFigure();
             //展示气质
             super.pettyGirl.greatTemperament();
     }
}
//场景类
public class Client {
     //搜索并展示美女信息
     public static void main(String[] args) {
             //定义一个美女
             IPettyGirl yanYan = new PettyGirl("嫣嫣");
             AbstractSearcher searcher = new Searcher(yanYan);
             searcher.show();
     }
}

星探搜索美女的运行结果如下所示：

--------美女的信息如下：---------------

嫣嫣—脸蛋很漂亮!

嫣嫣—身材非常棒!

嫣嫣—气质非常好!

星探寻找美女的程序开发完毕了，运行结果也正确。我们回头来想想这个程序有没有问题，思考一下IPettyGirl这个接口，这个接口是否做到了最优化设计？答案是没有，还可以对接口进行优化。

我们的审美观点都在改变，美女的定义也在变化。唐朝的杨贵妃如果活在现在这个年代非羞愧而死不可，为什么？胖呀！但是胖并不影响她入选中国四大美女，说明当时的审美观与现在是有差异的。当然，随着时代的发展我们的审美观也在变化，当你发现有一个女孩，脸蛋不怎么样，身材也一般般，但是气质非常好，我相信大部分人都会把这样的女孩叫美女，审美素质提升了，就产生了气质型美女，但是我们的接口却定义了美女必须是三者都具备，按照这个标准，气质型美女就不能算美女，那怎么办？可能你要说了，我重新扩展一个美女类，只实现greatTemperament方法，其他两个方法置空，什么都不写，不就可以了吗？聪明，但是行不通！为什么呢？星探AbstractSearcher依赖的是IPettyGirl接口，它有三个方法，你只实现了两个方法，星探的方法是不是要修改？我们上面的程序打印出来的信息少了两条，还让星探怎么去辨别是不是美女呢？

分析到这里，我们发现接口IPettyGirl的设计是有缺陷的，过于庞大了，容纳了一些可变的因素，根据接口隔离原则，星探AbstractSearcher应该依赖于具有部分特质的女孩子，而我们却把这些特质都封装了起来，放到了一个接口中，封装过度了！问题找到了，我们重新设计一下类图，修改后的类图如图4-2所示。

把原IPettyGirl接口拆分为两个接口，一种是外形美的美女IGoodBodyGirl，这类美女的特点就是脸蛋和身材极棒，超一流，但是没有审美素质，比如随地吐痰，文化程度比较低；另外一种是气质美的美女IGreatTemperamentGirl，谈吐和修养都非常高。我们把一个比较臃肿的接口拆分成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后是要外形美的美女还是气质美的美女都可以轻松地通过PettyGirl定义。

修改后的星探寻找美女类图

最佳实例

//两种类型的美女定义

public interface IGoodBodyGirl {
     //要有姣好的面孔
     public void goodLooking();
     //要有好身材
     public void niceFigure();
}
public interface IGreatTemperamentGirl {
     //要有气质
     public void greatTemperament();
}

//按照脸蛋、身材、气质都具备才算美女，实现类实现两个接口，如代码清单4-7所示。

//最标准的美女

public class PettyGirl implements IGoodBodyGirl,IGreatTemperamentGirl {
     private String name;
     //美女都有名字
     public PettyGirl(String _name){
             this.name=_name;
     }
     //脸蛋漂亮
     public void goodLooking() {
             System.out.println(this.name + "---脸蛋很漂亮!");
     }
     //气质要好
     public void greatTemperament() {
             System.out.println(this.name + "---气质非常好!");
     }
     //身材要好
     public void niceFigure() {
             System.out.println(this.name + "---身材非常棒!");
     }
}

通过这样的重构以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。当然，你可能要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个IGoodBody接口还是要修改的呀，确实是，但是设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。

以上把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则，让星探AbstractSearcher依赖两个专用的接口比依赖一个综合的接口要灵活。接口是我们设计时对外提供的契约，通过分散定义多个接口

5.迪米特法则

什么是迪米特法则

我的知识你知道得越少越好
迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。

1.只和朋友交流
迪米特法则还有一个英文解释是：Only talk to your immediate friends（只与直接的朋友通信。）什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。下面我们将举例说明如何才能做到只与直接的朋友交流。

传说中有这样一个故事，老师想让体育委员确认一下全班女生来齐没有，就对他说：“你去把全班女生清一下。”体育委员没听清楚，就问道：“呀，……那亲哪个？”老师无语了，我们来看这个笑话怎么用程序来实现，类图如图5-1所示。

图5-1 老师要求清点女生类图

Teacher类的commond方法负责发送命令给体育会员，命令他清点女生，其实现过程如代码清单5-1所示。

代码清单5-1 老师类

public class Teacher {     
     //老师对学生发布命令，清一下女生
     public void commond(GroupLeader groupLeader){
             List listGirls = new ArrayList();
             //初始化女生
             for(int i=0;i<20;i++){
                     listGirls.add(new Girl());
             }
             //告诉体育委员开始执行清查任务
             groupLeader.countGirls(listGirls);
     }
}

老师只有一个方法commond，先定义出所有的女生，然后发布命令给体育委员，去清点一下女生的数量。体育委员GroupLeader的实现过程如代码清单5-2所示。

代码清单5-2 体育委员类实现过程

public class GroupLeader { 
     //清查女生数量
     public void countGirls(List listGirls){
             System.out.println("女生数量是："+listGirls.size());
     }
}

老师类和体育委员类都对女生类产生依赖，而且女生类不需要执行任何动作，因此定义一个空类，其实现过程如代码清单5-3所示。

代码清单5-3 女生类

public class Girl {
}

故事中的三个角色都已经有了，再定义一个场景类来描述这个故事，其实现过程如代码清单5-4所示。

代码清单5-4 场景类

public class Client {
     public static void main(String[] args) {
             Teacher teacher= new Teacher();            
             //老师发布命令
             teacher.commond(new GroupLeader());
     }
}

运行结果如下所示：

女生数量是：20

体育委员按照老师的要求对女生进行了清点，并得出了数量。我们回过头来思考一下这个程序有什么问题，首先确定Teacher类有几个朋友类，它仅有一个朋友类——GroupLeader。为什么Girl不是朋友类呢？Teacher也对它产生了依赖关系呀！朋友类的定义是这样的：出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类，而Girl这个类就是出现在commond方法体内，因此不属于Teacher类的朋友类。迪米特法则告诉我们一个类只和朋友类交流，但是我们刚刚定义的commond方法却与Girl类有了交流，声明了一个List动态数组，也就是与一个陌生的类Girl有了交流，这样就破坏了Teacher的健壮性。方法是类的一个行为，类竟然不知道自己的行为与其他类产生依赖关系，这是不允许的，严重违反了迪米特法则。

问题已经发现，我们修改一下程序，将类图稍作修改，如图5-2所示。

图5-2 修改后的类图

在类图中去掉Teacher对Girl类的依赖关系，修改后的Teacher类如代码清单5-5所示。

代码清单5-5 修改后的老师类

public class Teacher {
     //老师对学生发布命令，清一下女生
     public void commond(GroupLeader groupLeader){
             //告诉体育委员开始执行清查任务
             groupLeader.countGirls();
     }
}

修改后的GroupLeader类如代码清代5-6所示。

代码清单5-6 修改后的体育委员类

public class GroupLeader {
     private List listGirls;
     //传递全班的女生进来
     public GroupLeader(List _listGirls){
             this.listGirls = _listGirls;
     }  
     //清查女生数量
     public void countGirls(){
             System.out.println("女生数量是："+this.listGirls.size());
     }
}

在GroupLeader类中定义了一个构造函数，通过构造函数传递了依赖关系。同时，对场景类也进行了一些修改，如代码清单5-7所示。

代码清单5-7 修改后的场景类

public class Client {
     public static void main(String[] args) {
             //产生一个女生群体
             List listGirls = new ArrayList();
             //初始化女生
             for(int i=0;i<20;i++){
                     listGirls.add(new Girl());
             }                  
             Teacher teacher= new Teacher();            
             //老师发布命令
             teacher.commond(new GroupLeader(listGirls));
     }  
}

对程序进行了简单的修改，把Teacher中对List的初始化移动到了场景类中，同时在GroupLeader中增加了对Girl的注入，避开了Teacher类对陌生类Girl的访问，降低了系统间的耦合，提高了系统的健壮性。

注意　一个类只和朋友交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。

2.朋友间也是有距离的
人和人之间是有距离的，太远关系逐渐疏远，最终形同陌路；太近就相互刺伤。对朋友关系描述最贴切的故事就是：两只刺猬取暖，太远取不到暖，太近刺伤了对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。

我们在安装软件的时候，经常会有一个导向动作，第一步是确认是否安装，第二步确认License，再然后选择安装目录……这是一个典型的顺序执行动作，具体到程序中就是：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再来看是否可以调用第三个方法，或者第四个方法，等等，其类图如图5-3所示。

图5-3 软件安装过程类图

很简单的类图，实现软件安装的过程，其中first方法定义第一步做什么，second方法定义第二步做什么，third方法定义第三步做什么，其实现过程如代码清单5-8所示。

代码清单5-8 导向类

public class Wizard {
     private Random rand = new Random(System.currentTimeMillis());
     //第一步
     public int first(){
             System.out.println("执行第一个方法...");
             return rand.nextInt(100);
     }  
     //第二步
     public int second(){
             System.out.println("执行第二个方法...");
             return rand.nextInt(100);
     }  
     //第三个方法
     public int third(){
             System.out.println("执行第三个方法...");
             return rand.nextInt(100);
     }
}

在Wizard类中分别定义了三个步骤方法，每个步骤中都有相关的业务逻辑完成指定的任务，我们使用一个随机函数来代替业务执行的返回值。软件安装InstallSoftware类如代码清单5-9所示。

代码清单5-9 InstallSoftware类

public class InstallSoftware {     
     public void installWizard(Wizard wizard){
             int first = wizard.first();  
             //根据first返回的结果，看是否需要执行second
             if(first>50){
                      int second = wizard.second();
                      if(second>50){
                                int third = wizard.third();
                                if(third >50){
                                          wizard.first();
                      }
                 }
            }           
     }
}

根据每个方法执行的结果决定是否继续执行下一个方法，模拟人工的选择操作。场景类如代码清单5-10所示。

代码清单5-10 场景类

public class Client {      
     public static void main(String[] args) {
             InstallSoftware invoker = new InstallSoftware();
             invoker.installWizard(new Wizard());
     }
}

以上程序很简单，运行结果和随机数有关，每次的执行结果都不相同，需要读者自己运行并查看结果。程序虽然简单，但是隐藏的问题可不简单，思考一下程序有什么问题。Wizard类把太多的方法暴露给InstallSoftware类，两者的朋友关系太亲密了，耦合关系变得异常牢固。如果要将Wizard类中的first方法返回值的类型由int改为boolean，就需要修改InstallSoftware类，从而把修改变更的风险扩散开了。因此，这样的耦合是极度不合适的，我们需要对设计进行重构，重构后的类图如图5-4所示。

图5-4 重构后的软件安装过程类图

在Wizard类中增加一个installWizard方法，对安装过程进行封装，同时把原有的三个public方法修改为private方法，如代码清单5-11所示。

代码清单5-11 修改后的导向类实现过程

public class Wizard {
     private Random rand = new Random(System.currentTimeMillis());
     //第一步
     private int first(){
             System.out.println("执行第一个方法...");
             return rand.nextInt(100);
     }  
     //第二步
     private int second(){
             System.out.println("执行第二个方法...");
             return rand.nextInt(100);
     }  
     //第三个方法
     private int third(){
             System.out.println("执行第三个方法...");
             return rand.nextInt(100);
     }  
     //软件安装过程   
     public void installWizard(){               
             int first = this.first();  
             //根据first返回的结果，看是否需要执行second
             if(first>50){
                      int second = this.second();
                      if(second>50){
                                int third = this.third();
                                if(third >50){
                                          this.first();
                                }
                      }
                 }              
     }
}

将三个步骤的访问权限修改为private，同时把InstallSoftware中的方法installWizad移动到Wizard方法中。通过这样的重构后，Wizard类就只对外公布了一个public方法，即使要修改first方法的返回值，影响的也仅仅只是Wizard本身，其他类不受影响，这显示了类的高内聚特性。

对InstallSoftware类进行少量的修改，如代码清单5-12所示。

//代码清单5-12 修改后的InstallSoftware类

public class InstallSoftware {
     public void installWizard(Wizard wizard){
             //直接调用
             wizard.installWizard();
     }
}

场景类Client没有任何改变，如代码清单5-10所示。通过进行重构，类间的耦合关系变弱了，结构也清晰了，变更引起的风险也变小了。

一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。

注意　迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

3.是自己的就是自己的
在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

4.谨慎使用Serializable
在实际应用中，这个问题是很少出现的，即使出现也会立即被发现并得到解决。是怎么回事呢？举个例子来说，在一个项目中使用RMI（Remote Method Invocation，远程方法调用）方式传递一个VO（Value Object，值对象），这个对象就必须实现Serializable接口（仅仅是一个标志性接口，不需要实现具体的方法），也就是把需要网络传输的对象进行序列化，否则就会出现NotSerializableException异常。突然有一天，客户端的VO修改了一个属性的访问权限，从private变更为public，访问权限扩大了，如果服务器上没有做出相应的变更，就会报序列化失败，就这么简单。但是这个问题的产生应该属于项目管理范畴，一个类或接口在客户端已经变更了，而服务器端却没有同步更新，难道不是项目管理的失职吗？

最佳实践

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。

不知道大家有没有听过这样一个理论：“任何两个素不相识的人中间最多只隔着6个人，即只通过6个人就可以将他们联系在一起”，这就是著名的“六度分隔理论”。如果将这个理论应用到我们的项目中，也就是说，我和我要调用的类之间最多有6次传递。呵呵，这只能让大家当个乐子来看，在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法进行重构了，为什么是两次以上呢？因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的外在因素决定，跳转次数越多，系统越复杂，维护就越困难，所以只要跳转不超过两次都是可以忍受的，这需要具体问题具体分析。

迪米特法则要求类间解耦，但解耦是有限度的，除非是计算机的最小单元——二进制的0和1。那才是完全解耦，在实际的项目中，需要适度地考虑这个原则，别为了套用原则而做项目。原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时反复度量，不遵循是不对的，严格执行就是“过犹不及”。

6.开闭原则

什么是开闭原则

总结起来就一句话：软件实体应该对扩展开放，对修改关闭

那什么又是软件实体呢？软件实体包括以下几个部分：

● 项目或软件产品中按照一定的逻辑规则划分的模块。

● 抽象和类。

● 方法。

最佳实例

目前有个场景是这样的
书店需要销售图书，然后有了如下的设计：

代码清单6-1 书籍接口

public interface IBook {   
     //书籍有名称
     public String getName();
     //书籍有售价
     public int getPrice();
     //书籍有作者
     public String getAuthor();
}

代码清单6-2 小说类

public class NovelBook implements IBook {
     //书籍名称
     private String name;       
     //书籍的价格
     private int price; 
     //书籍的作者
     private String author;             
     //通过构造函数传递书籍数据
     public NovelBook(String _name,int _price,String _author){
this.name = _name;
             this.price = _price;
             this.author = _author;
     }  
     //获得作者是谁
     public String getAuthor() {
             return this.author;
     }
     //书籍叫什么名字
     public String getName() {
             return this.name;
     }
     //获得书籍的价格
     public int getPrice() {
             return this.price;
     }
}

注意　我们把价格定义为int类型并不是错误，在非金融类项目中对货币处理时，一般取2位精度，通常的设计方法是在运算过程中扩大100倍，在需要展示时再缩小100倍，减少精度带来的误差。

书店售书的过程如代码清单6-3所示。

代码清单6-3 书店售书类

public class BookStore {
     private final static ArrayList bookList = new ArrayList();
     //static静态模块初始化数据，实际项目中一般是由持久层完成
     static{
             bookList.add(new NovelBook("天龙八部",3200,"金庸"));
             bookList.add(new NovelBook("巴黎圣母院",5600,"雨果"));
             bookList.add(new NovelBook("悲惨世界",3500,"雨果"));
             bookList.add(new NovelBook("金瓶梅",4300,"兰陵笑笑生"));
     }
     //模拟书店买书
     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)+"元");
             }
     }
}

在BookStore中声明了一个静态模块，实现了数据的初始化，这部分应该是从持久层产生的，由持久层框架进行管理，运行结果如下：

-----------------书店卖出去的书籍记录如下：--------------

书籍名称：天龙八部　　书籍作者：金庸　　　　书籍价格：￥25.60元

书籍名称：巴黎圣母院　书籍作者：雨果　　　　书籍价格：￥50.40元

书籍名称：悲惨世界　　书籍作者：雨果　　　　书籍价格：￥28.00元

书籍名称：金瓶梅 　　　书籍作者：兰陵笑笑生　书籍价格：￥38.70元

项目投产了，书籍正常销售出去，书店也赢利了。从2008年开始，全球经济开始下滑，对零售业影响比较大，书店为了生存开始打折销售：所有40元以上的书籍9折销售，其他的8折销售。对已经投产的项目来说，这就是一个变化，我们应该如何应对这样一个需求变化？我们直接使用开闭原则的方式来处理，看看与以往我们平时应对需求变更的方式有何不同吧：

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

图6-3 增加业务品种后的书店售书类图

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

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

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

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

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

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 书店销售计算机书籍

public class BookStore {
     private final static ArrayList bookList = new ArrayList();
     //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)+"元");
             }
     }
}

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

--------------------书店卖出去的书籍记录如下：---------------------

书籍名称：天龙八部　　　　书籍作者：金庸　　　　　书籍价格：￥32.00元

书籍名称：巴黎圣母院　　　书籍作者：雨果　　　　　书籍价格：￥56.00元

书籍名称：悲惨世界　　　　书籍作者：雨果　　　　　书籍价格：￥35.00元

书籍名称：金瓶梅　　　　　书籍作者：兰陵笑笑生　　书籍价格：￥43.00元

书籍名称：Think in Java　　　书籍作者：Bruce Eckel　　　书籍价格：￥43.00元

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

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

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

private final static ArrayList bookList = new ArrayList();

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

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

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

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

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

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

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

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

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

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

总结

软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的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，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

● 项目规章非常重要

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

● 预知变化

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

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