其他分享
首页 > 其他分享> > 软件架构设计原则

软件架构设计原则

作者:互联网

文章目录

软件架构设计原则

开闭性原则

什么是开闭性原则?就是我们已经写好的代码,对修改关闭,对扩展开放。

你就比如,公司是九点半上班,晚上六点半下班,你可以早来,可以晚走,这是可以扩展的。但是你不能晚来,早走,你不能在原有的逻辑上进行修改。

依赖倒置原则

细节通过传参进行控制,大的行为通过一个方法进行控制。你比如,现在有一个Tom类,如下

public class Tom{
    public void study(ICourse course){
        course.study();
    }
}

Tom的大的行为就是学习课程,这个大的行为我们使用一个方法study进行控制,而学习课程的一些细节,就是你学习的到底是什么课程,比方说你是学习java,还是学习python,又或者是学习AI算法,都可以通过传递不同的参数进行控制。我们只需要写一些实现类JavaCourse,PythonCourse,AICourse,让这些实现类都实现ICourse接口,然后把这些实现类当做参数传递给study方法就行了。

这样无论Tom想要学习什么课程,都可以通过传递不同的实现类参数给study来实现。这就叫做依赖倒置原则。

如果没有这个依赖倒置原则,你想一下会出现什么后果,就是如果Tom的学习兴趣很浓烈的话,那么每学习一门课程,你就需要要在Tom类里面定义一个方法,比如上面的这个例子,需要在Tom类里面定义三个方法,分别是JavaCourseStudy方法,PythonCourseStudy方法,AICourse方法,这样是不是就显得Tom这个类里面显得特别臃肿,所以这就是依赖倒置原则的好处。

单一职责原则

单一职责原则意思就是:一个类,接口,方法只负责一项职责。

先来说一下方法只负责一项职责是什么意思,就是一个方法中只能有一项功能,如果这个方法中的某一段很长的代码可以被单独抽离成一个功能,那么我们就需要把这段代码单独封装成一个功能。

接口只负责一项职责是什么意思,就是一个接口里面的抽象方法必须要属于同一个大类的功能。比如有专门获取信息的接口,有专门管理信息的接口,我们要写成两个接口,不能把它们写在一个接口里面。

类只负责一项职责是什么意思,我们的类实现了只负责一项职责的接口,那么它肯定也是只负责一项职责。

接口隔离原则

接口隔离原则的意思就是每一个接口必须要是一个最小单位,什么意思呢?

你就比如现在有三个接口:

//可以吃的动物接口
public interface IEatAnimal{
    void eat();
}

//可以飞的动物接口
public interface IFlyAnimal{
    void fly();
}

//可以游泳的动物接口
public interface ISwimAnimal{
    void swim();
}

如果我们现在有一个小鸟Bird,这个小鸟既可以飞又可以吃,但是不可以游泳,那么我们就可以写成这种格式:

public class Bird implements IEatAnimal,IFlyAnimal{
    @Override
    void eat(){}
    @Override
    void fly(){}
}

上面定义的三个接口就是最小单位的接口。

那怎么判断接口不是最小单位的接口呢?你就想一下,如果一个实体类实现了一个接口,这个接口中的抽象方法会不会有得不到继承的。比如现在有一个动物接口,如下:

public interface IAnimal{
    void eat();
    void fly();
    void swim();
}

然后一个小鸟Bird来实现这个接口,那么就会出现一个问题,因为swim()小鸟是做不到的,所以就会出现一个用不着实现的多余方法,那么IAnimal这个接口就不是最小单位的接口。

迪米特原则

迪米特原则的意思就是:只和熟悉的人交流,不和陌生人交流。

其实也就是不要跨层管理,上层就只负责它的直属下层就行了,不要负责它的直属下层的直属下层。

你比如,现在有一个Boss要统计课程的数量,它需要去问TeamLeader,然后TeamLeader会去统计课程的数量。如果Boss不仅要管他的直属下层TeamLeader还要管它的直属下层的直属下层,就会出现下面的这个情况,如下:

//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.checkNumberOfCourse(courseList);
    }
}

//TeamLeader类的代码如下
public class TeamLeader{
    public void checkNumberOfCourse(List<Course> courseList){
        System.out.println("目前已经发布的课程数量是:"+courseList);
    }
}

