@[toc]
单一职责原则
单一职责原则的定义
单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。
SRP的原话解释是：There should never be more than one reason for a class to change.
最佳实践
单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项日而异，因坏境而异。
对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。所以对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
里氏替换原则
里氏替换原则的定义
什么是里氏替换原则呢？它有两种定义：
第一种定义，也是最正宗的定义：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. （所有引用基类的地方必须能透明地使用其子类的对象。）
第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
最佳实践
里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含了4层含义。
- 子类必须完全实现父类的方法
- 子类可以有自己的个性
- 覆盖或实现父类的方法时输入参数可以被放大
- 覆写或实现父类的方法时输出结果可以被缩小
在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀委屈了点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离—缺乏类替换的标准。
依赖倒置原则
依赖倒置原则的定义
依赖倒置原则(Dependence Inversion Principle, DIP)这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思？依赖倒置原则的原始定义是：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.
翻译过来，包含三层含义：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
- 抽象不应该依赖细节；
- 细节应该依赖抽象。
依赖倒置原则在Java语言中的表现就是：
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
- 接口或抽象类不依赖于实现类；
- 实现类依赖接口或抽象类。
最佳实践
依赖是可以传递的，只要做到抽象依赖，即使是多层的依赖传递也无所畏惧！对象的依赖关系有三种方式来传递，如下所示。
- 构造函数传递依赖对象在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入。
- Setter方法传递依赖对象在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入。
- 接口声明依赖对象在接口的方法中声明依赖对象，该方法也叫做接口注入。
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置
- 变量的表面类型尽量是接口或者是抽象类。很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供的一个规范。
- 任何类都不应该从具体类派生。如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。
- 尽量不要覆写基基类的方法如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
结合里氏替换原则，我们可以得出这样一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
接口隔离原则
接口隔离的定义
接口分为两种：
实例接口 (Object Interface)，在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口。
类接口(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 interface. （类间的依赖关系应该建立在最小的接口上。）
我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
最佳实践
接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个来衡量：
- 一个接口只服务于一个子模块或业务逻辑；
- 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
- 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；
- 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设计就出自你的手中！
迪米特法则
迪米特法则的定义
迪米特法则的定义：迪米特法则(Law of Demeter, LoD)，也称为最少知识原则(Least Knowledge Principle,LKP)，虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
最佳实践
迪米特法则对类的低耦合提出了明确的要求，其包含以下4层含义。
- 只和朋友交流
迪米特法则还有一个英文解释是：Only talk to your immediate friends （只与直接的朋友通信。）什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合、依赖等。 一个类只和朋友交流，不与陌生类交流，不要出现getA ( ).getB ( ).getC ( ).getD（）这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。
- 朋友间也是有距离的
一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public 方法和属性，是否可以修改为private、package-private （包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。
- 是自己的就是自己的
在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
- 谨慎使用Serializable
突然有一天，客户端的VO修改了一个属性的访问权限，从private变成public，如果服务器上没有做出相应的变更，就会报序列化失败，就这么简单。但是这个问题的产生应该属于项目管理范畴，一个接口在客户端已经变更了，而服务器端却没有同步更新，难道不是项目管理的失职吗？
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了难度。读者在采用迪米特法则时需要反复权衡，既做到让结构清晰，又做到高内聚低耦合。在实际应用中，如果一个类跳转两次以上才能访问到另一个类，就需要想办法行重构了，为什么是两次以上呢？因为一个系统的成功不仅仅是一个标准或是原则就能够决定的，有非常多的外在因素决定，跳转次数越多，系统越复杂，维护就越困难，所以只要跳转超过两次都是可以忍受的，这需要具体问题具体分析。
迪米特法则要求类间解耦，但解耦是有限度的，除非是计算机的最小单元—二进制的0和1。那才是完全解耩，在实际的项目中，需要适度地考虑这个原则，原则只是供参考，如果违背了这个原则，项目也未必会失败，这就需要大家在采用原则时应复度量，不遵循是不对的，严格执行就是“过犹不及”
开闭原则
开闭原则的定义
开闭原则是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统，先来看开闭原则的定义：software entities like classes, modules and functions should be open for extension but closed for modifications. （一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。）
一个软件产品只要在生命期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计计进行约束的一个原则。
最佳实践
开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，开闭原则也是一个口号，那我们怎么把这个口号应用到实际工作中呢？
- 抽象约束
抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。 因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义： 第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法； 第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类； 第三，抽象层尽量保持稳定，一旦确定即不允许修改。
- 元数据(metadata)控制模块行为
编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？答案是尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。举个其中达到极致的就是控制反转(Inversion of Control)，使用最多的就是Spring容器。
- 制定项目章程
在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。
- 封装变化
对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二，将同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化(protected variations)，找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行封装的。
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我门要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化，我把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID (solid，稳定的），其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。
- 开闭原则也只是一个原则
开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但是遵循这6大设计原则基本上可以应对大多数变化。
- 项目规章非常重要
如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定，优秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提高技术或员水平，等等。
- 预知变化
在实践中过程中，架构师或项目经理一日发现有发恋化的可能，或者变化曾经发生过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求，还要适应可能发生的变化，这才是一个优良的架构。
