设计模式的几大原则

前言

设计模式原则，其实就是程序员在编程时，应当遵守的原则， 也是各种设计模式的基础(即： 设计模式为什么这样设计的依据)
设计模式常用的六大原则有:
①单一职责原则
②里氏替换原则
③依赖倒转(倒置)原则
④接口隔离原则
⑤迪米特法则
⑥开闭原则

一.单一职责原则

1.1 定义

什么是单一职责原则呢?只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型(Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离)，确实是一个很好的解决办法。
我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构)、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图.

这个类是不是看起来很简单,设计起来是不是也不是很复杂.
太可是Easy的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误!
这个接口确实设计得一团糟，应该把用户的信息抽取成一个BO ( Bussiness Object,业务对象)，把行为抽取成一个Biz (Business Logic，业务逻辑)，按照这个思路对类图进行修正，如图所示:

这里把原来的接口重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息﹔IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀!别着急，我们先来看一看分拆成两个接口怎么使用,具体的使用方法也很简单,我们需要使用的的话,就直接实现某个类就行了.

其实这里的进一步分解的类图就是如下所示

以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一职责原则呢?单一职责原则的定义是:应该有且仅有一个原因引起类的变更。

1.2 例子

如果大家对单一职责原则还是没有理解的话,我决定进一步举一个实际的例子.进一步说明

我们来用一个电话的例子来说明,这个例子很好理解，电话这玩意，是现代人都离不了，电话通话的时候有4个过程发生:拨号、通话、回应、挂机，那我们写一个接口，其类图如图1-4所示。

代码过程:

看到这里大家来思考一下,上面这个例子是否满足单一职责原则,大家估计是觉得满足的,我们来回忆一下什么是单一职责原则,一个接口或类只有一个原因引起变化，也就是一个接口或类只有一个职责，它就负责一件事情,看看上面的接口只负责一件事情吗?是只有一个原因引起变化吗?好像不是!
IPhone这个接口可不是只有一个职责，它包含了两个职责:一个是协议管理，一个是数据传送。dial()和hangup()两个方法实现的是协议管理，分别负责拨号接通和挂机，chat()实现的是数据的传送，把我们说的话转换成模拟信号或数字信号传递到对方，然后再把对方传递过来的信号还原成我们听得懂的语言。
我们可以这样考虑这个问题，协议接通的变化会引起这个接口或实现类的变化吗?会的!
那数据传送（想想看，电话不仅仅可以通话，还可以上网）的变化会引起这个接口或实现类的变化吗?会的!
那就很简单了，这里有两个原因都引起了类的变化。这两个职责会相互影响吗?电话拨号，我只要能接通就成，甭管是电信的还是网通的协议﹔电话连接后还关心传递的是什么数据吗?通过这样的分析，我们发现类图上的IPhone接口包含了两个职责，而且这两个职责的变化不相互影响，那就考虑拆分成两个接口，其类图如图

这个类图看上去有点复杂了，完全满足了单一职责原则的要求，每个接口职责分明，结构清晰，但是我相信你在设计的时候肯定不会采用这种方式，一个手机类要把ConnectionManager和DataTransfer组合在一块才能使用。组合是一种强耦合关系，你和我都有共同的生命期，这样的强耦合关系还不如使用接口实现的方式呢，而且还增加了类的复杂性，多了两个类。经过这样的思考后，我们再修改一下类图，如图所示

1.3 总结

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

• 类的复杂性降低，实现什么职责都有清晰明确的定义﹔
• 可读性提高，复杂性降低，那当然可读性提高了
• 可维护性提高，可读性提高，那当然更容易维护了﹔
• 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助.

二.里氏替换原则

2.1 定义

在介绍这个原则之前,我们要介绍面向对象的又一个机制,就是继承机制,这是面向对象的又一个优秀机制,它有哪些特点呢?

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性;
• 提高代码的重用性;
• 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同,
• 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的;
• 提高产品或项目的开放性。

自然界的所有事物都是优点和缺点并存的，即使是鸡蛋，有时候也能挑出骨头来，继承的缺点如下:

• 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法;
• 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束.
• 增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果-—─—大片的代码需要重构。

