大型Java进阶专题(三) 软件架构设计原则（下）

前言

​ 今天开始我们专题的第二课了，本章节继续分享软件架构设计原则的下篇，将介绍：接口隔离原则、迪米特原则、里氏替换原则和合成复用原则。本章节参考资料书籍《Spring 5核心原理》中的第一篇 Spring 内功心法（没有电子档，都是我取其精华并结合自己的理解，一个字一个字手敲出来的）。

接口隔离原则

​ 接口隔离原则（Interface Segregation Principke,ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则知道我们在设计接口时应当注意以下几点：

（1）一个类对另一个类的依赖应该建立在最小接口之上。

（2）建立单一接口，不要建立庞大臃肿的接口。

（3）尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

​ 接口隔离原则符合我们常说的高内聚、低耦合的设计思想，可以使类有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括对以后可能发生变化的地方做一些预判。所以，对于抽象、对于业务模型的理解是非常重要的。

​ 下面我们来看一段代码，对一个动物行为进行抽象描述。

//描述动物行为的接口
public interface IAnimal {
    void eat();
    void fly();
    void swim();
}

//鸟类
public class Bird implements IAnimal {
    public void eat() {
    }

    public void fly() {
    }

    public void swim() {
    }
}

//狗
public class Dog implements IAnimal {
    public void eat() {
    }

    public void fly() {
    }

    public void swim() {
    }
}

​ 可以看出，Brid的swim()方法只能空着，并且Dog的fly()方法显然不可能的。这时候，我们针对不同动物行为来设计不同的接口，分别设计IEatAnimal、IFlyAnimal和ISwimAnimal接口，来看代码：

public interface IEatAnimal {
    void eat();
}

public interface IFlyAnimal {
    void fly();
}

public interface ISwimAnimal {
    void swim();
}

此时Dog只需要实现IEatAnimal和ISwimAnimal接口即可，这样就清晰明了了。

public class Dog implements IEatAnimal,ISwimAnimal {

    public void eat() {
    }

    public void swim() {
    }
}

迪米特原则

​ 迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则(Least Knowledge Principle，LKP)，尽量降低类与类之间的耦合度。迪米特原则主要强调：只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类可以称为成员朋友类，而出现在方法体内部的类不属于朋友类。

​ 现在设计一个权限系统，Boss需要查看目前发布到线上的课程数量。这时候，Boss要找到TeamLeader进行统计，TeamLeader再把统计结果告诉Boss，接下来我们来看看代码：

//课程类
public class Course {
}

//TeamLeader类
public class TeamLeader {
    public void checkNumberOfCourses(List<Course> courses){
        System.out.println("目前已经发布的课程数量:"+courses.size());
    }
}

//Boss类
public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader){
        //模拟BOSS一页一页往下翻页,TeamLeader实时统计
        List<Course> courseList = new ArrayList<Course>();
        for (int i = 0; i < 20; i++) {
            courseList.add(new Course());
        }
        teamLeader.checkNumberOfCourses(courseList);
    }
}

//调用方代码
public static void main(String[] args) {
        Boss boss = new Boss();
        TeamLeader teamLeader = new TeamLeader();
        boss.commandCheckNumber(teamLeader);
}

​ 写到这里，其实功能已经实现，代码看上去没有什么问题，但是根据迪米特原则，Boss只想要结果，不希望跟Course直接交流。TeamLeader统计需要引用Course对象。Boss和Course并不是朋友,从下面的类图可以看出来:



​ 下面对代码进行改造：

//TeamLeader做与course的交流
public class TeamLeader {
    public void checkNumberOfCourses(){
        List<Course> courses = new ArrayList<Course>();
        for (int i = 0; i < 20; i++) {
            courses.add(new Course());
        }
        System.out.println("目前已经发布的课程数量:"+courses.size());
    }
}

//Boss直接与TeamLeader交流,不再直接与Course交流
public class Boss {
    public void commandCheckNumber(TeamLeader teamLeader){
        //模拟BOSS一页一页往下翻页,TeamLeader实时统计
        teamLeader.checkNumberOfCourses();
    }
}

再看下类图,Boss与Course已经没有联系了



​ 这里切记，学习软件设计规则，千万不能形成强迫症，碰到业务复杂的场景，我们需要随机应变。

里氏替换原则

​ 里氏替换原则（Liskov Substitution Priciple，LSP）是指如果对每一个类型为T1的对象O1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。

​ 这个定义看上去还是比较抽象的，我们要重新理解一下。可以理解为一个软件实体如果适用于一个父类，那么一定适用其子类，所以引用父类的地方必须能透明的使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变，根据这个理解，引申含义为：子类可以扩展父类的功能，但不能改变父类原有的功能。

