学会这10个设计原则，离架构师又进了一步！！！

心已赠人 2022-10-17 01:39 11阅读 0赞

> 知识分享，以技会友。大家好，我是Tom哥。阅读本文大约需要 15 分钟。

闲言碎语：

一个懂设计原则的程序猿，写出来的代码可扩展性就是强，后续的人看代码如沐春风。相反，如果代码写的跟流水账似的，完全一根筋平铺下来，后续无论换谁接手维护都要骂娘。

做软件开发多年，`CRUD`仿佛已经形成一种惯性，深入骨髓，按照常规的结构拆分：`表现层`、`业务逻辑层`、`数据持久层`，一个功能只需要个把小时代码就撸完了。

再结合`CTRL+C`和`CTRL+V` 绝世秘籍，一个个功能点便如同雨后春笋般被快速克隆实现。

**是不是有种雄霸天下的感觉，管他什么业务场景，大爷我一梭到底，天下无敌！！！**

![beee556b5545305213da9edb25319ae2.png][]

**可现实真的是这样？**

答案不言而喻！！！

初入软件行业，很多人都会经历这个阶段。时间久了，很多人便产生困惑，能力并没有随着工作年限得到同比提升，焦虑失眠，如何改变现状？

悟性高的人，很快能从一堆乱麻中找到线索，并不断的提升自己的能力。

**什么能力？**

当然是软件架构能力，一名优秀的软件架构师，要具备复杂的业务系统的`吞吐设计能力`、`抽象能力`、`扩展能力`、`稳定性`。

**如何培养这样能力?**

![79f3654d4d38a5ea232cdddfab75897c.png][]

**我将常用的软件架构原则，做了汇总，目录如下：**

![1994d12c7ec875597993f944d22321ea.png][]

当然这些原则有些是相互辅助，有些是相互矛盾的。实际项目开发中，要根据具体业务场景，灵活应对。`千万不能教条主义，生搬硬套`

##  ##

单一职责

> 我们在编码的时候，为了省事，总是喜欢在一个类中添加各种各样的功能。未来业务迭代时，再不断的修改这个类，导致后续的维护成本很高，耦合性大。牵一发而动全身。

为了解决这个问题，我们在架构设计时通常会考虑`单一职责`

**定义：**

单一职责（SRP：Single Responsibility Principle），面向对象五个基本原则（SOLID）之一。每个功能只有一个职责，这样发生变化的原因也会只有一个。通过`缩小职责范围`，尽量减少错误的发生。

单一职责原则和一个类只干一件事之间，最大的差别就是，将变化纳入了考量。

**代码要求：**

一个接口、类、方法只负责一项职责，简单清晰。

**优点：**

降低了类的复杂度，提高类的可读性、可维护性。进而提升系统的可维护性，`降低变更引起的风险`。

**示例：**

有一个用户服务接口`UserService`，提供了用户注册、登录、查询个人信息的方法，主要还是围绕用户相关的服务，看似合理。

public interface UserService{
        // 注册接口
        Object register(Object param);
        // 登录接口
        Object login(Object param);
        // 查询用户信息
        Object queryUserInfoById(Long uid);
    }

过了几天，业务方提了一个需求，用户可以参加项目。简单的做法是在`UserService`类中增加一个`joinProject()`方法

又过了几天，业务方又提了一个需求，统计一个用户参加过多少个项目，我们是不是又在`UserService`类中增加一个`countProject()`方法。

这样导致的后果是，`UserService`类的职责越来越重，类会不断膨胀，内部的实现会越来越复杂。既要负责用户相关还有负责项目相关，后续任何一块业务变动，都会导致这个类的修改。

两类不同的需求，都改到同一个类。正确做法是，把不同的需求引起的变动拆分开，单独构建一个`ProjectService`类，专门负责项目相关的功能

public interface ProjectService{
        // 加入一个项目
        void addProject (Object param);
        // 统计一个用户参加过多少个项目
        void countProject(Object param);
    }

这样带来的好处是，用户相关的需求只要改动`UserService`。如果是项目管理的需求，只需要改动`ProjectService`。二者各自变动的理由就少了很多。