看了继承的机制之后,我们来看看里氏替换原则的定义:
第一种定义，也是最正宗的定义:If for each object o1 of type s there is an object o2 oftype T such that for all programs P defined in terms of T, the behavior of P is unchangedwhen 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 useobjects of derived classes without knowing it.(所有引用基类的地方必须能透明地使用其子类的对象。)
第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了，有子类出现的地方，父类未必就能适应。

1.2 例子

大家玩过射击类游戏吗?我们现在开始以射击类游戏的枪这个类来作为例子,我们来描述一下里面用到的枪.

枪的主要职责是射击，如何射击在各个具体的子类中定义，手枪是单发射程比较近，步*威力大射程远，机枪用于扫射。在土兵类中定义了一个方法killEnemy，使用枪来杀敌人，具体使用什么枪来杀敌人，调用的时候才知道，AbstractGun类的源程序如代码清单,如下图所示:

手枪,步枪,机枪的实现类如下所示:

士兵的实现类

场景类

在这个程序中，我们给三毛这个士兵一把步枪，然后就开始杀敌了。如果三毛要使用机枪,当然也可以，直接把sanMao.killEnemy (new Rifle( ))修改为sanMao.killEnemy (newMachineGun ( ))即可，在编写程序时Solider士兵类根本就不用知道是哪个型号的枪.传入相关的类即可.
那假如我们此刻要增加需求呢?要加入一个玩具枪呢?此时我们怎么做呢?
我们做法是创建一个类ToyGun，然后继承于AbstractGun类,

首先我们想，玩具枪是不能用来射击的，杀不死人的，这个不应该写在shoot方法中。新增加的ToyGun的源代码如代码清单如下所示:

这个时候,我们的业务类的代码如下:

修改了粗体部分，把玩具枪传递给三毛用来杀敌，但是玩具枪怎么杀敌呢?而且代码执行之后没法射出子弹,其实我们这里业务已经出现了问题,正常运行之后,业务代码已经不能正常执行.我提供俩种解决方案,大家可以看一下:
第一种解决方案:在Soldier类中增加instanceof的判断，如果是玩具枪，就不用来杀敌人。这个方法可以解决问题，但是你要知道，在程序中，每增加一个类，所有与这个父类有关系的类都必须修改，你觉得可行吗?如果你的产品出现了这个问题，因为修正了这样一个Bug，就要求所有与这个父类有关系的类都增加一-个判断，客户非跳起来跟你干架不可!你还想要客户忠诚你吗?显然，这个方案被否定了。

第二种解决方案:ToyGun脱离继承，建立一个独立的父类，为了实现代码复用，可以与AbastractGun建立关联委托关系，如图所示:

在Java的基础知识中都会讲到继承，Java的三大特征嘛，继承、封装、多态。继承就是告诉你拥有父类的方法和属性，然后你就可以重写父类的方法。按照继承原则，我们上面的玩具枪继承AbstractGun是绝对没有问题的，玩具枪也是枪嘛，但是在具体应用场景中就要考虑下面这个问题了:子类是否能够完整地实现父类的业务，否则就会出现像上面的拿枪杀敌人时却发现是把玩具枪的笑话。
注意︰如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

1.3 总结

在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀—一委屈了点，把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离——缺乏类替换的标准。

三.依赖倒置原则

3.1 定义

依赖倒置原则（Dependence Inversion Principle，DIP）这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思?依赖倒置原则的原始定义是:
High level modules should not depend upon low level modules.Both should depend uponabstractions. Abstractions should not depend upon details.Details should depend uponabstractions.
具体的解释:
高层模块不应该依赖低层模块，两者都应该依赖其抽象;
抽象不应该依赖细节;
细节应该依赖抽象。

高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象?什么又是细节呢?在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的，细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是:

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的;
• 接口或抽象类不依赖于实现类，
• 实现类依赖接口或抽象类。

3.2例子

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
我们还是来看一个例子,来证明这个原则是否正确.
我们这里引入俩个论题
论题:依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险,提高代码的可读性和可维护性。
反论题:不使用依赖倒置原则也可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
我们现在要证明的就是这个反论题是否成立.
我用一个司机驾驶奔驰车类.来说明,类图如下:

