软件架构设计原则

一、开闭原则

开闭原则（Open-Closed Principle，OCP），是指对一个软件实体（如类、模块和函数）应该对于扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。它强调的是用抽象构建框架，用实现扩展细节，可以提高软件软件系统的可重复性及可维护性。开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定、灵活的系统。

代码示例：

课程接口

/**
 * @author xxbb
 */
public interface ICourse {
    Integer getId();
    String getName();
    Double getPrice();
}

/**
 * @author xxbb
 */
public class JavaCourse implements ICourse{
    private Integer id;
    private String name;
    private Double price;

    public JavaCourse(Integer id, String name, Double price) {
        this.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;
    }
}

package gp.ocp;

/**
 * @author xxbb
 */
public class JavaDiscountCourse extends JavaCourse{
    public JavaDiscountCourse(Integer id, String name, Double price) {
        super(id, name, price);
    }

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

    /**
     * 不符合里氏替换原则，父类的方法到子类后内容被修改，无法里氏替换，也违背了开闭原则
     * @return price
     */
    @Override
    public Double getPrice(){
        return super.getPrice()*0.76;
    }
}

二、依赖倒置原则

依赖导致原则（Dependence Inversion Principle，DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖其细节，细节应该依赖抽象。 通过依赖倒置，可以减少类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。

代码示例：
初始类:

public class Tom {
    public void studyJava(){
        System.out.println("Tom在学习java");
    }
    public void studyPython(){
        System.out.println("Tom在学习python");
    }
}

调用：

public static void main(String[] args) {
        Tom tom=new Tom();
        tom.studyJava();
        tom.studyPython();
    }

假设这时Tom学习了更多的课程，那么我们就需要去修改底层代码了，因此我们为课程创建接口，Tom的学习依赖接口，具体细节由依赖抽象接口的实现类来决定

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 {
    public void study(ICourse course){
        course.study();
    }
    public static void main(String[] args) {
        Tom tom=new Tom();
        //此时course为输入参数，属于成员朋友类，符合迪米特原则
	    tom.study(new JavaCourse());
    }
}

这种方式也就是依赖注入，不修改底层代码，通过依赖抽象接口的方式，传入不同的实现类来改变实现的细节。如果我们将ICourse作为Tom的成员变量时，可以通过构造器注入或者Set注入实现Tom的不同行为

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

三、单一指责原则

单一职责原则（Simple Responsibility Principle，SRP）是指不要存在多于一个导致类发生变更地原因。假设我们有一个类负责两个职责，一旦需求发生了变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生变化，这样一来，就存在一个类中有两个导致类变更的原因了。解决方法：用两个分别实现两个职责，进行解耦，后期需求变更维护就不会相互影响。这样设计可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更类引起的风险。总体来说，就是一个类、接口或方法只负责一项职责

课程区分直播课和录播课，直播课不能快进，录播课可以反复观看。

public class Course {
    public void study(String courseName){
        if("zb".equals(courseName)){
            System.out.println(courseName+"不能快进！！！");
        }else if("lb".equals(courseName)){
            System.out.println(courseName+"可以反复观看！！！");
        }
        
    }
}

加入此时我们要对直播课程进行加密，加密逻辑可能会影响到录播课代码（没有影响的例子），可以对职责进行解耦，新建两个类，可以建一个Course接口

public interface Course {
    void study(String courseName);
}
public class LiveCourse implements Course{
    @Override
    public void study(String courseName) {
        System.out.println(courseName+"直播课不可快进");
    }
}
public class ReplayCourse implements Course{
    @Override
    public void study(String courseName) {
        System.out.println(courseName+"录播课可以反复观看");
    }
}

随着业务发展，课程需要做权限，一是获取课程信息的权限，二是获取视频流的权限（vip），那么在控制课程层面至少需要两个权限，一个课程信息接口，一个课程权限接口

public interface ICourseInfo {
    String getCourseName();
}
public interface ICourseManager {
    byte[] getCourseVideo();
    void studyCourse();
    void refund();
}

对于方法，比如验证账号密码，我们可以在一个方法里传入账号密码一起验证，也可以单独设两个方法分别验证账号密码。

单一职责原则要求我们尽可能让接口和方法保持单一职责，比如在smybatis中的Executor类中，使用了parameter、statement、resultSet三个类来分别处理sql语句、参数和结果集，这里Executor类依赖这三个了类，但这三个类都是在类里面方法里实例化的，不满足迪米特原则。

四、接口隔离原则

接口隔离原则（Interface Segregation Principle,ISP）是指多个专门的接口，不使用总接口，比如上面的课程内容和课程权限分开，客户端不应该依赖它不需要的接口。在这个原则下指导我们设计接口时需要注意以下几点：

• 一个类对另一个类的依赖应该建立在最小的接口之上
• 建立单一接口，不要建立庞大臃肿的接口
• 尽量细化接口，接口中的方法尽量少（适度少），感觉2，3点意思相近，递进

接口隔离原则符合我们常说的高内聚，低耦合的设计思想，可以使类具有良好的可读性、可扩展性和可维护性。我们在设计接口时，要多花时间思考，要考虑业务模型，包括对未来可能发生变更的地方进行预判

代码示例：

public interface Animal {
    void eat();
    void run();
    void swin();
    void fly();
}

