架构设计原则

开闭原则

开闭原则（Open-Closed Principle, OCP）是指一个软件实体（如类，模块和函数）应该对扩展开放，对修改关闭。

优势：开闭原则强调用抽象构建框架，用实现扩展细节，可以提高软件系统的可复用性及可维护性。

//我的课程（抽象出来）
public interface ICourse {

    Integer getId();
    String getName();
    Double getPrice();

}

//java课程实现课程接口，新增python课程，我只需要新增一个实现类而不修改源码
public class JavaCourse  implements ICourse{

    private Integer Id;
    private String name;
    private Double price;

    public JavaCourse(Integer id, String name, Double price) {
        Id = id;
        this.name = name;
        this.price = price;
    }

    @Override
    public Integer getId() {
        return Id;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public Double getPrice() {
        return price;
    }
}

//java课程优惠继承了java课程，这样我是一直在横向或向下发展功能的
public class JavaDiscountCourse extends JavaCourse{

    public JavaDiscountCourse(Integer id, String name, Double price) {
        super(id, name, price);
    }

    public Double getOriginPrice(){///原价
        return super.getPrice();
    }

    public Double getPrice(){///优惠价
        return super.getPrice() * 0.61;
    }
}

简单来说：开闭原则就是由抽象到实现的过程，这其中抽象层是不动的程序可以不断的向下扩展自己的功能。就像上面的代码，我每新增一个课程只需要再加一个课程的实现类，一个课程的对应优惠类就好了，不需要修改抽象类和源代码。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eDjZpI57-1610680484969)(F:\spring5\笔记\md图片\开闭.png)]

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle, DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。

优势：通过依赖倒置可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的危险。

public interface ICourse {
    void study();
}

//具体的课程我只需要依赖课程抽象类就好了
public class JavaCourse implements ICourse{
    @Override
    public void study() {
        System.out.println("Tom 在学习Java课程");
    }
}

public class PythonCourse implements ICourse{
    @Override
    public void study() {
        System.out.println("Tom 在学习Python课程");
    }
}

public class Tom {

  /* 构造方法注入*/
    private ICourse course;

    public Tom(){
        
    }
    
    public Tom(ICourse course) {
        this.course = course;
    }

    /* set 方法注入*/

    public void setCourse(ICourse course) {
        this.course = course;
    }
    public void study(){
        course.study();
    }

}

简单来说：依赖倒置就是由更下层的实现依赖上层的抽象，下层的实现尽量不要依赖上层的实现。就像上面的实例，我再新学习一门课程我只需要新增一个课程的实现类，我的这个实现类只用依赖课程这一个抽象类就能正常使用。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OVs9yEvE-1610680484976)(F:\spring5\笔记\md图片\依赖倒置.png)]

单一职责原则

单一职责（Simple Responsibility Pinciple, SRP）是指不要存在多余一个导致类变更的原因。

优势：对代码后期需求的变更维护互不影响，降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险

public interface ICourse {
    String getCourseName();

    //获得视频流
    byte[] getCourseVideo();

    //学习课程
    void studyCourse();

    //退款
    void refundCourse();
}

拆分成：

public interface ICourseInfo {
    String getCourseName();
    byte[] getCourseVideo();
}

public interface ICourseManager {
    void studyCourse();
    void refundCourse();
}

简单来说：假设有一个类负责俩个职责，一但发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在俩个导致类变更的原因。将俩个职责用俩个类实现

说明：在实际开发中，项目的规模，周期和技术人员的水平，对进度的把控，所以很多类都不符合单一职责。但是，我们在开发中尽可能的让接口和方法保持单一职责，对项目后期的维护是有帮助的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7EJ5rtzW-1610680484978)(F:\spring5\笔记\md图片\单一职责.png)]

接口隔离原则

接口隔离原则（Interface Segregation Principle,ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖他不需要的接口。

注意一下几点：

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

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

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

优势：接口隔离原则可以使类具有很好的可读性，可扩展性和可维护性。

public class Dog1 implements IEatAnimal,ISwimAnimal{
    @Override
    public void eat() {
        System.out.println("狗吃饭");
    }

    @Override
    public void swim() {
        System.out.println("狗游泳");
    }
}

public interface IEatAnimal {
    void eat();
}

public interface IFlyAnimal {
    void fly();
}

public interface ISwimAnimal {
    void swim();
}

简单来说：我这个类要实现接口的所有方法，而接口中的方法不应该有我不需要的方法存在。就像上面的代码，鸟不应有游泳的方法，这个时候接口就要进行拆分。

迪米特原则

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP）

优势：降低类与类之间的耦合度

public class Course {

}

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

//老板只需要找到团队领导就好，不需要去接触课程
public class Boss1 {
    public void commandCheckNumber(TeamLeader1 teamLeader1){
        teamLeader1.checkNumberOfCourses();
    }
}

简单来说：迪米特原则强调，只和朋友交流，不和陌生人说话。出现在成员变量，方法的输入输出参数中的类都可以称为成员朋友类，而出现在方法体内部的类不属于朋友类。

里氏替换原则

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

注意：

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

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

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

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

优势：

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

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

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法

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

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

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

优势：

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

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

简单来说：儿子继承了父亲的纺织厂公司，也就是说父亲下岗了，换儿子上岗一点不影响厂子的功能。这就是里氏替换原则。