奔驰车可以提供一个方法run，代表车辆运行，代码清单如下:
司机类
奔驰类

业务类

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

宝马车也产生了，但是我们却没有办法让张三开动起来，为什么?张三没有开动宝马车的方法呀!
一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了!在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题:司机类和奔驰车类之间是紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗?还有稳定性，什么是稳定性?固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担!证明到这里，我们已经知道反论题已经部分不成立了。

到这里我们继续证明，“减少并行开发引起的风险”，什么是并行开发的风险?并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。为什么并行开发就有这样的风险呢?一个团队，20个开发人员，各人负责不同的功能模块,不同的功能模块.

甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过!在缺少Benz类的情况下，Driver类能编译吗?更不要说是单元测试了!在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队协作的结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系那然后呢?依赖倒置原则就隆重出场了!
在使用依赖倒置原则之后的类图如下:

建立两个接口:IDriver和ICar，分别定义了司
机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法，其实现过程如代码清单如下:
司机接口

司机类的实现
接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类代码如下:

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

具体的业务场景代码
我们在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象(ICar接口）不依赖BMW和Benz两个实现类（细节)，因此在高层次的模块中应用都是抽象，Client的实现过程

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的表面类型是IDriver，Benz的表面类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释?确实如此，zhangSan的表面类型是IDriver，是一个接口，是抽象的、非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就行,具体的代码细节如下:

在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他底层模块Driver不用做出任何修改.这样就把变更的风险降到最小.

另外还有一个重要的事情,就是我们看看依赖的三种实现是什么?
第一种:构造函数传递依赖

第二种:Setter方法传递依赖

第三种:接口声明传递依赖

3.3总结

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

• 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置变量的
• 表面类型尽量是接口或者是抽象类
  很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。
• 任何类都不应该从具体类派生
  如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是负责项目维护的同志，基本上可以不考虑这个规则，为什么?维护工作基本上都是进行扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必去继承最高的基类呢?（当然这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。)
• 尽量不要覆写基类的方法
  如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
• 结合里氏替换原则使用

讲了这么多，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢?我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑
就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

---

四.接口隔离原则

4.1 定义

在讲接口隔离原则之前,我们得知道什么是接口?接口分为两种.

• 实例接口（Object Interface)，在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口。比如你定义Person这个类，然后使用Person zhangSan = new Person()产生了一个实例，这个实例要遵从的标准就是Person这个类，Person类就是zhangSan的接口。疑惑?看不懂?不要紧，那是因为让Java语言浸染的时间太长了，只要知道从这个角度来看，Java中的类也是一种接口。
• 类接口(Class Interface)，Java中经常使用的interface关键字定义的接口。

主角已经定义清楚了，那什么是隔离呢?它有两种定义，如下所示:
Clients should not be forced to depend upon interfaces that they don’t use.(客户端不应该依赖它不需要的接口。)
The dependency of one class to another one should depend on the smallest possible(类间的依赖关系应该建立在最小的接口上。)

新事物的定义一般都比较难理解，晦涩难懂是正常的。我们把这两个定义剖析一下，先说第一种定义:“客户端不应该依赖它不需要的接口"，那依赖什么?依赖它需要的接口，客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，那就需要对接口进行细化，保证其纯洁性，再看第二种定义:“类间的依赖关系应该建立在最小的接口上"，它要求是最小的接口，也是要求接口细化，接口纯洁，与第一个定义如出一辙，只是一个事物的两种不同描述。
我们可以把这两个定义概括为一句话:建立单一接口，不要建立臃肿庞大的接口再通俗一点讲:接口尽量细化，同时接口中的方法尽量少。看到这里大家有可能要疑惑了，这与单一职责原则不是相同的吗?错，接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。

举个实际的例子,你就明白了
例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问"，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。专门的接口指什么?就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

4.2 例子