​ （1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

​ （2）子类可以增加自己特有的方法。

​ （3）当子类的方法重载父类的方法时，方法的前置条件（即方法的输入、入参）要比父类的方法输入参数更宽松。

​ （4）当子类的方法实现父类的方法时（重写、重载或实现抽象方法），方法的后置条件（即方法的输出、返回值）要比父类更严格或与父类一样。

​ 使用里氏替换原则有以下优点：

​ （1）约束继承泛滥，是开闭原则的一种体现。

​ （2）加强程序的健壮性，同事变更时也可以做到非常好的兼容性，提高程序的可维护性和扩展性，降低需求变成时引入的风险。

​ 现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道正方形一个特殊的矩形，所以就可以创建一个父类Rectangle：

//矩形类
public class Rectangle {
    private long hight;
    private long width;

    public long getHight() {
        return hight;
    }

    public void setHight(long hight) {
        this.hight = hight;
    }

    public long getWidth() {
        return width;
    }

    public void setWidth(long width) {
        this.width = width;
    }
}

//正方形类
public class Square extends Rectangle {
    private long length;

    public long getLength() {
        return length;
    }

    public void setLength(long length) {
        this.length = length;
    }

    @Override
    public long getHight() {
        return super.getHight();
    }

    @Override
    public void setHight(long hight) {
        super.setHight(hight);
    }

    @Override
    public long getWidth() {
        return super.getWidth();
    }

    @Override
    public void setWidth(long width) {
        super.setWidth(width);
    }
}

public class DemoTest {
    //在测试类中创建resize方法,长方形的宽应该大于等于高,我们让高一直增加,直至高等于宽,变成正方形。
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() >= rectangle.getHight()){
            rectangle.setHight(rectangle.getHight()+1);
            System.out.println("宽度:"+rectangle.getWidth()+"高度:"+rectangle.getHight());
        }
        System.out.println("resize方法结束!");
    }

	//测试代码如下
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setHight(10);
        rectangle.setWidth(20);
        resize(rectangle);
    }

​ 看下控制台输出，发现高度最后大于了宽度，这个情况在正方形中是正常的情况，现在我们把Rectangle类替换成它的子类的话，就不符合逻辑了，违背了里氏替换原则，将父类替换成子类后，程序运行结果没有达到预期。因此，我们的代码设计存在一定的风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥。我们再来创建一个基于正方形和长方形共同的抽象接口四边形接口Quadrangle:

public interface Quadrangle {
    long getWidth();
    long getHeight();
}

修改长方形 Rectangle 类：

public class Rectangle implements Quadrangle {
    private long height;
    private long width;

    public long getHeight() {
        return height;
    }

    public long getWidth() {
        return width;
    }

    public void setHeight(long height) {
        this.height = height;
    }

    public void setWidth(long width) {
        this.width = width;
    }
}

修改正方形类 Square 类：

public class Square implements Quadrangle {
    private long length;

    public long getLength() {
        return length;
    }

    public void setLength(long length) {
        this.length = length;
    }

    public long getWidth() {
        return 0;
    }

    public long getHeight() {
        return 0;
    }
}

​ 此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。 因为正方形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承 泛滥，resize()的方法参数只能用 Rectangle 长方形。当然，我们在后面的设计模式课程 中还会继续深入讲解。

合成复用原则

​ 合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组 合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵 活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。 继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱 复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计， 其实也都需要遵循 OOP 模型。还是以数据库操作为例，先来创建 DBConnection 类：

public class DBConnection {
    public String getConnection(){
        return "MySQL 数据库连接";
    }
}

创建 ProductDao 类:

public class ProductDao{
    private DBConnection dbConnection;
    public void setDbConnection(DBConnection dbConnection) {
        this.dbConnection = dbConnection;
    }
    public void addProduct(){
        String conn = dbConnection.getConnection();
        System.out.println("使用"+conn+"增加产品");
    }
}

​ 这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生 变化，数据库操作层要支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违背了开闭原则。其实，我们可以不必修改 Dao 的代码， 将 DBConnection 修改为 abstract，来看代码：

public abstract class DBConnection {
    public abstract String getConnection();
}

然后，将 MySQL 的逻辑抽离：

public class MySQLConnection extends DBConnection {
    @Override
    public String getConnection() {
        return "MySQL 数据库连接";
    }
}

再创建 Oracle 支持的逻辑：

public class OracleConnection extends DBConnection {
    @Override
    public String getConnection() {
        return "Oracle 数据库连接";
    }
}

具体选择交给应用层，来看一下类图：

设计原则总结

​ 学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都 遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的 场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。