【软件架构设计原则】迪米特原则、里氏替换原则、合成复用原则

软件架构设计原则

本文通过实例来讲解

• 迪米特原则
• 里氏替换原则
• 合成复用原则

迪米特原则

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

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

Course类：

public class Course {
}

TeamLeader类的代码：

public class TeamLeader {
    public void checkNumberOfCourse(List<Course> courseList){
        System.out.println("目前已发布的课程信息："+courseList.size());
    }
}

Boss类的代码：

public class Boss {
    
    public void commandCheckNumber(TeamLeader teamLeader){
        List<Course> courseList = new ArrayList<>();
        for (int i =0; i < 20 ; i++){
            courseList.add(new Course());
        }
        
        teamLeader.checkNumberOfCourse(courseList);
    }
}

测试代码：

public class Test {
    public static void main(String[] args) {
        Boss boss = new Boss();
        TeamLeader teamLeader = new TeamLeader();
        boss.commandCheckNumber(teamLeader);
    }
}

功能其实已经基本实现，代码其实看上去也没有什么问题。根据迪米特原则，Boss只想知道结果，不需要跟Course交流。而TeamLeader 统计需要引用Course对象。Boss和Course并不是朋友。

对代码进行改造：

TeamLeader类的代码如下：

public class TeamLeader {
    public void checkNumberOfCourse(){
        List<Course> courseList = new ArrayList<>();
        for (int i =0; i < 20 ; i++){
            courseList.add(new Course());
        }
        System.out.println("目前已发布的课程信息："+courseList.size());
    }
}

Boss类：

public class Boss {

    public void commandCheckNumber(TeamLeader teamLeader){


        teamLeader.checkNumberOfCourse();
    }
}

这样Boss和Course就没有关联了。

里氏替换原则

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

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

1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2. 子类可以增加自己特有的方法
3. 当子类的方法重载父类的方法时，前置条件要比父类方法的输入参数更宽松。
4. 当子类的方法实现父类的方法时，方法的后置条件（返回值）要比父类更严格或父类一样。

使用里氏替换原则又以下优点：
5. 约束继承泛滥，是开闭原则的一种体现
6. 加强程序的健壮性。同时变更时也可以做到非常好的兼容性，提高程序的可维护性和扩展性，降低需求变更时引入的风险。

现在描述一个场景，用正方形、矩形、和四边形的关系说明里氏替换原则，我们都知道正方形是一种特殊的长方形，所以我们创建一个父类Rectangle

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

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

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

    public long getHeight() {
        return height;
    }

    public long getWidth() {
        return width;
    }
}

创建正方形Square继承Rectangle类：

public class Square extends Rectangle {

    private long length;
    
    public long getLength() {
        return length;
    }

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

    @Override
    public void setHeight(long height) {
        setLength(height);
    }

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

    @Override
    public long getHeight() {
        return getLength();
    }

    @Override
    public long getWidth() {
        return getLength();
    }
}

在测试中创建resize方法，长方形的宽应该大于正方形，我们让高一直增加，直到高大于等于宽。

public static void resize(Rectangle rectangle){
        while (rectangle.getWidth()>rectangle.getHeight()){
            rectangle.setHeight(rectangle.getHeight()+1);
            System.out.println("Height："+rectangle.getHeight()+"  Weight: "+rectangle.getWidth());
        }

        System.out.println("方法结束:  " + "Height："+rectangle.getHeight()+"  Weight: "+rectangle.getWidth());
    }

测试代码：

 public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setHeight(10);
        rectangle.setWidth(20);
        resize(rectangle);
    }

如果我们把矩形类换成正方形类：

 public static void main(String[] args) {
        Square square = new Square();
        square.setLength(10);

        resize(square);
    }

上述代码方法了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥，我们在创建一个基于长方形和正方形的抽象四边形接口Quadrangle；

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

修改长方形类：

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

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

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

    public long getHeight() {
        return height;
    }

    public long getWidth() {
        return width;
    }
}

修改正方形类：

public class Square implements Quadrangle {

    private long length;

    public long getLength() {
        return length;
    }

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

    @Override
    public long getHeight() {
        return getLength();
    }

    @Override
    public long getWidth() {
        return getLength();
    }
}

此时，如果我们把resize（）方法的参数换成四边形接口，方法就会报错，因为正方形类已经没有了setWidth()和setHeight（）方法，因此为了约束继承泛滥，resize（）方法的参数只能用Rectangle类。

合成复用原则

合成复用原则(Composite/Aggregate Reuse Principle,CAPP)是指尽量使用对象组合（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数据库。当然我们可以在DB类中增加对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 Oracle extends DBConnection {
    @Override
    public String getConnection() {
        return "Oracle";
    }
}

设计原则总结

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

其他设计原则

开闭原则和依赖倒置原则
单一职责原则和接口隔离原则

参考：Spring 5 核心原理