我们举例来说明接口隔离原则到底对我们提出了什么要求。现在男生对小姑娘的称呼，使用频率最高的应该是“美女”了吧，你在大街上叫一声:“嗨，美女!”估计10个有8个回头，其中包括那位著名的如花。美女的标准各不相同，首先就需要定义一下什么是美女:首先要面貌好看，其次是身材要窈窕，然后要有气质，当然了，这三者各人的排列顺序不一样，总之要成为一名美女就必须具备:面貌、身材和气质，我们用类图体现一下星探（当然，你也可以把自己想象成星探〉找美女的过程，如图所示:

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

美女实现类

星探抽象类

星探实现类源码

具体业务场景类

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

如何进行优化呢?
我们的审美观点都在改变，美女的定义也在变化。唐朝的杨贵妃如果活在现在这个年代非羞愧而死不可，为什么?胖呀!但是胖并不影响她入选中国四大美女，说明当时的审美观与现在是有差异的。当然，随着时代的发展我们的审美观也在变化，当你发现有一个女孩，脸蛋不怎么样，身材也–般般，但是气质非常好，我相信大部分人都会把这样的女孩叫美女，审美素质提升了，就产生了气质型美女，但是我们的接口却定义了美女必须是三者都具备，按照这个标准，气质型美女就不能算美女，那怎么办?可能你要说了，我重新扩展一个美女类，只实现greatTemperament方法，其他两个方法置空，什么都不写，不就可以了吗?聪明，但是行不通!为什么呢?星探AbstractSearcher依赖的是IPettyGirl接口，它有三个方法，你只实现了两个方法，星探的方法是不是要修改﹖我们上面的程序打印出来的信息少了两条，还让星探怎么去辨别是不是美女呢?
我们分析到这里，我们发现接口IPettyGirl的设计是有缺陷的，过于庞大了，容纳了一些可变的因素，根据接口隔离原则，星探AbstractSearcher应该依赖于具有部分特质的女孩子，而我们却把这些特质都封装了起来，放到了一个接口中，封装过度了!问题找到了，我们重新设计一下

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

按照脸蛋、身材、气质都具备才算美女，实现类实现两个接口，

通过这样的重构以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。当然，你可能要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个IGoodBody接口还是要修改的呀，确实是，但是设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
以上把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则，让星探AbstractSearcher依赖两个专用的接口比依赖一个综合的接口要灵活。接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。

4.3 总结

接口隔离原则是对接口进行规范约束,其中包含四层含义

1. 接口尽量要小
   这是接口隔离原则的核心定义，不出现臃肿的接口 (Fat Interface)，根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
2. 接口要高内聚
   什么是高内聚?高内聚就是提高接口、类、模块的处理能力，减少对外的交互。比如你告诉下属“到奥巴马的办公室偷一个XXX文件”，然后听到下属用坚定的口吻回答你:“是，保证完成任务!”一个月后，你的下属还真的把XXX文件放到你的办公桌上了，这种不讲任何条件、立刻完成任务的行为就是高内聚的表现。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
3. 定制服务
   一个系统或系统内的模块之间必然会有耦合，有耦合就要有相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或单纯的数据交换)，我们设计时就需要为各个访问者（即客户端）定制服务，什么是定制服务﹖定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求:只提供访问者需要的方法.
4. 接口的设计是有限的
   接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个“度”如何来判断呢﹖根据经验和常识判断，没有一个固化或可测量的标准。

五.迪米特法则

5.1 定义

迪米特法则〈（Law of Demeter，LoD)也称为最少知识原则（Least Knowledge Principle,LKP)，虽然名字不同，但描述的是同一个规则:一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

5.2 例子

迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。

1. 只和朋友交流

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

我会用一个例子来说明这其中的奥秘,传说中有这样一个故事，老师想让体育委员确认一下全班女生来齐没有，就对他说:“你去把全班女生清一下。”体育委员没听清楚，就问道:“呀，……那亲哪个?”老师无语了，我们来看这个笑话怎么用程序来实现，类图如下:

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

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

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

具体的业务实现

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

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

体育委员类

修改后的场景类

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

