《如何做好软件设计》：设计原则

作者：yangwq
博客：https://yangwq.cn

前言

软件设计是一门关注长期变化的学问，日常开发中需求不断变化，那我们该怎么编写出可以支撑长期变化的代码呢？大多数人都认同的解决方案是利用设计模式，这里就有一个问题：怎么融汇贯通的将设计模式应用到实际项目中呢？这就是我们本篇文章的主题：设计原则。

个人认为设计原则是软件设计的基石之一，所有语言都可以利用设计原则开发出可扩展性、可维护性、可读性高的项目，学好设计原则，就等于我们拥有了指南针，不会迷失在各个设计模式的场景中。

郑晔老师的《软件设计之美》指出：设计模式是在特定问题上应用设计原则的解决方案。我们可以类比设计原则是心法，设计模式是招式，两者相辅相成，虽然脱离对方都能使用，但是不能融会贯通。

本章主要涉及的设计原则有：

1. SOLID原则
2. KISS原则、YAGNI原则、DRY原则

接下来对各个原则进行详细说明，有错误或语义不明确的地方欢迎大家指正。

一、SOLID原则

1. S(Single Responsibility Principle，SRP)：单一职责原则；
2. O(Open–closed principle，OCP)：开放-关闭原则；
3. L(Liskov Substitution Principle，LSP)：里氏替换原则；
4. I(Interface segregation principle，LSP)：接口隔离原则；
5. D(Dependency inversion principle, DIP)：依赖倒置原则。

1、单一职责原则（Single Responsibility Principle，SRP）

本原则的定义经历过一些变化。以前的定义是：一个模块（模块、类、接口）仅有一个引起变化的原因，后面升级为： 一个模块（模块、类、接口）对一类且仅对一类行为者负责。

怎么理解一个模块（模块、类、接口）仅有一个引起变化的原因？

我们重点关注的是“变化”一词。下面我们用代码来进行示例：

背景：设计一个订单接口，能做到创建、编辑订单和会员的赠送及过期。

public interface OrderService {
    int createOrder();
    int updateOrder();
    
    // 下单完成后分配vip给用户
	int distributionVIP();
	// vip过期
	int expireVIP();
}

OrderService包含对订单、VIP的操作，不管是订单业务或VIP业务的改变，我们都需要改变这个类。这样有什么问题？有多个引起OrderService变化的原因导致这个类不能稳定下来，对VIP代码的改动有可能导致原本运行正常的订单功能发生故障，没有做到高内聚、低耦合。

一个模块最理想的状态是不改变，其次是少改变。我们可以将对VIP的处理单独放到一个类：

public interface OrderService {
    int createOrder();
    int updateOrder();
    
}

public interface VIPService{
    // 下单完成后分配vip给用户
	int distributionVIP();
	// vip过期
	int expireVIP();
}

这样我们对订单或VIP的改动都不会影响到对方正常的功能，极大程度上减少了问题发生的概率。

该怎么理解一个模块（模块、类、接口）对一类且仅对一类行为者负责？

这个定义比上面的定义多加了一个内容：变化的来源。

上面的例子可能区分不出来变化的来源，像vip这类功能一般都是订单系统体系内的。从下面这个例子说明:

背景：在上面例子的背景下，增加对地址信息的维护。

public interface OrderService {
    int createOrder();
    int updateOrder();
    
	// 订单地址的修改
	int updateOrderAddress();
}

OrderService中对订单地址的修改，可能是订单负责人提出的需求，也可能是物流部门提出来：需要共用订单地址。

这里就需要区分两种业务场景。

如果是订单负责人提出的，那上面这个设计就是合理的，因为我们维护的是订单附属内容，而且变化的来源只有订单系统。

但如果是物流部门提出共用订单地址，那就需要将更改地址的接口抽离出来，因为这个需求变化的来源有两拨人：可能是订单，也可能是物流部门。改动如下：

public interface OrderService {
    int createOrder();
    int editOrder();
}

public interface AddressService {
    // 订单修改地址
	int updateAddressByOrder();
	
	// 物流修改地址
	int updateAddressByLogistics();
}

为了职责明确我们有对接口的命名进行重构，这样更容易被使用者接受，通过将地址的变化隔离在AddressService，后续维护地址只用修改这个类，提升了代码的可读性和可维护性。

2、开放-关闭原则（Open–closed principle，OCP)

定义：对扩展开放，对修改关闭。简而言之: 不修改已有代码（尽可能不更改已有代码的情况下），新需求用新代码实现。

如何做到？分离关注点，找出共性构建模型/抽象，设计扩展点。

代码示例：

背景：设计一套通用的文件上传下载功能，需要支持本地盘和阿里云OSS。一开始的设计可能是这样的：

