ahh，这个面向对象编程六大原则下篇，我是时隔好久才发出来了的，没办法，人太懒了，emmmmm，一直没来得及写。

回顾上篇

在上篇中我们学习了六大原则中的：对象单一职责、里式替换原则、迪米特法则、开闭原则

对象单一职责：我们设计创建的对象，须职责明确，比如学生类。里面相关的属性和方法都必须是学生的，不能出现教师或者课程相关的内容。这里的类可以是模块（比如这个文件夹下面放的是跟动态配置相关的）、类库（比如这个类库是整个项目的公共方法）、程序集，而不单单指类（Class）。

1、特点：在项目中最为常见。比如分层：仓储接口层，仓储实现层，服务接口层，服务实现层等等。

2、好处：每个类（对象或模块）都包含着自己所特定的相关的（比如属性、方法）。比如仓储接口模块下，放置的都是各个对象相关的仓储接口，里面定义的是各个设计的类相关的方法，方便查找维护。

里式替换原则：子类能够完全替代父类，反之则不行。通常用于实现接口时运用。

1、好处：因为子类能够完全替代基（父）类，那么这样父类就拥有很多子类，在后续的程序扩展中就很容易进行扩展，程序完全不需要进行修改即可进行扩展。比如IA的实现为A，因为项目需求变更，现在需要新的实现，直接在容器注入处更换接口即可（如使用autofac程序集注入，直接注释掉原A的继承即可）

2、也是侧面提醒我们在开发项目当中尽量面向接口编程，方便后续扩展。

迪米特法则和开闭原则：

迪米特法则也叫最小原则，或者说最小耦合。通常在设计程序或开发程序的时候，尽量要高内聚，低耦合。当两个类进行交互的时候，会产生依赖。而迪米特法则就是建议这种依赖越少越好。

就像构造函数注入父类对象时一样，当需要依赖某个对象时，并不在意其内部是怎么实现的，而是在容器中注入相应的实现，既符合里式替换原则，又起到了解耦的作用。

开闭原则：开放扩展，封闭修改。当项目需求发生变更时，要尽可能的不去对原有的代码进行修改，而在原有的基础上进行扩展。（当然是尽可能的去扩展，而不是修改，有时候却很难做到）

六大原则（下）

这一篇我们将学习依赖倒置原则和接口隔离原则。

依赖倒置原则：上层（高层）调用者，不应该依赖于下层细节对象，两者都应该依赖抽象（抽象/接口）。也就是说抽象不应该依赖于细节，而细节应该依赖于抽象。

基于细节去编程，我们必须要求细节去全部完成，才能调用其中的方法。而依赖接口去编程，则不必去考虑接口的实现细节即可调用。使用接口或抽象类的目的是指定好规范，而不涉及到任何具体的操作，把展现细节的任务交给他们的实现类来完成。

终极一班有个汪大东，想要学习C#，于是买了本《C#从入门到入土》进行学习。

学完了，过了段时间，又买了本Mysql学习，于是：

在之后的学习当中，会发现代码越来越臃肿，汪大东的方法无限延长，但都有共性。因为汪大东模块是一个高级模块，依赖了众多的书籍。每当学习一本书，就需要添加一个方法。

这个时候，就体现出依赖于接口的好处了，将共性的方法提取出来，利用里式替换，从而解决了依赖细节编程的问题：代码重复臃肿，维护不便！下面改动一下代码：

依赖倒置特点：

高层模块不应该依赖于低层模块，两者都应该依赖于抽象/接口。

抽象不应该依赖于细节，细节应该依赖于抽象。

依赖倒置的中心思想是面向接口编程。

使用接口或者抽象，制定好规范，而不设计任何具体的操作，把展现细节的任务交予其他的实现类来完成。

如果有复用的属性，使用抽象类，没有复用的属性，直接使用接口；能用接口的，最好不要使用继承。

接口隔离原则：

一个对象和另外一个对象交互的过程中，依赖的内容最小。也就是说在接口设计的时候，在遵循对象单一职责的情况下，尽量减少接口的内容。减少的原则，就是考虑到有的对象可能用不到某些接口，如果我们把接口的行为全部封装到一个接口当中，你就会发现,用不到某些接口的对象，就会出现接口“污染”。

大接口容易导致接口污染，小接口，按需实现，非常灵活（接口可多继承）。使用要求：接口分离要适当，不要过多。

OOP六大原则总结：

单一职责：对象设计要求独立，不能设计万能对象。

开闭原则：对象修改最小化。

里式替换：程序扩展中抽象被具体可以替换（接口、父类、可以被实现类对象、子类替换对象）

迪米特：高内聚，低耦合。尽量不要依赖细节。

依赖倒置：面向抽象编程。也就是参数传递，或者返回值，可以使用父类类型或者接口类型。从广义上讲：基于接口编程，提前设计好接口框架。

接口隔离：接口设计大小要适中。过大导致污染，过小，导致调用麻烦。

以上为OOP面向对象的六大原则，也就是我们要遵循的一系列的规范、要求、理念。虽然高度概括，理论性较强，乏味无趣，但是根据这些原则我们可以直接用于实践，后续学习一系列设计模式等，都是在这些基础上实现的。好了今天的学习到这里结束，有想法和意见欢迎交流。