软件设计的六⼤原则剖析
我们平时编写代码时，很少有⼈为了刻意迎合软件设计原则⽽编写。其实，有时候是你⽤到了其中的某个或多个设计原则，⽽不⾃知⽽已。也有可能是有的⼈压根就不知道设计原则是什么。
不过，没关系，为了搞明⽩既抽象⼜⽞幻的六⼤准则，我总结了⼀句话来概括每⼀种设计原则所体现的主要思想。
⾥⽒替换原则是指继承时不要破坏⽗类原有的功能；依赖倒置原则是指要⾯向接⼝编程；开闭原则是指对扩展是开放的，对修改是关闭的；职责单⼀原则是指实现类的职责要单⼀；接⼝隔离原则是指设计的接⼝要尽量简单，专⼀；迪⽶特法则是指要降低类之间的耦合度。
下⾯⼀⼀介绍六⼤类设计原则，看完之后，你会对上边的总结有更深的理解。
⼀、⾥⽒替换原则
⾥⽒替换原则，乍⼀看名字，让⼈摸不着头脑。其实，这是⼀位姓⾥的⼥⼠提出来的，因此⽤她的姓⽒命名。⾥⽒替换原则，通俗来讲，就是指⼦类继承⽗类时，可以扩展⽗类的功能，但是不要修改⽗类原有的功能。什么意思呢，举个例⼦。
//⽗类
public class Calculate {
public int cal(int a,int b){
return a + b;
}
}
//⼦类
public class Calculate2 extends Calculate {
public int cal(int a,int b){
return a - b;
}
}
/
/测试
public class TestCal {
public static void main(String[] args) {
Calculate2 cal2 = new Calculate2();
int res = cal2.cal(1, 1);
System.out.println("1+1="+res); // 1+1 = 0
}
}
⼦类继承了⽗类之后，想实现新功能，却没有扩展新⽅法，⽽是重写了⽗类的cal⽅法，因此导致结果 1+1=0. 这就违反了⾥⽒替换原则。
应该把⼦类Calculate2修改为，添加⼀个新⽅法cal2来实现相减功能
public class Calculate2 extends Calculate {
public int cal2(int a, int b){
return a - b;
}
}
public class TestCal {
public static void main(String[] args) {
Calculate2 cal2 = new Calculate2();
int res = cal2.cal2(1, 1);
System.out.println("1-1="+res); // 1-1=0
}
}
有⼼的⼈可能会发现，⾥⽒替换原则规定⼦类不能重写⽗类的⽅法。这不是和⾯向对象中的三⼤特征之⼀“多态”冲突吗，多态实现的⼀个重要前提就是⼦类继承⽗类并重写⽗类的⽅法啊。
⼆、单⼀职责原则
简单来说，就是要控制类的粒度⼤⼩，降低类的复杂度，⼀个类只负责⼀项职责。
例如，在研发⼀个产品新功能时。需要项⽬经理接需求，评估⼯作量，然后分发任务给程序员。程序员，根据需求编写代码，然后⾃测。各司其职，才能保证项⽬稳定向前推进。其类图如下
另外，单⼀职责原则也适⽤于⽅法，⼀个⽅法只做⼀件事。
三、依赖倒置原则
依赖倒置原则的定义为：⾼层模块不应该依赖低层模块，⼆者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其实，就是在说要⾯向抽象，⾯向接⼝编程。
举个栗⼦，如果⼀个学⽣去学习历史知识，只需要把历史书给他就可以了
public class History {
public String getKnowledge(){
return "历史知识";
}
}
public class Student {
public void study(History history){
System.out.println("学习" + Knowledge());
}
}
public class Test {
public static void main(String[] args) {
Student stu = new Student();
stu.study(new History()); //学习历史知识
}
}
但是，如果他需要学习地理知识呢，我们需要把History改为Geography，然后修改study⽅法的参数类型为Geography
public class Geography {
public String getKnowledge(){
return "地理知识";
}
}
public class Student {
public void study(Geography geography){
System.out.println("学习" + Knowledge());
}
}
//学习地理知识
虽然，这样实现也是可以的，但是通⽤性太差，类之间的耦合度太⾼了。设想，如果该学⽣⼜要学习数学知识呢，语⽂呢，英语呢，是不是每次都要修改study⽅法。这样的设计不符合依赖倒置原则，应该把各个学科知识抽象出来，定义⼀个接⼝IKnowledge，然后每个学科去实现这个接⼝，⽽study⽅法的参数传⼀个固定类型IKnowledge就可以了。
public interface IKnowledge {
String getKnowledge();
}
public class History implements IKnowledge{
public String getKnowledge(){
return "历史知识";
}
}
public class Geography implements IKnowledge{
public String getKnowledge(){
return "地理知识";
}
}
public class Student {
public void study(IKnowledge iKnowledge){
System.out.println("学习" + Knowledge());
}
}
public class Test {
public static void main(String[] args) {
Student stu = new Student();
stu.study(new History()); //学习历史知识
stu.study(new Geography()); //学习地理知识
}
}
这样的话，如果需要再学习英语知识，只需要定义⼀个English类，去实现IKnowledge接⼝就可以了。这就是依赖倒置原则的⾯向接⼝编程。
它们之间的类图关系如下
四、接⼝隔离原则
接⼝隔离原则的定义：客户端不应该依赖它不需要的接⼝；⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上。
什么意思呢，就是说设计接⼝的时候，不要把⼀⼤堆需要实现的抽象⽅法都定义到同⼀个接⼝中，应该根据不同的功能，来拆分成不同的接⼝。我们知道，实现类去实现接⼝的时候，需要实现所有的抽象⽅法。如果接⼝中有某些不需要的⽅法，也需要实现，但是⽅法体却是空的，这样完全没有意义。
例如，我定义⼀个Animal的接⼝，⽤狮⼦去实现接⼝
public interface Animal {
void eat();
void fly();
void run();
}
public class Lion implements Animal {
@Override
public void eat() {
System.out.println("狮⼦吃⾁");
}
@Override
public void fly() {
}
@Override
public void run() {
System.out.println("狮⼦奔跑");
}
}
很明显，狮⼦是不会飞的，fly⽅法的⽅法体是空的。这样设计，不符合接⼝隔离原则。因此，我们把接⼝进⾏拆分，拆分为
Animal，IFly，IRun三个接⼝，让狮⼦选择性实现。
public interface Animal {
void eat();
}
public interface IFly {
void fly();
}
public interface IRun {
void run();
}
public class Lion implements Animal,IRun {
@Override
public void eat() {
System.out.println("狮⼦吃⾁");
}
@Override
public void run() {
System.out.println("狮⼦奔跑");
}
}
// 狮⼦只需要实现吃的⽅法和奔跑的⽅法就可以了，不需要实现IFly接⼝。
可以发现，接⼝隔离原则和职责单⼀原则⾮常之相似，但其实是不同的。职责单⼀原则主要是约束类，针对的是具体的实现，强调类职责的单⼀。⽽接⼝隔离原则主要是约束接⼝的，注重的是⾼层的抽象和对接⼝依赖的隔离。
另外，需要注意，接⼝设计的过细也不太好，会增⼤系统的复杂度。想象⼀下，你为了实现某些功能，却需要实现⼗⼏个接⼝的场景是多崩溃吧。因此需要适度地进⾏接⼝拆分。
五、迪⽶特法则
迪⽶特法则定义：⼀个对象应该对其他对象保持最少的了解。什么意思呢，就是说要尽量降低类之间的耦合度，提⾼类的独⽴性，这样当⼀个类修改的时候，对其他类的影响也会降到最低。
通俗点讲，就是⼀个类对它依赖的类知道的越少越好。对于被依赖的类来说，不管内部实现多复杂，只需给其他类暴露⼀个可以调⽤的公共⽅法。
举个简单的例⼦。当公司⽼板需要下发⼀个任务时，不会直接把每个员⼯都叫到⼀起，给每个⼈分配具体的任务。⽽是先召集各部门经理给他们发布任务，然后部门经理再给下边员⼯分派任务。⽼板只需要监督部门经理即可，不需要关⼼部门经理给每个员⼯分配的任务具体是什么。
⽤代码可以这样表⽰
public class Employee {
public void doTask(){
System.out.println("员⼯执⾏任务");
}
}
public class DeptManager {
public void task(){
System.out.println("部门领导发布任务");
Employee employee = new Employee();
employee.doTask();
}
}
public class Boss {
private DeptManager deptMgr;
public void tDeptMgr(DeptManager mgr){
this.deptMgr = mgr;
}
public void task(){
System.out.println("⽼板发布任务");
deptMgr.task();
}
}
public class TestD {
public static void main(String[] args) {
Boss boss = new Boss();
boss.tDeptMgr(new DeptManager());
boss.task();
}
}
//⽼板发布任务
//部门领导发布任务
//员⼯执⾏任务
这样，⽼板跟具体的每个员⼯就没有任何直接联系，降低了耦合度。
可以看到，其实部门经理在这其中充当了中介的作⽤，⽤于建⽴⽼板和员⼯之间的联系。需要注意，要适度的使⽤中介，如果中介太多，就会导致系统复杂度太⾼，通讯的效率降低。就如同⼀个公司，部门越多，级别层级越多，越不容易管理，沟通成本增加，执⾏任务的效率下降。因此，需要合理设计中介类。
六、开闭原则
开闭原则定义：对扩展是开放的，对修改是关闭的。
其实，这句话就体现了封装，继承和多态的思想。⼀个实体类，如果已经实现了原有的功能，就不应
该再对其进⾏修改，需要的话应该对其进⾏功能扩展。这句话听起来是不是跟⾥⽒替换原则特别像。其实，开闭原则更像是对其他⼏个原则的总结，最终要达到的⽬的就是⽤抽象构建⾼层模块，⽤实现扩展具体的细节。
⾥⽒替换原则和依赖倒置原则告诉你应该对类和⽅法进⾏抽象。单⼀职责和接⼝隔离告诉你应该怎样做抽象才合理，迪⽶特法则告诉你具体实现怎样做才能做到⾼内聚，低耦合。
其实，六⼤设计原则就规定了⼀些规则，它告诉你按照这样做更好，但是如果你⾮要不遵守规则，也不是不⾏，代码照样可以跑，只不过是增加了代码出问题的概率，健壮性也不好，可维护性不⾼。这就像我们⽣活中的很多规则，如过马路，需要看红绿灯。但是，你⾮要不看，硬闯红灯，也没⼈能把你怎样，不过是增加了你被撞的概率⽽已。所以，遵守规则，能最⼤限度降低我们的损失。
