面向对象六大原则
一：单一职责原则，缩写SRP（Single Responsibility Principle）
定义：仅有一个导致类变化的原因。
举个列子
类O，有两个不同的职责P1、P2，修改了P1，可能导致P2也跟着变化。
为了解决以上问题，我们遵照单一职责原则，做如下优化
建立两个类O1、O2，O1负责职责P1的功能，O2负责职责P2的功能。
这样，类O1和O2分别负责不同的职责，即便修改O1，也不会影响O2，同理，修改O2，也不影响O1。
在实际应用中，如何划分一个类，一个函数的职责，每个人都有自己不同的看法，具体情况根据个人经验、业务逻辑、实际需求及后续需求而定。但我们应该遵照一个基本指导原则：
完全不同的功能不应该放在一个类中。
二：里氏替换原则，缩写LSP（Liskov Substitution Principle）
定义1：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象 O1都代换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
看完之后，整个人都不好了~~
我们换个更直截了当的定义：
定义2：所有引用基类的地方必须能透明地使用其子类的对象。
举个例子
功能P1，由T1类完成，现在功能P1需要扩展，建立T2类，继承T1类，在T2类完成扩展时，可能造成原有功能P1出现问题。
所以，遵照此原则，我们在扩展时，T2类继承T1，除添加扩展功能外，尽量不重写和重载T1的方法。
但其实在现实中，常常会违背这个原则，比如我们在Android开发中自定义View。
三：依赖倒置原则，缩写DIP（Dependence Inversion Principle）
定义：抽象不应该依赖于细节，细节应当依赖于抽象。通俗点就是要针对接口编程，而不是针对实现编程。
举个例子
类T依赖类O2，现在类T需要改为依赖类O3，则必须修改类T完成。
遵照此原则，我们修改一下为
类O2，O3实现接口I，T通过接口I与O2、O3发生联系。
依赖倒置原则的核心就是要我们面向接口编程。
四：接口隔离原则，缩写ISP（InterfaceSegregation Principle）
定义1：客户端不应该依赖它不需要的接口。
另一种定义
定义2：类间的依赖关系应该建立在最小的接口上。
接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。
举个例子
接口I有方法M1，M2， M3。类O1实现接口I，需要接口I中的M1方法，类O2实现接口I，需要接口I中的方法M2，M3。
是不是发现对于类O1和O2来讲，接口I中的一些方法对彼此是没有用的？那么根据此原则，我们应该修正为：
将接口I拆分为I1，I2，I1中含方法M1，I2中含方法M2，M3，O1实现接口I1，O2实现接口I2。
将臃肿的接口拆分为更细粒度的接口中，使我们的系统具有更低的耦合性，提高灵活性。
五：迪米特原则，缩写LOD（Least Knowledge Principle）
定义：一个对象应该对其他对象保持最少的了解。
迪米特法则还有一个更简单的定义：只与直接的朋友通信。什么是朋友？每个对象与其他对象的耦合（组合、聚合、依赖等），我们就认定这两个对象为朋友关系。
通俗点讲，一个类对自己需要依赖的类知道的越少越好，类的内部实现跟调用者没有关系，调用者只需要知道它需要的方法即可。
类与类之间，耦合越大，修改的影响就越大，风险也就越大。所以我们应该尽量降低类与类之间的耦合，防止它们的朋友关系太铁~
六：开闭原则，缩写OCP（Open Close Principle）
定义：一个实体（类、模块、函数等）对于扩展开放，对于修改关闭。
在软件开发中，我们因为各种原因（需求变化、升级等）需要对原有代码进行修改时，可能会将错误的代码引入到已经测试过的旧代码中，是原来的系统出现错误。因此，当需要对原有代码进行修改时，我们应该尽量通过扩展的方式去实现，而不是修改原来的代码。
但其实在开发中，唯一不变的就是变化本身，产品需要不断升级、维护。
开闭原则是六大原则中最基础的一个，但也是让人最难做的一个，它指导我们如何建立一个稳定的、灵活的系统，告诉我们对于扩展开放，对于修改关闭。是不是感觉说的很对？但貌似什么都没说？
