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

好，咱们今天聊点实在的。模块化设计听起来高大上，但说白了，就是怎么把代码拆得漂亮、拆得合理。我做了十几年系统架构，见过太多「拆了还不如不拆」的惨案。为什么会这样？因为很多人只记住了「要拆」，却忘了「怎么拆」。

我个人习惯，把模块化设计浓缩成三个原则。你把这三点吃透了，至少能避开80%的坑。

一、高内聚低耦合：模块设计的黄金法则

先说说内聚和耦合。这两个词，我建议你刻在脑子里。

高内聚，就是一个模块内部的东西，应该紧密相关。比如一个订单模块，它只管订单的创建、修改、查询。别把用户登录的逻辑塞进去，也别把支付回调的逻辑塞进去。

低耦合，就是模块之间依赖要少、要弱。A模块改了，B模块最好不用动。如果非得动，那说明耦合太紧了。

我在项目中遇到过这样一个案例：一个电商系统，订单模块和库存模块耦合得死死的。订单创建时直接调用库存的扣减方法，库存不足时订单模块还要抛异常。后来库存逻辑改了，订单模块跟着改了三轮。这就是典型的「高耦合」灾难。

二、接口隔离原则：别让模块「被迫依赖」

接口隔离原则，说白了就是：不要强迫一个模块依赖它不需要的东西。

你想想看，如果一个接口定义了10个方法，但你的模块只需要用其中2个，那剩下的8个就是「噪音」。更麻烦的是，这8个方法一旦变化，你的模块也得跟着重新编译、重新测试。

我记得有一次，一个支付模块依赖了一个「用户服务接口」，这个接口里有20多个方法。支付模块其实只用到了getUserById()这一个方法。后来用户服务接口重构，改了十几个方法签名，支付模块被迫跟着改了一堆无关的代码。

怎么避免？

• 接口要小：一个接口最好只包含3-5个方法
• 接口要专：每个接口只服务于一个「角色」或「场景」
• 接口要稳：接口一旦发布，尽量别改，要改就新增

三、单一职责原则：一个模块只做一件事

单一职责原则，是模块化设计的基石。一个模块只应该有一个「改变的理由」。

举个例子：一个OrderService类，如果它既负责订单的CRUD，又负责发送邮件通知，还负责生成报表。那它就有三个改变的理由：订单逻辑变了要改它，邮件模板变了要改它，报表格式变了也要改它。这样的模块，迟早变成「屎山」。

我个人的习惯是：一个模块的职责，用一句话能说清楚。如果说需要两句话，那就说明它可能太「胖」了。

模块	职责描述（一句话）	是否合理
OrderModule	管理订单的生命周期	✅ 合理
OrderModule	管理订单生命周期 + 发送通知 + 生成报表	❌ 不合理
PaymentModule	处理支付请求和回调	✅ 合理
PaymentModule	处理支付 + 管理用户余额 + 对账	❌ 不合理

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

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

• 单一职责帮你确定「拆什么」—— 按职责拆
• 接口隔离帮你确定「怎么连」—— 用小接口连接
• 高内聚低耦合帮你确定「拆得好不好」—— 内聚高、耦合低就是好

我一般这样用：先按单一职责把系统拆成模块，然后给每个模块设计小接口，最后用高内聚低耦合的标准去衡量。如果发现某个模块耦合太高，就回头看看是不是职责没分清楚。

五、实战中的常见误区

说了这么多，我再给你泼点冷水。这三个原则看着简单，实际用起来很容易走偏。

1. 过度拆分：一个模块只有两行代码，那叫「碎片化」，不叫「模块化」。模块要有一定的「粒度」。
2. 接口泛滥：每个类都搞一个接口，那是「为了接口而接口」。接口是为「变化点」服务的，稳定的内部实现不需要接口。
3. 忽视业务：技术上的高内聚，不等于业务上的高内聚。模块划分首先要考虑业务边界，其次才是技术实现。

总结

高内聚低耦合、接口隔离、单一职责，这三个原则是模块化设计的「三驾马车」。你不需要背定义，但需要在每次写代码、做设计时，问自己三个问题：

• 这个模块的职责是什么？一句话能说清吗？
• 它依赖的接口，每个方法都用得上吗？
• 修改这个模块，会影响多少个其他模块？

这三个问题问完，你的模块化设计水平，至少能超过80%的开发者。嗯，剩下的20%，靠的是经验和踩坑。慢慢来，不着急。