2. 朋友交流是有距离的
   人和人之间是有距离的，太远关系逐渐疏远，最终形同陌路，太近就相互刺伤。对朋友关系描述最贴切的故事就是:两只刺猬取暖，太远取不到暖，太近刺伤了对方，必须保持一个既能取暖又不刺伤对方的距离。迪米特法则就是对这个距离进行描述，即使是朋友类之间也不能无话不说，无所不知。
   我们还是来举个例子吧,大家都安装过软件吧?
   我们在安装软件的时候，经常会有一个导向动作，第一步是确认是否安装，第二步确认License，再然后选择安装目录……这是一个典型的顺序执行动作，具体到程序中就是:调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再来看是否可以调用第三个方法，或者第四个方法，等等.
   这里我们就具体的画一个类图如下:
   软件的安装过程
   
   具体的导向类编码
   在Wizard类中分别定义了三个步骤方法，每个步骤中都有相关的业务逻辑完成指定的任务，我们使用一个随机函数来代替业务执行的返回值。
   
   软件安装InstallSoftware类如代码清单如下:
   
   根据每个方法执行的结果决定是否继续执行下一个方法，模拟人工的选择操作。场景类如下:
   

以上程序很简单，运行结果和随机数有关，每次的执行结果都不相同，需要读者自己运行并查看结果。

程序虽然简单，但是隐藏的问题可不简单，思考一下程序有什么问题。Wizard类把太多的方法暴露给InstallSoftware类，两者的朋友关系太亲密了，耦合关系变得异常牢固。如果要将Wizard类中的first方法返回值的类型由int改为boolean，就需要修改InstallSoftware类，从而把修改变更的风险扩散开了。
因此，这样的耦合是极度不合适的，我们需要对设计进行重构.
重构后的类图入下:

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

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

修改后的InstallSoftware的代码入下:

业务场景类

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

5.3 总结

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。
不知道大家有没有听过这样-一个理论:“任何两个素不相识的人中间最多只隔着6个人，耶只通过6个人就可以将他们联系在一起”，这就是著名的“六度分隔理论”。如果将这个理论应用到我们的项目中，也就是说，我和我要调用的类之间最多有6次传递。呵呵，这只能让大家当个乐子来看，在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法进行重构了，为什么是两次以上呢?因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的外在因素决定，跳转次数越多，系统越复杂，维护就越困难，所以只要跳转不超过两次都是可以忍受的,这需要具体问题具体分析。
迪米特法则要求类间解耦，但解耦是有限度的，除非是计算机的最小单元——二进制的0和1。那才是完全解耦，在实际的项目中，需要适度地考虑这个原则，别为了套用原则而做项目。原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时反复度量，不遵循是不对的，严格执行就是“过犹不及”。

六.开闭原则

6.1 定义

在哲学上，矛盾法则即对立统一的法则，是唯物辩证法的最根本法则。本章要讲的开闭原则是不是也有同样的重要性且具有普遍性呢?确实，开闭原则是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的、灵活的系统，先来看开闭原则的定义:
Software entities like classes,modules and functions should be open for extension but closedfor modifications.(一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。)
初看到这个定义，可能会很迷惑，对扩展开放?开放什么?对修改关闭，怎么关闭?没关系，我会一步一步带领大家解开这些疑惑。
我们做一件事情，或者选择一个方向，一般需要经历三个步骤:What-—–是什么，Why——为什么，How——怎么做（简称3W原则，How取最后一个w)。对于开闭原则，我们也采用这三步来分析，即什么是开闭原则，为什么要使用开闭原则，怎么使用开闭原则。

6.2 例子

开闭原则的定义已经非常明确地告诉我们:软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那什么又是软件实体呢?软实体包括以下几个部分:
1.项目或软件产品中按照一定的逻辑规则划分的模块。
2.抽象和类。
3.方法。
我们举例说明
什么是开闭原则，以书店销售书籍为例，其类图如图所示。

IBook定义了数据的三个属性:名称、价格和作者。小说类NovelBook是一个具体的实现类，是所有小说书籍的总称，BookStore指的是书店，IBook接口如代码清单如下所示:
书籍接口

具体的小说类

书店销售类

