Java进阶专题: 软件架构设计原则

1、前言

​ 今天开始我们专题的第一课了,也是我开始进阶学习的第一天,我们先从经典设计思想开始,看看大牛市如何写代码的,提升技术审美、提高核心竞争力。本章节参考资料书籍《Spring 5核心原理》中的第一篇 Spring 内功心法(需要电子档的加小姐姐V:java9610 免费领取)。

2、开闭原则

开闭原则(Open-Closed Principle,OCP)是指一个软件实体(如类,模块和函数)应该对扩展开发,对修改关闭。所谓的开闭,也正是对扩展和修改的两种行为的一个原则。它强调的是用抽象构建框架,用实现扩展细节,可以提高软件系统的可复用性及可维护性。开闭原则他是面向对象设计中最基础的设计原则。它知道我们如何建立稳定、灵活的系统。例如版本更新,我们尽可能不修改源码,但可以增加新功能。常见于我们经常写的接口与实现类的使用上,先接口定义好,对于不同的需求写不同的实现类,后期有改动若不修改原有代码,可以重新写一个实现类。

3、依赖倒置原则

依赖倒置原则(Dependence Inversion Principle,DIP)是指设计代码结构时,高层模块不应该依赖底层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且能够降低修改程序所造成的风险。这是一个比较重要的设计原则,在我们日常开发中,经常有使用该思想的场景,能避免很多时候业务更改时,只需要改动少量代码就可以完成需求。下面我们通过一个例子,来深入理解该思想。

以学习课程为例:

//Tom正在学习两个课程 public class Tom { public void studyJva() { System.out.println("正在学习Java"); } public void studyPython() { System.out.println("正在学习Python"); } }
//这里调用Tom的两个学习方法 public static void main(String[] args) { Tom tom = new Tom(); tom.studyJva();; tom.studyPython(); }

 看上去以上两个类的方法与调用没有毛病,但是随着业务的扩展,Tom又想继续学习Go语言,这时候我们就需要从低层到高层(调用层)依次修改代码。先在Tom里面正在studyGo()方法,然后在main中加以调用。这样一来,系统发布以后,实际上非常不稳定,现在代码少能清晰知晓,但是实际项目中,代码量、涉及的业务非常多,修改多个类的代码,可能会代码意想不到的风险。

​ 接下来我们根据依赖倒置的思想来优化代码,先创建一个ICourse接口。

public interface ICourse { /** * 抽象出来一个专门用来学习的方法,抽象不依赖细节,不去关心去学习什么课程 */ void study(); }

//创建一个Java课程学习 public class JavaCourse implements ICourse { /** *由实现类去觉得具体学习什么课程(细节应该依赖抽象) */ public void study() { System.out.println("Tom在学习Java"); } }

//创建一个Python课程学习 public class PythonCourse implements ICourse { public void study() { System.out.println("Tom在学习Python"); } }

//修改Tom public class Tom { public void study(ICourse course){ //应证了高层模块不应该依赖底层模块,应该依赖其抽象 course.study(); } }
//调用方代码 public static void main(String[] args) { Tom tom = new Tom(); tom.study(new JavaCourse()); tom.study(new PythonCourse()); }
通过以上代码改造,可以看出了依赖倒置原则的核心思想。通过抽象课程学习的接口,减少了类与类之间的耦合性和可维护性。当又有新的课程添加,我们直接可以再添加一个实现类,通过传参的方式告知Tom,而不在需要修改底层代码(也体现了开闭原则)。

​ 大家要切记:以抽象为基准比以细节为基准搭建起来的架构要稳定的多,因此在拿到需求之后,要面向接口编程,先顶层再细节设计代码结构。

4、单一职责原则

​ 单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责,一旦发生需求变更,修改其中一个职责的代码,有可能导致另外一个职责的功能发生故障。这样一来,这个类就存在两个导致类发生变更的原因。如何解决这个问题呢?将两个职责用两个类来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。总体来说,就是一个类、接口或方法只负责一项职责。

​ 接下来,我们来看代码示例,还用课程举例,我们的课程有直播课和录播课。直播课不能快进和快退,录播课程可以任意反复观看,功能职责不一样,还是想创建一个Course类:

public class Course { public void study(String courseName){ if ("直播课".equals(courseName)){ System.out.println(courseName + "不能快进"); }else { System.out.println(courseName + "可以反复回看"); } } }

//看下调用代码 public static void main(String[] args) { Course course = new Course(); course.study("直播课"); course.study("录播课"); }

​ 从上面的的代码来看,Course类承担了两种处理逻辑。假如现在要对课程进行加密,直播课与录播课的加密逻辑不一样,必须修改代码。而修改代码的逻辑势必会相互影响,容易带来不可控的风险。我们对职责进行解耦,来看代码,分别创建两个类

//直播 public class LiveCourse { public void study(String courseName){ System.out.println(courseName + "不能快进看"); } }
//录播 public class ReplayCourse { public void study(String courseName){ System.out.println(courseName + "可以反复回看"); } }
//调用代码 public static void main(String[] args) { LiveCourse liveCourse = new LiveCourse(); liveCourse.study("直播课!"); ReplayCourse replayCourse = new ReplayCourse(); replayCourse.study("录播课!"); }

​ 此时业务继续发展,课程要做权限。没有付费的学员可以获得课程基本信息,已经付费的学员可以获得视频流,即学习权限。设计一个顶层接口,创建ICourse接口:

public interface ICourse { //获取课程基本信息 String getCourseName(); //获取视频流 byte[] getCourseVideo(); //学习课程 void studyCourse(); //退款 void refundCourse(); }
​ 其实在控制课程层面上至少有两个职责。我们可以把展示职责和管理职责分离开来,都实现同一个抽象依赖。我们可以把这个接口拆成两个接口:ICourseInfo和ICourseManager。
public interface ICourseInfo { //获取课程基本信息 String getCourseName(); //获取视频流 byte[] getCourseVideo(); } public interface ICourseManager { //学习课程 void studyCourse(); //退款 void refundCourse(); }

我们看下类图

以上是类/接口的单一职,下面我们看下方法层面的单一职责,有时候我们会偷懒,把一个方法写成下面这样:

/** * 修改用户信息 */ private void modityUserInfo(String userName,String address){ userName="LaoWang"; address = "BeiJin"; } private void modityUserInfo(String userName,String... fileds){ userName="LaoWang"; for (String filed : fileds) { //.... } } private void modityUserInfo(String userName,String address,boolean bool){ if (bool){ //... }else { //... } userName = "LaoWang"; address = "BeiJin"; }
 显然,上面的modityUserInfo()方法承担了多个职责,既可以修改userName又可以修改address,甚至更多,明显不符合单一职责。我们做如下修改,可以拆成两个方法
private void modifyUserName(String userName){ userName="LaoWang"; } private void modifyAddress(String address){ address = "BeiJin"; }

​ 修改之后,开发起来简单,维护起来也容易。我们在实际开发中会有项目依赖、组合、聚合这些关系,还有的项目的规模、周期、技术人员的水平、对进度的把控,很多类都不符合单一职责。但是,我们在编写代码的过程中,尽可能的让接口和方法保持单一职责,对项目后期的维护是有很大的帮助的。

 

第二节:

1、接口隔离原则

​ 接口隔离原则(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() { } }

2、迪米特原则

​ 迪米特原则(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已经没有联系了

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

3、里氏替换原则

​ 里氏替换原则(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 长方形。当然,我们在后面的设计模式课程 中还会继续深入讲解。

4、合成复用原则

​ 合成复用原则(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 数据库连接"; 
    } 
}
具体选择交给应用层,来看一下类图:

5、设计原则总结

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

 

结尾:

最后希望大家多多支持 一键三连+评论下 并献上我自己整理的“大厂真题+微服务+MySQL+分布式+SSM框架+Java+Redis+数据结构与算法+网络+Linux+Spring全家桶+JVM+高并发+各大学习思维脑图+面试集合”

 

全部评论

相关推荐

今天 11:40
海南大学 Java
点赞 评论 收藏
分享
牛客618272644号:佬携程工作怎么样,强度大吗
点赞 评论 收藏
分享
评论
点赞
收藏
分享
牛客网
牛客企业服务