public void FileUtil {
	
	void upload(UploadParam uploadParam) {
		if(type == 1){
			// 上传文件到本地盘
		}else if (type == 2){
			// 上传文件到阿里云OSS
		}
	}
	
	void download(DownloadParam downloadParam){
		if(type == 1){
			// 从本地盘下载文件
		}else if (type == 2){
			// 从阿里云OSS下载文件
		}
	}
}

上面的设计有什么问题？首先第一点UploadParam 和 DownloadParam 参数职责过重，不同方式的上传、下载参数混合在一个类，可读性不高，而且加入其他存储方式的时候可能只加了上传，漏掉了下载的改动，容易产生问题。

那我们先通过分离关注点：不同存储方式都需要提供对应的上传、下载操作。于是我们可以将动作拆分成上传、下载，参数需要按不同场景选用不同的对象。改动后如下：

// 所有参数的父类接口
public interface BaseFileParam{
	
}

// 统一的上传下载接口类
public  interface FileService<U,D>{
    
    /**
     * 上传
     */
    void upload();

    /**
     * 下载
     */
    void  download();

}

// 抽象实现，将参数作为属性放到类中，子类可以使用
public abstract class AbstractFileService<U,D> implements FileService<U,D>{
    protected U uploadParam;
    protected D downloadParam;

    public AbstractFileService() {
    }

    protected FileService<U, D> buildUploadParam(U uploadParam){
        this.uploadParam = uploadParam;
        return this;
    }
    
    protected FileService<U, D> buildDownloadParam(D downloadParam){
        this.downloadParam = downloadParam;
        return this;
    }
    
    protected U getUploadParam() {
        return uploadParam;
    }

    protected D getDownloadParam() {
        return downloadParam;
    }
}



// OSS实现
public class OssFileServe extends AbstractFileService<OssFileServe.OssUpload, OssFileServe.OssDownload> {

    /**
     * 上传到阿里云
     */
    @Override
    public void upload() {

    }

    /**
     * 从阿里云下载文件
     */
    @Override
    public void download() {

    }

    public class OssUpload implements BaseFileParam{

    }

    public class OssDownload implements BaseFileParam{

    }

}

// 本地盘实现
public class LocalFileService extends AbstractFileService<LocalFileService.LocalFileUploadParams, LocalFileService.LocalFileDownloadParams> {

    /**
     * 上传到本地磁盘
     */
    @Override
    public void upload() {

    }

    @Override
    public void download() {

    }

    public static class LocalFileUploadParams implements BaseFileParam {

    }

    public static class LocalFileDownloadParams implements BaseFileParam {

    }
}



// 使用入口
public class FileServiceDelegate {

    public FileService<? extends BaseFileParam,? extends BaseFileParam> getFileService(String type, BaseFileParam upload, BaseFileParam download){
        if("local".equals(type)){
           return new LocalFileService().buildUploadParam(upload != null ? (LocalFileService.LocalFileUploadParams) upload : null)
                   .buildDownloadParam(download != null ? (LocalFileService.LocalFileDownloadParams) download : null);
        }else if ("oss".equals(type)) {
            return new OssFileServe().buildUploadParam(upload != null ? (OssFileServe.OssUpload) upload : null)
                    .buildDownloadParam(download != null ? (OssFileServe.OssDownload) download : null);
        }else {
            throw new RuntimeException("未知的上传类型");
        }
    }

    public void upload(String type, BaseFileParam baseFileParam){
        getFileService(type,baseFileParam, null).upload();
    }

    public void download(String type, BaseFileParam baseFileParam){
        getFileService(type,null, baseFileParam).download();
    }
}

以上是比较粗糙的方案，只做案例演示。后续如果需要加入亚马逊S3存储，我们需要改动的点：

// 加入S3实现
public class S3FileService extends AbstractFileService<S3FileService.S3UploadParams, S3FileService.S3DownloadParams> {

    /**
     * 上传到S3
     */
    @Override
    public void upload() {

    }

    /**
     * 从S3下载文件
     */
    @Override
    public void download() {

    }

    public class S3UploadParams implements BaseFileParam {

    }

    public class S3DownloadParams implements BaseFileParam {

    }
}

// 修改入口类
public class FileServiceDelegate {

    public FileService<? extends BaseFileParam,? extends BaseFileParam> getFileService(String type, BaseFileParam upload, BaseFileParam download){
        if("local".equals(type)){
           return new LocalFileService().buildUploadParam(upload != null ? (LocalFileService.LocalFileUploadParams) upload : null)
                   .buildDownloadParam(download != null ? (LocalFileService.LocalFileDownloadParams) download : null);
        }else if ("oss".equals(type)) {
            return new OssFileServe().buildUploadParam(upload != null ? (OssFileServe.OssUpload) upload : null)
                    .buildDownloadParam(download != null ? (OssFileServe.OssDownload) download : null);
        }
        // 加入S3处理
        else if("s3".equals(type)){
            return new S3FileService().buildDownloadParam(upload != null ? (S3FileService.S3DownloadParams) upload : null)
                    .buildDownloadParam(download != null ? (S3FileService.S3DownloadParams) download : null);

        }else {
            throw new RuntimeException("未知的上传类型");
        }
    }