项目投产了，书籍正常销售出去，书店也盈利了。从2008年开始，全球经济开始下滑，对零售业影响比较大，书店为了生存开始打折销售:所有40元以上的书籍9折销售，其他的8折销售。对已经投产的项目来说，这就是一个变化，我们应该如何应对这样一个需求变化?有如下几种应对方式:
第一种:修改接口
在IBook上新增加一个方法getOffPrice()，专门用于进行打折处理，所有的实现类实现该方法。但是这样修改的后果就是，实现类NovelBook要修改，BookStore中的main方法也修改，同时IBook作为接口应该是稳定且可靠的，不应该经常发生变化，否则接口作为契约的作用就失去了效能。因此，该方案否定。
第二种:修改实现类
修改NovelBook类中的方法，直接在getPrice()中实现打折处理，好办法，我相信大家在项目中经常使用的就是这样的办法，通过class文件替换的方式可以完成部分业务变化（或是缺陷修复)。该方法在项目有明确的章程（团队内约束）或优良的架构设计时，是一个非常优秀的方法，但是该方法还是有缺陷的。例如采购书籍人
员也是要看价格的，由于该方法已经实现了打折处
理价格，因此采购人员看到的也是打折后的价格，
会因信息不对称而出现决策失误的情况。因此，该
方案也不是一个最优的方案。
第三种:通过扩展实现变化
增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是static静态模块区〉通过OffNovelBook类产生新的对象，完成业务变化对系统的最小化开发。好办法，修改也少，风险也小，修改后的类图如下图所示

打折销售销售的小说类

很简单，仅仅覆写了getPrice方法，通过扩展完成了新增加的业务。书店类BookStore需要依赖子类，代码稍作修改，如代码清单如下所示:

OK，打折销售开发完成了。看到这里，各位可能有想法了:增加了一个OffNoveBook类后，你的业务逻辑还是修改了，你修改了static静态模块区域。这部分确实修改了，该部分属于高层次的模块，是由持久层产生的，在业务规则改变的情况下高层模块必须有部分改变以适应新业务，改变要尽量地少，防止变化风险的扩散。
最后我们来总结一下变化点:
我们一般把变化点分为三个方面
逻辑变化
只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是ab+c，现在需要修改为ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
子模块变化
一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的，刚刚的书籍打折处理就是类似的处理模块,该部分的变化甚至会引起界面的变化。
可视视图变化
可见视图是提供给客户使用的界面，如JSP程序、Swing界面等，该部分的变化一股会引起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太大)。如果仅仅是界面上按钮、文字的重新排布倒是简单，最司空见惯的是业务耦合变化，什么意思呢?一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。
我们再来回顾一下书店销售书籍的程序，首先是我们有一个还算灵活的设计（不灵活是什么样子?BookStore中所有使用到IBook的地方全部修改为实现类，然后再扩展一个ComputerBook书籍，你就知道什么是不灵活了)﹔然后有一个需求变化，我们通过扩展一个子类拥抱了变化，最后把子类投入运行环境中，新逻辑正式投产。通过分析，我们发现并没有修改原有的模块代码，IBook接口没有改变，NovelBook类没有改变，这属于已有的业务代码，我们保持了历史的纯洁性。放弃修改历史的想法吧，一个项目的基本路径应该是这样的:项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性。

6.3 结论

1.开闭原则可以提高复用性
在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。那为什么要复用呢?减少代码量，避免相同的逻辑分散在多个角落，避免日后的维护人员为了修改一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码，然后发出对开发人员“极度失望”的感慨。那怎么才能提高复用率呢?缩小逻辑粒度，直到一个逻辑不可再拆分为止。
2.开闭原则可以提高可维护性
一款软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能要对程序进行扩展，维护人员最乐意做的事情就是扩展一个类，而不是修改一个类，甭管原有的代码写得多么优秀还是多么糟糕，让维护人员读懂原有的代码，然后再修改，是一件很痛苦的事情，不要让他在原有的代码海洋里游弋完毕后再修改，那是对维护人员的一种折磨和摧残。
3.面向对象开发的要求
万物皆对象，我们需要把所有的事物都抽象成对象，然后针对对象进行操作，但是万物皆运动，有运动就有变化，有变化就要有策略去应对，怎么快速应对呢?这就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。