设计模式笔记---6大设计原则

注意：这是个人的学习笔记，针对重点内容进行了摘录，不是具体的学习资料

1、单一职责原则

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。  

例如下图中，用户类包含两种职责，1是用户信息（用户属性），2是用户相关行为，所以应该分成两个接口

UserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。  

有时候为了迎合单一职责，会采用组合的形式去实现一个复杂的功能，但是。组合是一种强耦合关系，你和我都有共同的生命期，这样的强耦合关系还不如使用接口实现的方式呢，而且还增加了类的复杂性，多了两个类。

所以，我们会让一个类实现了两个接口，把两个职责融合在一个类中。（我们是面向接口编程，我们对外公布的是接口而不是实现类）

如果真要实现类的单一职责，这个就必须使用上面的组合模式了，这会引起类间耦合过重、类的数量增加等问题，人为地增加了设计的复杂性。

单一职责适用于接口、类，同时也适用于方法  

下单一职责原则有什么好处：

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

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

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

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修

改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大

的帮助。  

注意　单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

2、里氏替换原则  

所有引用基类的地方必须能透明地使用其子类的对象  

通俗点讲，只要父类能出现的地方子类就可以出现，而且

替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但

是，反过来就不行了，有子类出现的地方，父类未必就能适应。 

里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含了4层含义。

1.子类必须完全实现父类的方法 

//产生三毛这个士兵
Soldier sanMao = new Soldier();
//给三毛一支枪
sanMao.setGun(new Rifle());
sanMao.killEnemy();

这里solder类不需要知道AbstractGun具体是什么类型，在实现类中去set具体的就好了，

注意　在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。  

　       如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。  

2.子类可以有自己的个性 

3.覆盖或实现父类的方法时输入参数可以被放大 

4. 覆写或实现父类的方法时输出结果可以被缩小  

采用里氏替换原则的目的就是增强程序的健壮性  

3、依赖倒置原则  

依赖倒置原则在Java语言中的表现就是：

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

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类。  

更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。  

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。  

注意　设计是否具备稳定性，只要适当地“松松土”，观察“设计的蓝图”是否还可以茁壮地成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。  

注意　在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型，如zhangSan的表面类型是IDriver，实际类型是Driver。  

抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到“言必信，行必果”。  

对象的依赖关系有三种方式来传递

1.构造函数传递依赖对象  

2.Setter方法传递依赖对象  

3.接口声明依赖对象 （叫做接口注入） 

要遵循以下的几个规则：  

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

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

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

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

样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。  

4、接口隔离原则  

接口分为两种：

● 实例接口（Object Interface） 

● 类接口（Class 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.（类间的依赖关系应该建立在最小的接口上。）  

尽量使用多个专门的接口，就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。 

，但是设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。  

接口隔离原则是对接口进行规范约束，其包含以下4层含义：

● 接口要尽量小  

这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度

的，首先就是不能违反单一职责原则，  

根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

● 接口要高内聚

    高内聚就是提高接口、类、模块的处理能力，减少对外的交互  

● 定制服务  

定制服务就是单独为一个个体提供优良的服务。  

有一个要求：只提供访问者需要的方法  

● 接口设计是有限度的  

      这个“度”如何来判断呢？根据经验和常识判断，没有一个固化或可测量的标准。

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。但是，这个原子该怎么划分是设计模式中的一大难题，在实践中可以根据以下几个规则来衡量：

● 一个接口只服务于一个子模块或业务逻辑；

● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；

● 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素 ，环境不同，接口拆分的标准就不同。深入了解业务逻辑

5、迪米特法则  

最少知识原则 ：一个对象应该对其他对象有最少的了解 

其包含以下4层含义。

1. 只和朋友交流  

注意 类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。

2. 朋友间也是有距离的    

注意　迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量  

3. 是自己的就是自己的  

：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。  

4. 谨慎使用Serializable  

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高  

迪米特法则要求类间解耦，但解耦是有限度的  

6、开闭原则  

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭  

其含义是说：一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。  

注意　开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。  

变化归纳为以下三种类型：

● 逻辑变化  

● 子模块变化  

● 可见视图变化  

放弃修改历史的想法吧，一个项目的基本路径应该是这样的：

项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性。  

开闭原则是最基础的一个原则，前五章节介绍的原则都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖  

开闭原则是非常重要的，可通过以下几个方面来理解其重要性。

1. 开闭原则对测试的影响  

2. 开闭原则可以提高复用性 

3. 开闭原则可以提高可维护性 

4. 面向对象开发的要求  

开闭原则是一个非常虚的原则 

1. 抽象约束

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

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

尽量使用元数据来控制程序的行为，减少重复开发。  

3. 制定项目章程 

约定优于配置  

4. 封装变化  

23个设计模式都是从各个不同的角度对变化进行封装的，  

总结：

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

● Single Responsibility Principle：单一职责原则

● Open Closed Principle：开闭原则

● Liskov Substitution Principle：里氏替换原则

● Law of Demeter：迪米特法则

● Interface Segregation Principle：接口隔离原则

● Dependence Inversion Principle：依赖倒置原则