Java进阶专题(三) 软件架构设计原则(下)-阿里云开发者社区

开发者社区> 老王爱java> 正文

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

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

前言

​ 今天开始我们专题的第二课了,本章节继续分享软件架构设计原则的下篇,将介绍:接口隔离原则、迪米特原则、里氏替换原则和合成复用原则。本章节参考资料书籍《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 数据库连接"; 
    } 
}

具体选择交给应用层,来看一下类图:

设计原则总结

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
10306 0
JavaScript进阶【五】利用JavaScript实现动画的基本思路
版权声明:本文为博主原创文章,未经博主允许不得转载。更多学习资料请访问我爱科技论坛:www.52tech.tech https://blog.csdn.net/m0_37981569/article/details/79659313 ...
843 0
JavaScript进阶【二】JavaScript 严格模式(use strict)的使用
版权声明:本文为博主原创文章,未经博主允许不得转载。更多学习资料请访问我爱科技论坛:www.52tech.tech https://blog.csdn.net/m0_37981569/article/details/79249309 ...
875 0
JavaScript进阶【三】JavaScript面向对象的基础知识复习
版权声明:本文为博主原创文章,未经博主允许不得转载。更多学习资料请访问我爱科技论坛:www.52tech.tech https://blog.csdn.net/m0_37981569/article/details/79547464 ...
785 0
JavaScript进阶【一】JavaScript模块化开发的基础知识
版权声明:本文为博主原创文章,未经博主允许不得转载。更多学习资料请访问我爱科技论坛:www.52tech.tech https://blog.csdn.net/m0_37981569/article/details/79249047 //模块化的最初写法 //1.最初写法 //下面的m1和m2就组成了一个模块 //缺点:"污染"了全局变量,无法保证不与其他模块发生变量名冲突,而且模块成员之间看不出直接关系。
905 0
Java---设计模式app小软件汇总应用
写了一个app小软件,重点不在于软件,软件bug挺多,也没去修改。 这个小软件只是为了更好的说明和了解设计模块而做的。 Java 程序设计–包结构 Java程序设计的系统体系结构很大一部分都体现在包结构上 大家看看我的这个小软件的分层: 结构还是挺清楚的。
803 0
JavaScript进阶【四】JavaScript中的this,apply,call的深入剖析
版权声明:本文为博主原创文章,未经博主允许不得转载。更多学习资料请访问我爱科技论坛:www.52tech.tech https://blog.csdn.net/m0_37981569/article/details/79646265 ...
937 0
91
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载