模块化设计原则：高内聚低耦合、单一职责与接口隔离

聊到模块化设计，我脑子里第一个蹦出来的词就是「高内聚低耦合」。这六个字，说白了就是模块化设计的灵魂。你想想看，一个系统拆成几十个模块，如果它们之间牵一发动全身，那还不如不拆。

我个人习惯把模块化设计比作搭积木。好的积木，每一块自己站得稳，跟别的积木只靠几个凸点连接。坏的积木呢？互相粘在一起，想换一块就得扯下一大片。嗯，咱们今天就把这三个原则掰开揉碎了讲清楚。

一、高内聚低耦合：模块化的基石

高内聚，指的是一个模块内部的各个元素之间关系紧密，共同完成一个明确的功能。低耦合，指的是模块与模块之间的依赖关系尽量少、尽量弱。

我在项目中遇到过这样一个案例：一个订单模块，里面混了用户校验、库存查询、支付处理、物流跟踪。表面上看是一个模块，实际上它跟七八个模块都有直接调用关系。每次改订单逻辑，都得拉上三个团队一起回归测试。这就是典型的高耦合低内聚——改一处，炸一片。

怎么判断耦合度高不高？我有个土办法：你改一个模块的代码，看看需要同时改多少个其他模块。超过两个，就得警惕了。

二、单一职责原则（SRP）

单一职责原则，英文叫 Single Responsibility Principle。说白了就是：一个模块只应该有一个引起它变化的原因。

举个例子，你写了一个 UserService，里面既有用户注册的逻辑，又有发送邮件的逻辑，还有生成报表的逻辑。那么当邮件模板变了、报表格式变了、或者注册规则变了，你都得改这个类。这就是三个职责揉在一起了。

我曾经接手过一个遗留系统，一个类三千多行，里面塞了数据解析、业务计算、文件导出、日志记录。我花了整整两周才把它拆成六个独立的模块。拆完之后，每个模块的单元测试覆盖率从 20% 飙到了 85%。

正确的做法是这样：

// ❌ 违反 SRP：一个类干了三件事
public class OrderProcessor {
    public void processOrder(Order order) {
        validateOrder(order);      // 校验
        calculatePrice(order);     // 计算
        sendNotification(order);   // 通知
    }
}

// ✅ 符合 SRP：每个类只做一件事
public class OrderValidator {
    public void validate(Order order) { ... }
}

public class PriceCalculator {
    public void calculate(Order order) { ... }
}

public class NotificationService {
    public void send(Order order) { ... }
}

三、接口隔离原则（ISP）

接口隔离原则，Interface Segregation Principle。它的核心思想是：客户端不应该被迫依赖它不需要的接口。

你想想看，如果一个接口定义了 10 个方法，但你的实现类只需要用到其中 2 个，那剩下的 8 个空实现就是垃圾代码。更糟糕的是，一旦接口变了，所有实现类都得跟着改。

我记得有一次重构一个支付模块，原来的接口长这样：

// ❌ 胖接口：所有支付方式共用一个大接口
public interface Payment {
    void payByCreditCard();
    void payByWeChat();
    void payByAlipay();
    void refund();
    void queryBill();
}

// ✅ 接口隔离：每个支付方式独立接口
public interface CreditCardPayment {
    void pay();
    void refund();
}

public interface WeChatPayment {
    void pay();
    void queryBill();
}

拆完之后，新增一个支付方式只需要实现对应的接口，完全不影响已有的代码。这就是接口隔离带来的好处——改动局部化，风险最小化。

四、三个原则如何协同工作

这三个原则不是孤立的，它们互相支撑：

原则	关注点	解决的问题
高内聚低耦合	模块内部与模块之间	系统整体可维护性
单一职责	模块的职责边界	模块内部的可理解性
接口隔离	模块对外暴露的契约	调用方的依赖最小化

实际项目中，我一般这样落地：先按单一职责把模块拆清楚，然后用接口隔离原则设计对外 API，最后用高内聚低耦合的标准来评审模块间的依赖关系。三步走下来，代码质量基本不会差到哪里去。

好了，这一章的内容就到这里。记住，模块化设计不是一蹴而就的，它需要你在每个代码提交前多问自己一句：「这个模块的职责够单一吗？它的接口够小吗？它跟其他模块的依赖够弱吗？」问多了，就成了习惯。