开闭原则

开闭原则（OCP：Open-Closed Principle），主要指一个类、方法、模块 等 **对扩展开放，对修改关闭**。简单来讲，一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

**个人感觉，开闭原则在所有的原则中最重要，像我们耳熟能详的23种设计模式，大部分都是遵循开闭原则，来解决代码的扩展性问题。**

**实现思路：**

采用抽象构建框架主体，用实现扩展细节。不同的业务采用不用的子类，尽量避免修改已有代码。

**优点：**

*  可复用性好。在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。
 *  可维护性好。它的底层抽象相对固定，不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。

**示例：**

比如有这样一个业务场景，我们的电商支付平台，需要接入一些支付渠道，项目刚启动时由于时间紧张，我们只接入`微信支付`，那么我们的代码这样写：

class WeixinPay {
        public Object pay(Object requestParam) {
            // 请求微信完成支付
            // 省略。。。。
            return new Object();
        }
    }

随着业务扩展，后期开始逐步接入一些其他的支付渠道，比如`支付宝`、`云闪付`、`红包支付`、`零钱包支付`、`积分支付`等，要如何迭代？

class PayGateway {
        public Object pay(Object requestParam) {
    
            if(微信支付){
                // 请求微信完成支付
                // 省略。。。。
            }esle if(支付宝){
                // 请求支付宝完成支付
                // 省略。。。。
            }esle if(云闪付){
                // 请求云闪付完成支付
                // 省略。。。。
            }
             // 其他，不同渠道的个性化参数的抽取，转换，适配
             // 可能有些渠道一次支付需要多次接口请求，获取一些前置准备参数
             // 省略。。。。
            return new Object();
        }
    }

所有的业务逻辑都集中到一个方法中，每一个支付渠道本身的业务逻辑又相当复杂，随着更多支付渠道的接入，`pay`方法中的代码逻辑会越来越重，维护性只会越来越差。每一次改动都要回归测试所有的支付渠道，劳民伤财。那么有没有什么好的设计原则，来解决这个问题。我们可以尝试按**开闭原则**重新编排代码

首先定义一个支付渠道的抽象接口类，把所有的支付渠道的骨架抽象出来。**设计一系列的插入点，并对若干插入点流程关联。**

> 关于插入点，用过OpenResty的同学都知道，通过set\_by\_lua、rewrite\_by\_lua、body\_filter\_by\_lua 等不同阶段来处理请求在对应阶段的逻辑，有效的避免各种衍生问题。

abstract class AbstractPayChannel {
        public Object pay(Object requestParam) {
            // 抽象方法
        }
    }

逐个实现不同支付渠道的子类，如：`AliayPayChannel`、`WeixinPayChannel`，每个渠道都是独立的，后期如果做渠道升级维护，只需修改对应的子类即可，降低修改代码的影响面。

class AliayPayChannel extends  AbstractPayChannel{
        public Object pay(Object requestParam) {
            // 根据请求参数，如果选择支付宝支付，处理后续流程
            // 支付宝处理
        }
    }
    class WeixinPayChannel extends  AbstractPayChannel{
        public Object pay(Object requestParam) {
            // 根据请求参数，如果选择微信支付，处理后续流程
            // 微信处理
        }
    }

总调度入口，遍历所有的支付渠道，根据`requestParam`里的参数，判断当前渠道是否处理本次请求。

当然，也有可能采用`组合支付`的方式，比如，`红包支付`\+`微信支付`，可以通过上下文参数，传递一些中间态的数据。

class PayGateway {
    
        List<AbstractPayChannel> payChannelList；
    
        public Object pay(Object requestParam) {
            for(AbstractPayChannel channel:payChannelList){
                channel.pay(requestParam);
            }
        }
    }

里氏替换

里氏替换原则（LSP：Liskov Substitution Principle）：所有引用基类的地方必须能透明地使用其子类的对象

简单来讲，子类可以扩展父类的功能，但不能改变父类原有的功能（如：不能改变父类的入参，返回），跟面向对象编程的`多态性`类似。

