原文地址：LoveDev
在学习设计模式之前，需要了解一下面向对象的六大原则，设计模式大多都遵循这些原则，写代码时心中时刻不要忘记六大原则，利用它们能写出更整洁、低耦合、高内聚的代码，更加清晰的逻辑
该文章由网上以及书籍上的资料整理而来 :)
<h1 id="SRP"> 单一职责原则 </h1>
Single Responsibility Principle，简称SRP，对一个类而言，应该仅有一个引起它变化的原因，即一个类只负责一项职责
问题描述
当类 C 负责两个不同的职责：职责 M1，职责 M2，职责 M1 需求发生改变需要改变类 C 的时候，很有可能影响到原先的职责 M2 的功能
解决方案
一个类只负责一个职责，当需求改变时，不会影响到其他职责
<h1 id="LSP"> 里氏替换原则 </h1>
Liskov Substitution Principle，简称LSP，所有引用基类的地方必须能透明地使用其子类的对象
问题描述
有一个功能 M，由类 C 完成，由于业务需要，需要拓展 M 功能 M1，此时需要由类 C 的子类 C1 完成拓展功能，当 C1 完成 M1 功能的同时，有可能导致原来 M 功能不可用
解决方案
当使用继承时，遵循里氏替换原则。类 M1 继承类 M 时，除添加新的方法完成 M1 的新增功能外，尽量不要重写父类 C 的方法，也尽量不要重载父类 C 的方法
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障
<h1 id="DIP"> 依赖倒置原则 </h1>
Dependence Inversion Principle，简称DIP
- 高层模块不应该依赖低层模块，高层模块是调用类，低层模块是实现类
- 二者都应该依赖其抽象，抽象指接口或抽象类
- 细节应该依赖抽象，细节指实现类
问题描述
有 B 和 C 两个实现类，类 A 直接依赖类 B，这种场景下，类 A 一般为高层模块，负责复杂业务逻辑，类 B 和类 C 是低层模块，负责原子操作，如果需要把类 A 改为依赖类 C，必须通过修改类 A 源代码，可能会引入不必要的风险
Tip：
- 原子操作：不可分割的，在执行完毕之前不会被任何其它任务或事件中断的操作
解决方案
将类 A 修改为依赖接口 I ，类 B 和类 C 各自实现接口 I ，类 A 通过接口 I 间接与类 B 或者类 C 发生联系，则会大大降低修改类A的几率
示例代码：
interface Animal{
public String getFood();
}
class Cat implements Animal {
@Override
public String getFood() {
return "鱼";
}
}
class Dog implements Animal{
@Override
public String getFood() {
return "骨头";
}
}
class Master {
// 依赖Animal接口
public void feed(Animal animal) {
String food = animal.getFood();
}
}
<h1 id="ISP"> 接口隔离原则 </h1>
Interface Segregation Principle，简称ISP，一个类对另一个类的依赖应该建立在最小的接口上
问题描述
类 A 通过接口 I 依赖类 B，类 C 通过接口 I 依赖类 D，如果接口 I 对于类 A 和类 B 来说不是最小接口，则类 B 和类 D 必须去实现他们不需要的方法
解决方案
将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
<h1 id="LoD"> 迪米特法则 </h1>
Law of Demeter，简称LoD，也称为最少知识原则（Principle of Least Knowledge）或得墨忒耳定律，一个对象应该对其他对象保持最少的了解
问题描述
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大
解决方案
尽量降低类与类之间的耦合
<h1 id="OCP"> 开闭原则 </h1>
Open Close Principle，简称OCP，对象应该对扩展开放，对修改关闭，开闭原则是面向对象设计中最基础的设计原则
问题描述
在软件的开发工程中，因为需求变化，升级，重构和维护等原因，需要修改源代码，这样很有可能引入错误
解决方案
当软件有变化时，尽量通过扩展的行为实现变化，而不是通过修改已有的代码实现变化