    public void upload(String type, BaseFileParam baseFileParam){
        getFileService(type,baseFileParam, null).upload();
    }

    public void download(String type, BaseFileParam baseFileParam){
        getFileService(type,null, baseFileParam).download();
    }
}

上面我们修改了两个地方，一个是加入了S3的实现类，另一个是更改入口类加入了S3的处理，这就符合新功能用新代码实现，但可能有人说改动了入口类，其实只要改动的代码没有影响到原有的功能，小幅度的修改是可以接受的。

3、里氏替换原则(Liskov Substitution Principle，LSP)

定义：子类必须能够替换其父类，并保证原来程序的逻辑行为不变及正确性不被破坏。

如何实现？站在父类的角度设计接口，子类需要满足基于行为的IS-A关系，更具体的来讲：子类遵守父类的行为约定，约定包含：功能主旨，异常，输入，输出，注释等。

违背功能主旨：

public interface OrderService {
    Order updateById(Order order);
}

public class OrderServiceImpl {
    public Order findById(Order order) {
        // 实际上是通过订单编号进行更新的
        return orderMapper.updateBySn(order);
    }
}

父类的定义原本是按订单ID更新，在子类实现中却变成了按订单编号更新，这个方法就违背了功能主旨。会出现什么问题？使用者会发现执行结果与自己期望的不一致，而且有隐藏BUG：一开始传了订单编号，后面订单编号没了，这个方法就报错了，更严重一点，如果是使用mybatis的xml判断了编号不为空进行条件拼接，此时由于编号为空就没有了条件过滤然后更改了整个表的数据。

异常：父类规定接口不能抛出异常，而子类抛出了异常。

输入：父类输入整数类型就行，子类要求正整数才能执行。

输出：父类执行方法要求有异常时返回null,子类重写后直接将异常抛出来了。

关于里氏替换原则，我们就只要记住一点：从父类角度设计行为一致的子类。

4、接口隔离原则（Interface segregation principle，LSP）

定义：不应强迫使用者依赖于它们不用的方法。 通俗的理解：对接口设计应用单一职责，根据调用者设计不同的接口。

示例：

public class UserController{
    
    int addUser(User user);
    int updateUser(User user);
    int deleteUser(int id);
    // 锁定用户
    int lockUser(User user);
}

上面是一个对订单crud的接口，现在有其他项目组的同事需要锁定用户的功能，然后你可能一拍脑袋直接把上面整个接口UserController扔给他（或者直接扔一个swagger文档），这样同事会很懵逼：我只要锁定用户就行，为什么还要这么多接口？

这样做暴露的问题:

1. 调用者关注了不需要的接口；
2. 多余的接口暴露出来容易问题，每次更改接口你也不知道会不会影响其他模块的功能。

所以我们尽量要最小化暴露接口，根据不同的调用者仅提供他们当前需要的接口，提供的公共接口越多越难以维护。

接口隔离原则与单一职责的区别：

1、单一职责要求的的是模块、类、接口的职责单一，

2、接口隔离原则要求的是暴露给使用者的接口尽可能少。

可以这么理解：一个类某个职责有10个接口都暴露给其他模块使用，按单一原则来讲是合理的，但是按接口隔离来讲是不允许的。

5、依赖倒置原则(Dependency inversion principle, DIP)

定义：高层模块不直接依赖底层模块，依赖于抽象，底层模块不依赖于细节，细节依赖于抽象。

这一点如果我们是使用spring开发的项目就已经用到了。spring的依赖注入就是依赖倒置原则的体现。

// 以前没有使用spring的时候，我们是这样初始化service的
// 存在的问题：1、如果需要替换成一个新的实现类，改动点太多，简单点说就是高耦合；
// 2、使用者不需要关注具体的实现类，只关注有哪些接口能用就行；
// 3、对象实例不能共享，每个使用的地方都是新建的实例，实际上用同一个实例就行了。
UserService userService = new UserServiceImpl();

通过spring的IOC容器，我们只要定义好依赖关系，IOC容器就可以帮我们管理对应的实例，起到了松耦合的作用。

还有其他的使用场景吗？

有，举例：

public class UserServiceImpl {
    private KafkaProducer producer;
    
    public int addUser(User user){
        // 创建用户
        
        // 发送消息到消息队列，由感兴趣的系统订阅并消费。
        producer.send(msg);
    }
}

这里初看没有什么问题，但如果后续我们更换了kafka为rabbitmq，那上面使用到kafka的类都需要重新调整。