> 多态是面向对象编程语言的一种语法，是一种代码实现的思路。而里氏替换是一种设计原则，是用来指导继承关系中子类如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。

**实现思路：**

*  子类可以实现父类的抽象方法
 *  子类中可以增加自己特有的方法。
 *  当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
 *  当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

接口隔离

接口隔离原则（ISP：Interface Segregation Principle）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含调用方感兴趣的方法，而不应该强迫调用方依赖它不需要的接口。

**实现思路：**

*  接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
 *  为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
 *  结合业务，因地制宜。每个项目或产品都有特定的环境因素，环境不同，接口拆分的标准就不同，需要我们有较强的业务 sense
 *  提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

**示例：**

用户中心封装了一套`UserService`接口，给上层调用（业务端以及管理后台）提供用户基础服务。

但随着业务衍化，我们需要提供一个删除用户功能，常规的做法是直接在`UserService`接口中增加一个`deleteById`方法，比较简单。

但这样会带来一个安全隐患，如果该方法被普通权限的业务方误调用，容易导致误删用户，引发灾难。

**如何避免这个问题，我们可以采用****`接口隔离`的原则**

定义一个全新的接口服务，并提供`deleteById`方法，`BopsUserService`接口只提供给Bops管理后台系统使用。

public interface BopsUserService{
        // 删除用户
        Object deleteById(Long uid);
    }

总结一下，在设计微服务接口时，如果其中一些方法只限于部分调用者使用，我们可以将其拆分出来，独立封装，而不是强迫所有的调用方都能看到它。

依赖倒置

软件设计中的细节具有多变性，**但是抽象相对稳定**，为了利用好这个特性，我们引入了依赖倒置原则。

依赖倒置原则（DIP：Dependence Inversion Principle）：高层模块不应直接依赖低层模块，二者应依赖于抽象；**抽象不应该依赖实现细节；而实现细节应该依赖于抽象。**

> 依赖倒置原则的主要思想是要面向接口编程，不要面向具体实现编程。

**示例：**

定义一个消息发送接口`MessageSender`，具体的实例Bean注入到`Handler`，触发完成消息的发送。

interface MessageSender {
      void send(Message message);
    }
    
    class Handler {
    
      @Resource
      private MessageSender sender;
      
      void execute() {
         sender.send(message);
      }
    }

假如消息的发送采用`Kafka`消息中间件，我们需要定义一个`KafkaMessageSender`实现类来实现具体的发送逻辑。

class KafkaMessageSender implements MessageSender {
      private KafkaProducer producer;
      
      public void send(final Message message) {
         producer.send(new KafkaRecord<>("topic", message));
      }
    }

这样实现的好处，将高层模块与低层实现解耦开来。假如，后期公司升级消息中间件框架，采用Pulsar，我们只需要定义一个`PulsarMessageSender`类即可，借助Spring容器的`@Resource`会自动将其`Bean实例`依赖注入。

**优点：**

*  降低类间的耦合性
 *  提高系统的稳定性
 *  降低并行开发引起的风险
 *  提高代码的可读性和可维护性

最后，要玩溜**依赖倒置原则**，必须要熟悉`控制反转`和`依赖注入`，如果你是java后端，这两个词语你一定不陌生，`Spring框架`核心设计就是依赖这两个原则。

简单原则

复杂系统的终极架构思路就是`化繁为简`，此简单非彼简单，简单意味着灵活性的无限扩展，接下来我们来了解下这个简单原则。

简单原则（KISS：Keep It Simple and Stupid）。翻译过来，**保持简单，保持愚蠢。**

**我们深入剖析下这个 “简单”：**

1、简单不等于简单设计或简单编程。软件开发中，为了赶时间进度，很多技术方案简化甚至没有技术方案，认为后面再找时间重构，编码时，风格随意，追求本次项目快速落地，导致欠下一大堆技术债。长此以往，项目维护成本越来越高。

保持简单并不是只能做简单设计或简单编程，而是做设计或编程时要努力以最终产出简单为目标，过程可能非常复杂也没关系。

2、简单不等于数量少。这两者没有必然联系，代码行少或者引入不熟悉的开源框架，看似简单，但可能引入更复杂的问题。

