软件设计的六大原则剖析
烟雨星空 人气:1我们平时编写代码时，很少有人为了刻意迎合软件设计原则而编写。其实，有时候是你用到了其中的某个或多个设计原则，而不自知而已。也有可能是有的人压根就不知道设计原则是什么。
不过，没关系，为了搞明白既抽象又玄幻的六大准则，我总结了一句话来概括每一种设计原则所体现的主要思想。
里氏替换原则是指继承时不要破坏父类原有的功能；依赖倒置原则是指要面向接口编程；开闭原则是指对扩展是开放的，对修改是关闭的；职责单一原则是指实现类的职责要单一；接口隔离原则是指设计的接口要尽量简单，专一；迪米特法则是指要降低类之间的耦合度。
下面一一介绍六大类设计原则，看完之后，你会对上边的总结有更深的理解。
一、里氏替换原则
里氏替换原则，乍一看名字，让人摸不着头脑。其实，这是一位姓里的女士提出来的，因此用她的姓氏命名。里氏替换原则，通俗来讲，就是指子类继承父类时，可以扩展父类的功能，但是不要修改父类原有的功能。什么意思呢，举个例子。
//父类
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
}
}有心的人可能会发现，里氏替换原则规定子类不能重写父类的方法。这不是和面向对象中的三大特征之一“多态”冲突吗，多态实现的一个重要前提就是子类继承父类并重写父类的方法啊。
其实，刚开始学习里氏替换原则，我也产生了这样的疑惑。后来查了很多资料，才明白，子类不应该去重写父类已经实现的方法（非抽象方法），而是去实现父类的抽象方法。也就是说，尽量要基于抽象类和接口的继承，而不是基于可实例化的父类继承。关于这一点的解释，可以看这篇文章，我感觉总结的挺不错的：https://www.jianshu.com/p/e6a7bbde8844?utm_campaign
二、单一职责原则
简单来说，就是要控制类的粒度大小，降低类的复杂度，一个类只负责一项职责。
例如，在研发一个产品新功能时。需要项目经理接需求，评估工作量，然后分发任务给程序员。程序员，根据需求编写代码，然后自测。各司其职，才能保证项目稳定向前推进。其类图如下
另外，单一职责原则也适用于方法，一个方法只做一件事。
三、依赖倒置原则
依赖倒置原则的定义为：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其实，就是在说要面向抽象，面向接口编程。
举个栗子，如果一个学生去学习历史知识，只需要把历史书给他就可以了
public class History {
public String getKnowledge(){
return "历史知识";
}
}
public class Student {
public void study(History history){
System.out.println("学习" + history.getKnowledge());
}
}
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("学习" + geography.getKnowledge());
}
}
//学习地理知识虽然，这样实现也是可以的，但是通用性太差，类之间的耦合度太高了。设想，如果该学生又要学习数学知识呢，语文呢，英语呢，是不是每次都要修改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("学习" + iKnowledge.getKnowledge());
}
}
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 setDeptMgr(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.setDeptMgr(new DeptManager());
boss.task();
}
}
//老板发布任务
//部门领导发布任务
//员工执行任务这样，老板跟具体的每个员工就没有任何直接联系，降低了耦合度。
可以看到，其实部门经理在这其中充当了中介的作用，用于建立老板和员工之间的联系。需要注意，要适度的使用中介，如果中介太多，就会导致系统复杂度太高，通讯的效率降低。就如同一个公司，部门越多，级别层级越多，越不容易管理，沟通成本增加，执行任务的效率下降。因此，需要合理设计中介类。
六、开闭原则
开闭原则定义：对扩展是开放的，对修改是关闭的。
其实，这句话就体现了封装，继承和多态的思想。一个实体类，如果已经实现了原有的功能，就不应该再对其进行修改，需要的话应该对其进行功能扩展。这句话听起来是不是跟里氏替换原则特别像。其实，开闭原则更像是对其他几个原则的总结，最终要达到的目的就是用抽象构建高层模块，用实现扩展具体的细节。
里氏替换原则和依赖倒置原则告诉你应该对类和方法进行抽象。单一职责和接口隔离告诉你应该怎样做抽象才合理，迪米特法则告诉你具体实现怎样做才能做到高内聚，低耦合。
其实，六大设计原则就规定了一些规则，它告诉你按照这样做更好，但是如果你非要不遵守规则，也不是不行，代码照样可以跑，只不过是增加了代码出问题的概率，健壮性也不好，可维护性不高。这就像我们生活中的很多规则，如过马路，需要看红绿灯。但是，你非要不看，硬闯红灯，也没人能把你怎样，不过是增加了你被撞的概率而已。所以，遵守规则，能最大限度降低我们的损失。
加载全部内容