软件设计六大原则
网上有很多朋友都介绍过这六个原则，下面我简单说说我对这六个原则的一些理解。
如上图所示，这就是软件设计的六大原则。
其中我认为最重要的就是开闭原则，可以理解为这是最终目的。其余的五种原则都是为了达到这个目的而存在的。
要理解开闭原则，则需要先看看另外五个原则。
单一职责（Single Responsibility Principle）
单一职责原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。
个人理解
这是单一职责的概念，我对这个原则的理解是，一个类最好只有一种职责，返回来说就是，把相同的职责放到一个类中。这样就实现了高内聚。
职责可以从各种维度去切割，比如以中间件为维度拆分类，或者以业务规则为维度拆分类等等。
想要将职责才分的恰到好处，需要对业务领域的深入理解，和对软件设计的经验。
例子
举个例子，用户模块的业务需要MySql和Redis这两个中间件来支持。
如果我创建一个UserRepository，里面既有访问MySql存储数据的方法，又有访问Redis存储数据的方法，那么可以理解为这个类有两个职责，访问MySql和Redis。
那么可以创建两个类：UserRepository封装访问MySql的方法，UserRedisRepository封装访问Redis的方法，这种类的职责就单一了。
再举个例子，天气模块中的类WeatherService有一个方法getWeather()，该方法会发起HTTP请求访问第三方资源接口获取天气数据（返回JSON格式），随后将JSON数据转换成WeatherEntity。
这里最好在进行一次拆分，可以把请求第三方接口当作一种职责，提供一个WeatherProxy类，然后将数据转换作为一种职责，提供一个WeatherConverter类。
好处
降低类的复杂度、提高可读性、提高可维护性、提高扩展性、降低了变更引起的风险。
里氏替换（Liskov Substitution Principle）
如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。所有引用基类的地方必须能透明地使用其子类的对象，通俗的说，就是派生类（子类）对象可以在程序中代替其基类（父类）对象。
个人理解
通俗的理解是，在使用父类的地方可以任意使用其子类，但是在使用子类的地方不一定能使用父类。
例子
最简单的一个例子，在Java中，大家都有使用过List，它的实现最初可以是ArrayList，随后也可以修改成LinkedList。
在做修改时，List的使用并不会被影响。
List list = new ArrayList<>();
list.add(...);
list.forEach(t -> {...}); 上面代码中，可随意切换List的实现类，对后续使用的代码不会造成任何影响。
List list = new LinkedList<>(); // 修改实现类不会对下面的代码造成影响
list.add(...);
list.forEach(t -> {...}); 上面的例子中的list.forEach就实现了里氏替换原则，该方法接收任何List对象，此处传递ArrayList或LinkedList都是可以的，做到了子类可以在程序中代替其父类。
好处
增强程序的健壮性，即使切换了子类，不会对使用代码造成影响。
依赖倒置原则（Dependence Inversion Principle）
高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。
个人理解
这里应该指的是面相接口编程，说的是对象与对象之间的依赖关系。
通俗的说就是把业务的功能划分清楚后，定义在接口和抽象类中，然后编写业务类继承或实现该接口或抽象类，如果对外发布封装的业务功能，要发布接口或抽象类，而不是具体的实现类。
例子
依赖倒置在工作中是最常使用的。
项目中常用的分层架构，Controller层，Service层，Dao层。Controller层会调用Service层，Service层会调用Dao层。
假如使用Spring Framework开发用户模块，编写数据访问层的时候，都会编写一个UserDao接口，然后编写一个UserDaoImpl的实现类。UserServiceImpl会创建一个UserDao对象，然后使用@Autowired自动装配。
@Service("userService")
public class UserServiceImpl implements UserService {
....
@Autowired
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
private UserDao userDao;
}这里就用到了依赖倒置原则，依赖抽象接口而不依赖于具体的实现类。
好处
可以减少类见的耦合性，提高系统的稳定性，可高代码的可读性和可维护性，也可以降低同时开发时引起的风险。
接口隔离原则（Interface Segregation Principle）
拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。
个人理解
设计接口的时候，尽量不要设计出一个拥有非常多的方法的庞大接口，应该尽量使用多个专门提供某种功能的接口。
例子
还是用开发用户模块举例，在编写根据手机号登录，如果登录不存在则注册的时候，需要用到发送短信验证码、验证短信验证码、登录、注册等功能。
此时，如果根据接口隔离原则，就需要登录将一个LoginService接口拆分成多个专门提供某种功能的接口，例如：
-
LoginService接口，里面有登录功能； -
PinCodeService接口，里面有发送PinCode和验证PinCode的功能； -
RegeditService接口，里面有注册的功能；
那么在登录时有可能会用到这三个接口。
此时，还有一个业务场景，修改手机号时，需要输入旧的手机号，获取Pin码并验证，然后输入新的手机号，获取Pin码并验证，最后调用修改电话号的功能。那么在修改手机号时只需要用到PinCodeService即可，不需要使用LoginService和RegeditService。
这就是接口隔离原则的一个实现例子。
满足接口隔离原则的同时，先满足单一职责原则。
好处
使程序解耦，从而容易重构、更改和重新部署。
最少知识原则（Least Knowledge Principle）
又叫迪米特法则，系统中的类，尽量不要过多的与其他类互相作用，减少类之间的耦合度。
- 每个单元对其他单元只拥有有限的知识，只了解与当前单元紧密联系的单元；
- 每个单元只能和它的 "朋友" 交谈，不能和 "陌生人" 交谈；
- 只和自己直接的 "朋友" 交谈；
个人理解
一个对象调用另一个对象时，应该不去过分关注这个对象的实现。被调用的对象的内部是如何复杂都和调用者无关，简单的说，调用者就知道被调用者提供的的public方法就行，其他的不需要关心。
例子
假设一个场景，老板要统计公司的人数，可以这个命令委托给主管，由主管去统计人数。
public class Boss {
public void command(Manager manager) {
....
}
}
public class Manager {
private List employees;
public Manager(List employees) {
this.employees = employees;
}
public int employeeCount() {
return this.employees.size();
}
}
public class Employee {}
public class Client {
public static void mand(String[] args) {
List employees = new ArrayList<>();
... 添加20个employee
Boss boss = new Boss();
boss.command(new Manager(employees));
}
}
其中Boss只与Manager进行交谈，Manager只与Employee进行交谈，Boss不与Employee进行交谈，这就是最少知识原则的一个例子。
好处
类负责的职责清晰明了，使类可以高度内聚降低类与类之间的耦合。
开闭原则（Open Close Principle）
软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的。
个人理解
我对开闭原则的理解是，程序应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化的。面向对象可以达到这种方式完成对软件的扩展。
在对软件进行设计时，应该尽可能的考虑到后续会变更的地方，以便在变更真发生时，可以尽可能在不修改或修改很少的情况下，把变更实现。
例子
开闭原则是最基础的设计原则，其它的五个设计原则都是开闭原则的具体形态。
好处
开闭原则可以提高复用性，维护性，减少测试范围。