乍一看上面的代码是没有问题的,但是你仔细分析可以发现,Boss类它不仅和它的直属下层TeamLeader进行了交流,还和它的直属下层的下层Course进行了交流,这样就不符合迪米特原则了。我们可以进行一些修改,让Boss类只和它的直属下层TeamLeader进行交流,不要和Course进行交流,至于和Course进行交流的工作应该分给TeamLeader,如下:

//Boss类的代码如下
public class Boss{
    public void commandCheckNumber(TeamLeader teamLeader){
        teamLeader.checkNumberOfCourse(courseList);
    }
}

//TeamLeader类的代码如下
public class TeamLeader{
    public void checkNumberOfCourse(List<Course> courseList){
        List<Course> courseList = new ArrayList<Course>();
        for(int i=0; i<20; i++){
            courseList.add(new Course());
        }
        System.out.println("目前已经发布的课程数量是:"+courseList);
    }
}

对应到我们的项目中就是,我现在能想到的就是一个三层架构,上层直接去调用它的下层,但不能出现即调用它的下层又调用它的下下层的情况。

里式替换原则

什么是里式替换原则呢?意思就是所有用到父类的地方,都可以用它的子类替换。引申含义其实是:子类可以扩展父类的功能,但不可以改变父类原有的功能。有两个规范:

1.子类可以实现父类中的抽象方法,但是不能重写父类中的非抽象方法,父类中的非抽象方法,子类中必须要保持父类中原有的非抽象方法的完整性。

2.子类中可以增加自己特有的方法。

比如,如果子类中重写了父类的非抽象方法,当用子类替换父类的时候,可能就出现异常了,如下:

有一个长方形类:

/**
 * @Date 2022/1/31 12:31
 * @Author 望轩
 */
public class Rectangle {
    private long height;
    private long width;
    public long getWidth(){
        return width;
    }
    public long getHeight(){
        return height;
    }
    public void setHeight(long height){
        this.height = height;
    }
    public void setWidth(long width){
        this.width = width;
    }
}

有一个正方形类继承长方形类,但是正方形类重写了父类中的非抽象方法setHeight和setWidth,如下:

/**
 * @Date 2022/1/31 12:35
 * @Author 望轩
 */
public class Square extends Rectangle {
    @Override
    public long getWidth() {
        return super.getWidth();
    }

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

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

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

然后写了一个测试类,如下:

/**
 * @Date 2022/1/31 12:37
 * @Author 望轩
 */
public class Test {
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setWidth(20);
        rectangle.setHeight(10);
        resize(rectangle);
    }
    
    //当长方形的宽大于等于高的时候循环,让长方形高加一
    public static void resize(Rectangle rectangle){
        while (rectangle.getWidth() >= rectangle.getHeight()){
            rectangle.setHeight(rectangle.getHeight()+1);
            System.out.println("width:"+rectangle.getWidth()+",height:"+rectangle.getHeight());
            System.out.println("resize方法结束"+"\nwidth:"+rectangle.getWidth()+",height:"+rectangle.getHeight());
        }
    }
  
    
}

当测试类中的resize方法的参数是Rectangle父类的时候,测试方法可以成功执行。那么按照里式替换原则,我们可以把父类替换成它的子类,仍然可以成功的执行,但是当我们把这里的父类对象Rectangle替换成它的子类Square之后,测试方法就不能成功执行了,会出现死循环,因为我们的Square子类覆盖了父类的非抽象方法setHeight和setWidth,导致width和height都是同步变化的,所以while循环会一直循环下去。

因此,根据里式替换原则,子类一定不能覆盖父类的原有的方法,但子类可以增加自己独有的方法。

所以像上面的这种,正方形,长方形的例子,我们要重新写一个接口,把正方形和长方形共有的东西给抽象出去,然后再让正方形,长方形分别重写这个接口,然后实现不同的方法逻辑,如下:

//定义一个四边形接口
public interface Quadrangle{
    void setWidth(long width);
    void setHeight(long height );
}

//正方形实现这个接口
public class Square implements Quadrangle{
    private long width;
    private long height;
    @Override
    void setWidth(long width){
        this.width = width;
        this.height = height;
    }
    @Override
    void setHeight(long height){
        this.height = height;
        this.width = width;
    }
}

//长方形实现这个接口
public class Rectangle implements Quadrangle{
    private long width;
    private long height;
    @Override
    void setWidth(long width){
        this.width = width;
    }
    @Override
    void setHeight(long height){
        this.height = height;
    }
}

标签:long,原则,void,接口,height,width,软件架构,设计,public
来源: https://blog.csdn.net/qq_45950109/article/details/122759672