我们利用"高层模块不直接依赖底层模块，依赖于抽象"对上面代码进行调整，让我们的实现类UserServiceImpl不直接依赖KafkaProducer，而是依赖接口类MessageSender。

public class UserServiceImpl {
    private MessageSender sender;
    
    public int addUser(User user){
        // 创建用户
        
        // 发送消息到消息队列，由感兴趣的系统订阅并消费。
        sender.send(msg);
    }
}

public interface MessageSender {
    void send(Map<String,String> params);
}

// kafka 实现
public class KafkaProducer implements MessageSender{
    public void send(Map<String,String> params) {
        
    }
}

这样一来，就算我们切换成RabbitMq，改动的点无非是对MessageSender实现的更改，而有了spring的IOC容器，我们很容易就可以更改实例实现。

// rabbitmq 实现
public class RabbitmqProducer implements MessageSender{
    public void send(Map<String,String> params) {
        
    }
}

控制反转：控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里的控制指的是程序执行流程的控制，反转是从程序员变为框架控制。

依赖注入：一种具体的编码技巧，不直接使用new创建对象，而是在外部将对象创建好后通过构造函数、方法、方法参数传递给类使用。

二、KISS原则、YAGNI原则、DRY原则

这三个原则是偏理论性的概念，主要目的是指导我们学习设计原则后不要过度设计。

KISS（Keep it simple, stupid）原则

定义： 尽量保持简单。保持简单可以让我们的代码可读性更高，维护起来也更容易。但这是一个比较抽象的概念：对于“简单”的定义没有统一规范，每个人的理解都不一致，这个时候就需要code review，同事有很多疑问的代码就要考虑是不是代码不够“简单”。

实践过程中怎么编写满足KISS原则的代码？以下几点供大家参考：

1. 不要重复造轮子，复用已有的工具；
2. 方法写得越小越好；
3. 不要使用同事可能不懂的技术来实现代码。

YAGNI（You aren’t gonna need it）原则

定义： 你不会需要它。我们可以这样理解：如非必要，勿增功能。

这一个原则我们可以用在两个方面：需求和代码实现。

对于产品人员提出的需求，按照二八原则，80%的功能是用不上的，所以我们可以不做对用户没有价值的需求。

对于开发人员的代码实现，除非编写的模块以后会频繁变化，这种情况我们可以提前构建扩展点，但如果模块变化很少，我们就不需要做过多的扩展点，保持功能正常运行就行。

KISS原则和YAGNI原则区别：

KISS原则关注的怎么做，YAGNI原则关注的是需不需要做。

DRY（Don’t repeat yourself）原则：

定义：不要重复自己。广泛的认知是不写重复代码，更深入一点的理解是不要对你的知识和意图进行复制。

在我看来：解决重复代码是每个程序员都会做的事情，但是重复的代码一定要解决吗？首先要明白解决重复代码的重点是建立抽象，那这个抽象有没有存在的意义？我们应该根据实际的业务场景，如果发现引起该抽象改变的原因超过一个，这说明该抽象没有存在的意义。

例如，我们开发crud接口中常见的VO和Entity：

public class UserEntity {
    private String username;
    private String name;
    private Integer age;
    private String password;
}

public class UserVO {
    private String username;
    private String name;
    private Integer age;
    // 用户拥有的菜单
    private List menuList;
}

我们如果按DRY原则将重复的代码合并到一个类：

public class BaseUser{
    private String username;
    private String name;
    private Integer age;
    private String phone;
}
public class UserEntity extends BaseUser{
    private String password;
}

public class UserVO {
    // 用户拥有的菜单
    private List menuList;
}

改成这样会有什么问题？如果后续UserVO不允许暴露age属性或者需要对手机号加密，这个时候就需要改动BaseUser和UserEntity，对UserVO的维护就会改动到BaseUser和UserEntity，一方面违反了单一职责，另一方面需要对发现所有使用BaseUser、UserEntity、UserVO的地方进行测试，增加了维护成本。

基于以上考虑，我们需要将对UserVO的改动隔离起来：还原成刚开始重复代码的场景。

实行DRY原则的方式:

三次法则(Rule of Three)：

1. 第一次先写了一段代码，不考虑复用性；

2. 第二次在另一个地方写了一段相同的代码，可以标记为需清除重复代码，但是暂不处理；

3. 再次在另一个地方写了同样的代码，现在可以考虑解决重复代码了。

总结

本篇的宗旨是给大家树立一个观点：设计原则是设计模式的基础，而不是设计模式的附属物。设计模式是在特定问题应用设计原则的解决方案。但是只用设计原则开发软件离目标是有偏差的，所以我们也要借鉴设计模式：熟悉不同场景下设计原则的使用方式，这样才能开发出可扩展性、可维护性、可读性高的软件。

本篇文章如有错误或语义不明确的地方欢迎大家指正。