一、单一职责原则(SRP)
单一职责原则(SRP)用于指导我们，在对功能划分到具体的类中的时候，要保证具有高内聚性。对于SRP的一个很好的描述是：就一个类而言，应该仅有一个引起它变化的原因。
想要使用好SRP，一个首先要搞清楚的问题是：什么是职责？每一个职责都是变化的一个轴线，职责被定义为"变化的原因"。
这里对于职责的定义个人感觉比较清楚明确。我们要知道，SRP中的职责并不是一个类中的函数，而是一个变化的轴线，具体到不同层次的类，其职责有大有小。如对于一个Activity来说，其负责的是展示一个完整的界面，那么界面的内容获取势必从他里面发起，界面的数据处理势必在其里面完成，一个Activity里面做的事情，调用的方法有很多，但是站在其层次的角度来考虑，一个Activity的职责就是负责好他所对应的页面，而其他页面的事情对它来说就是多余的职责。
即SRP告诉我们，当一个类中某几个功能常常衍生出新的场景、新的实现方式时，那么应该考虑将他们各自进行独立的职责封装，而不是在当前类中不断的改来改去、加来加去来使得当前类变得臃肿、难以维护。
1、一个例子
举一个例子，假设需要装一台电脑，以下是配置：
public class Computer {
private String CPU() {
return "最贵的最好的CPU";
}
private String board(){
return "最实惠的、型号对应的主板";
}
private void build() {
String cpu = CPU();
String board = board();
return "电脑配置为"+cpu+board;
}
}
当前来看这个类很单纯，就是组装一台电脑嘛，完全可以胜任，目前的方案是在CPU上花钱，主板挑一个过得去的就行；但是，不同的人需求不一样，有的人追求够用即可在CPU上也追求实惠，有的人土豪一个，在主板上也追求最贵最好。这样的需求变动不得不使我们在Computer类中添加对应的方法来满足以上需求，这样就导致了Computer类的臃肿和难以维护。
上述的问题在于，在可预见的未来，用户选择CPU的方案和选择board的方案都会产生很多变化，即Computer类变化的轴线有两个：CPU和board，这违反了SRP，所以方案就是将CPU的选择方案封装成一个单独的类CPU，将board的选择方案封装成一个单独的类Board。同时，这个例子也体现了单一职责也是分层次的，Computer的职责是负责组装电脑，CPU的职责是负责确定哪款CPU，Board的职责是负责确定哪款主板。
另外，在上述问题中CPU的选择方案与主板之间还存在一种约束关系(型号对不上)，因此，如果不将职责进行拆分的话，build方法还可能因为耦合关系，出现运行错误的情况，而这种情况当代码量很大时是很难察觉的。如果进行了职责的拆分，Computer类只负责CPU和board方案的匹配校验工作，那么这种错误发生的概率就会降低很多。
2. 小结
通过上述例子我们可以粗略大胆的认为当一下情况出现的时候，你的类违背了SRP，并且到了需要拆分的时候：
- 当前类包含了多个子功能的具体实现；
- 在应用场景中，上述子功能分别会有多种可能的实现方案。
二、开放封闭原则(OCP)
开闭原则(OCP)：软件实体应该是可扩展的，但是不可修改的。
按照OCP设计出的模块具有两个特征：
- 对扩展开放：模块的行为是可以扩展的；当应用的需求改变时，可以对模块进行扩展来满足新的行为。
- 对更改封闭：对模块进行扩展时，不必改变模块的源码。
上面的两个特征看起来有些矛盾，不改变源码怎么进行扩展？实际上OCP要求我们使用抽象来定义行为，使用具体类来实现行为，扩展也就是说使用新的具体类来扩展行为；封闭也就是说在使用该行为时使用抽象类对象来囊括不同具体行为，这样一来就不用了更改源码了(实际上由于多了个具体类，那么最起码初始化该具体类对象的地方还是相当于修改了源码，这是没法避免的)。
同时，还有一个重点在于，在使用OCP来定义行为的时候，一定要选择程序中呈现频繁变化的那些部分进行抽象；如若不然，那么滥用OCP也会带来很高的维护成本。
小结
通过上面的说明，我们对OCP可以有一个大概的认知，即具有如下结构的应用：
- 定义类时采用抽象类，实例化时采用具体类，即所谓的左类型与右类型。
三、里式替换原则(LSP)
上述的OCP核心思想在于：利用抽象来定义行为，利用具体类来实现和实施不同种的行为。但是，在面向对象开发中还有另一种形式的继承机制，即父类并不是抽象类，在一些情况下父类可以胜任很多工作，但有时候需要子类对象来扩展一些工作，而不得不实例化子类对象，这时候就需要要求在实例化子类对象时，他要能够完成其父类角色的任务。
即：在大多数情况下Parent a = new Parent();a.fun1();即可完成工作，但有时候需要使用到子类：Parent b = new Child();b.fun1();b.fun2();才能够完成工作。那么就需要子类的fun1()方法能够像父类的该方法一样承担应有的工作。
LSP的解释如下：子类型必须能够替换掉他们的基类型。并且在替换掉基类型之后，程序依然能够运行。
1. 一个例子
假设父类的sort函数可以实现对数组的升序排序：
class Parent {
int[] array;
public Parent(int[] a) {
this.array = a;
}
public void sort() {
实现对array的升序排序
...
}
}
class Child {
...
@override
public void sort(){
实现对array的降序排序
}
}
很显然，上述的子类虽然是继承了父类，并且重写了父类的sort方法，但是将全局的所有父类对象的实现变为子类对象，那么程序肯定会出问题。这就是LSP所约束的问题。
2. 小结
LSP和OCP看起来都是在说继承的问题，但是他们所关注的场景不同，而且可以看出OCP显然是遵从了LSP的，因为OCP的背景为不同子类去扩展抽象类所定义的行为的。
而LSP则告诉我们，子类在覆盖父类的方法的时候不能够任意实现，而是要遵循父类对该方法的期望与要求。为此，有人提出了一种契约设计的方式：
- 契约是通过为每一个方法声明的前置条件和后置条件来指定的；
- 要使一个方法得以执行，前置条件必须要为真；执行完毕后，后置条件必须为真；
- 派生类的前置条件和后置条件的规则为：在重新声明派生类中的例程时，只能使用相等或更弱的前置条件来替换基类的前置条件；只能使用相等或更强的后置条件来替换基类的后置条件。
四、依赖倒置原则(DIP)
开门见山，该原则的解释为：
- 高层模块不应该依赖于低层模块，二者都应该依赖于抽象；
- 抽象不应该依赖于细节，细节应该依赖于抽象。
如果高层模块依赖于低层模块，那么在不同的上下文中重用高层模块会变得非常困难。
首先要明确一点的是，既然是高层模块，那么其势必要使用低层模块提供的功能或者说服务，如何做到高层不依赖于低层呢？答案就在后半句，抽象，不过要加上一种要求：抽象由高层模块来定义，低层模块去实现它。这样一来，高层模块就可以通过抽象类对象来使用想要的服务，而不必理会低层模块是如何实现它的，从而避免了对低层模块的依赖。这也体现了第二个要求，是细节依赖抽象而不是抽象依赖细节，即高层模块一旦定义了想要的服务，就不必理会低层模块的具体实现方式，即这种服务一定要抽象到不用去理会实现细节。
很明显，一个典型的例子就是计算机网络协议的设计，高层协议通过服务访问点来使用下层协议所提供的服务，而不必理会下层协议是何种协议。例如TCP是传输层协议，其只需要下层能够将数据传输到端即可，而不关心你是IPv4还是IPv6.
五、接口隔离原则(ISP)
接口隔离原则很简单：
不应该强迫客户依赖于他们不用的方法
因为一旦这些方法发生变化，他们不得不做出相应的改变。
很显然，出现上述情况时，应该对接口进行拆分了。