假如有dong类，那么它不需要fly和swim，假如有bird类，不需要swim，为此我们需要接口细分

public interface EatAnimal {
    void run();
}
public interface FlyAnimal {
    void fly();
}
public interface SwimAnimal {
    void swim();
}

一般动物继承eat和一个动作接口。

单一职责和接口隔离有些类似，都会要求接口上的细分，避免一个类或接口处理的内容过于复杂，单一职责偏重于一种事物的抽象类的不同功能需要细分不同职责，接口隔离偏重于一类抽象事物的属性不一定是每个实现类都需要的，所以需要接口隔离，实现类继承需要的接口。接口隔离针对抽象事物，单一职责针对更具体点的事物。

单一职责针对具体类的功能划分，希望功能尽可能单一化，接口隔离原则针对抽象类的具体化，希望抽象类的方法能具体化一点，侧重点是依赖关系，保证接口被继承时不会出现没被被使用到的方法

五、迪米特原则

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

设计一个权限系统，Boss需要查看发布到线上的课程数量，需要TeamLeader类进行统计，由它把结果反馈给Boss。

public class Course {
}
public class TeamLeader {
    public void checkNums(List<?> list){
        System.out.println("number:"+list.size());
    }
}
public class Boss {
    public void getNums(TeamLeader tl){
        //模拟boss查看课程，由team leader统计
        List<Course> courses=new ArrayList<>(20);
        for(int i=0;i<20;i++){
            courses.add(new Course());
        }
        tl.checkNums(courses);
    }
}

Boss本来只需要知道course的数量，但这里boss又承担了与course交互的过程，实际上这些事情交给TeamLeader去做就可以了

修改代码

public class Boss {
    public void getNums(TeamLeader tl){
        tl.checkNums();
    }
}
public class TeamLeader {
    public void checkNums(){
        List<Course> courses=new ArrayList<>(5);
        for(int i=0;i<20;i++){
            courses.add(new Course());
        }
        System.out.println("number:"+courses.size());
    }
}

六、里氏替换原则

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

可以理解为如果一个软件实体适用于其父类，那么一定适用于其子类，所有引用父类的地方必须能够透明的使用其子类对象，即子类对象能偶替换父类对象，而程序逻辑不变。

根据这个理解，引申含义为：子类可以扩展父类的功能，但不能改变父类原有的功能。

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

在开闭原则代码中已经提到了子类getPrice方法对父类方法内容的修改，如果子类需要获取打折后价格应该是添加一个getDiscountPrice方法

使用里氏替换原则有以下有点：

1.约束继承泛滥，是开闭原则的一种体现。（约束继承类不允许对原方法进行改写，避免继承过多时出现不可预知的情况，保证继承类的同名方法提供的功能是相同的）

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

描述一个经典的业务场景，用正方形、矩形和四边形的干系说明里氏替换原则，正方形时特殊的矩形，我们先创建一个矩形父类

public class Rectangle {
    private long height;
    private long width;
}
public class Square extends Rectangle{
    private long length;
}
public class Test {
    /**
     * 将矩形变成正方形
     * @param 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("over");
    }
}

这个例子举得不好，书上说当传入正方形时会出现死循环，用来说明将父类替换成子类后程序结果未达到预期，违背里氏替换原则，其实不然

修改：

public interface Quadrangle {
    long getWidth();
    long getHeight();
}
public class Rectangle implements Quadrangle{
    private long height;
    private long width;

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

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

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

    public void setWidth(long width) {
        this.width = 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 getWidth() {
        return length;
    }

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

这样正方形时实现了四边形接口，重写接口的获取长宽的方法，让他们返回边长length，避免了继承Rectangle类后修改其获取长宽方法而违背里氏替换原则。

此时我们如如果把resize方法的参数换成Quadrangle接口，那么参数会报错，因为square类中已经没有设置长宽的方法，从而约束了继承的泛滥，使得resize()方法只能作用域Rectangle类。

七、合成复用原则

合成复用原则（Composite / Aggreate Reuse Principle,CARP ）是指尽量使用对象组合（has-a）/聚合（constanis-a）而不是继承关系达到软件复用的目的，可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对于其他类造成的影响相对较少。

继承叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合称为黑箱复用，我们是无法获取到类以外的对象的实现细节的。虽然我们要根据具体的业务场景来做代码设计，但也需要遵循OOP模型。

以数据库操作为例

public class DbConnection {
    public String getConnection(){
        return "mysql数据库连接";
    }
}
public class ProductDao {
    private DbConnection dbConnection;

    public DbConnection getDbConnection() {
        return dbConnection;
    }

    public void setDbConnection(DbConnection dbConnection) {
        this.dbConnection = dbConnection;
    }
    public void addProduct(){
        String conn=dbConnection.getConnection();
        System.out.println("使用"+conn+"增加了产品");
    }
}

这是典型的合成复用的应用场景，其中的DbConnection类是成员变量也就属于成员朋友类，符合迪米特原则。但是不够抽象，只能满足mysql数据库情况，故我们将连接对象抽象

public abstract class BaseDbConnection {
    public abstract String getConnection();
}
public class MySQLConnection extends BaseDbConnection{
    @Override
    public String getConnection() {
        return "mysql";
    }
}
public class OracleConnection extends BaseDbConnection{
    @Override
    public String getConnection() {
        return "Oracle";
    }
}

八、设计原则总结

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