**如何写出“简单”的代码？**

*  不要长期进行打补丁式的编码
 *  不要炫耀编程技巧
 *  不要简单编程
 *  不要过早优化
 *  要定期做 Code Review
 *  要选择合适的编码规范
 *  要适时重构
 *  要有目标地逐渐优化

最少原则

最少原则也称迪米特法则（LoD：Law of Demeter）。迪米特法则定义只与你的直接朋友交谈，不跟“陌生人”说话。

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

**核心思路：**

*  一个类只应该与它直接相关的类通信
 *  每一个类应该知道自己需要的最少知识

**示例：**

现在的软件采用分层架构，比如常见的`Web --> Service --> Dao` 三层结构。如果中间的`Service层`没有什么业务逻辑，但是按照`迪米特法则`保持层之间的密切联系，也要定义一个类，纯粹用于`Web层`和`Dao层`之间的调用转发。

这样传递效率势必低下，而且存在大量代码冗余。面对此问题，我们需灵活应对，早期可以允许`Web层`直接调用`Dao`。后面随着业务复杂度的提高，我们可以慢慢将`Controller`中的`重业务逻辑`收拢沉淀到`Service`层中。随着架构的衍化，清晰的分层开始慢慢沉淀下来。

写在最后，迪米特法则关心局部简化，这样很容易忽视整体的简化。

表达原则

代码的可维护性也是考验工程师能力的一个重要标准。试问一个人写的代码，每次code review时都是一堆问题，你会觉得他靠谱吗？

这时候我们就需要引入一个`表达原则`。

表达原则（Program Intently and Expressively，简称 PIE），起源于敏捷编程，是指编程时应该有清晰的编程意图，并通过代码明确地表达出来。

> 表达原则的核心思想：代码即文档，通过代码清晰地表达我们的真实意图。

**那么如何提高代码的可读性？**

1、优化代码表现形式

无论是变量名、类名还是方法名，要命名合理，要能清晰准确的表达含义。再配合一定的中文注释，基本不用看设计文档就能快速的熟悉项目代码，理解原作者的意图。

2、改进控制流和逻辑

控制`嵌套代码`的深度，比如`if else`的深度最好不要超多三层。外层最好提前做`否定式`判断，提前终止操作或返回。这样的代码逻辑清晰。下面示例便是正确的处理：

public List<User> getStudents(int uid) {
        List<User> result = new ArrayList<>();
        User user = getUserByUid(uid);
        if (null == user) {
            System.out.println("获取员工信息失败");
            return result;
        }
        
        Manager manager = user.getManager();
        if (null == manager) {
            System.out.println("获取领导信息失败");
            return result;
        }
    
        List<User> users = manager.getUsers();
        if (null == users || users.size() == 0) {
            System.out.println("获取员工列表失败");
            return result;
        }
    
        for (User user1 : users) {
            if (user1.getAge() > 35 && "MALE".equals(user1.getSex())) {
                result.add(user1);
            }
        }
        return result;
    }

分离原则

天下大事，分久必合合久必分。面对复杂的问题，考虑人脑的处理能力有限，有效的解决方案，就是`大事化小，小事化了`，将复杂问题拆分为若干个小问题，通过解决小问题进而解决大问题。

**分离的核心思路：**

1、架构视角

结合业务场景对整个系统内若干组件进行边界划分，如，层与层（MVC）、模块与模块、服务与服务等。像现在流行的DDD领域驱动设计指导的微服务就是一种很好的拆解方式，通过水平分离的策略达到服务与服务之间的分离。

![11d1119fb430a6376711cff50148008f.png][]

> 架构设计视角下的关注点分离更重视组件之间的分离，并通过一定的通信策略来保证架构内各个组件间的相互引用。

2、编码视角

编码视角主要侧重于某个具体类或方法间的边界划分。比如`Stream`流的`filter`、`map`、`limit`，数据集在不同阶段按照不同的逻辑处理，并将输出内容作为下一个方法的输入，当所有的流程处理完后，最后汇总结果。

**一些不错分层案例：**

1、MVC模型

2、网络 OSI 七层模型