高内聚低耦合法则实例解析为什么重要，如何实现？

高内聚低耦合不是一纸空谈，它通过模块内部紧密协作、模块间接口隔离，让系统在需求变更时只改一处而不是推倒重来，是保障代码长寿的关键设计原则。

高内聚低耦合到底在说什么？

高内聚强调的是模块内部的所有元素（函数、类、数据）都围绕同一个职责展开，改动一个功能时，你只需要在这个模块里动手，低耦合则要求模块之间的依赖尽可能少，最好只依赖接口而非具体实现，业界共识认为，模块内聚度越高，耦合度越低，系统的可维护性就越强。

日常开发中,很多团队遇到的“改一处引起全线崩溃”，根源往往是内聚不足或耦合过紧，比如一个订单模块里混了支付逻辑、库存扣减、短信通知，这就是典型的内聚低，而模块之间直接new硬编码类，则是耦合高，高内聚低耦合的目标，就是让每个模块都像独立的乐高块，插拔替换都不影响其他块。

用一个最常见的电商场景来说清楚,假设你接到一个订单模块，原来代码里订单类做了三件事：校验订单数据、发起支付、发送确认邮件，这三个职责混在一起，当支付方式从支付宝换成微信时，你不得不改订单类，还要担心邮件发送会不会被影响，这就是低内聚高耦合的典型。

把订单模块拆成订单核心、支付模块、通知模块，订单核心只负责订单状态流转（创建、待支付、已支付、已取消），支付模块通过接口接收订单ID和金额，完成支付后回调订单模块修改状态，通知模块监听订单状态变化，异步发送邮件或短信。

关键改动：

这种设计下,内聚体现在订单模块只关注订单本身，耦合体现在支付模块只需实现接口，不关心订单内部细节。内聚性高了，耦合度自然降下来。

设计模式是实现高内聚低耦合的典型工具,以支付方式为例，不同支付渠道（支付宝、微信、银联）的处理逻辑完全不同，但调用方（订单模块）不需要知道这些差异。

定义一个支付策略接口,每种支付方式实现一个策略类，订单模块只持有策略接口引用，运行时根据参数选择具体策略，这样，新增支付方式时，只需增加一个策略类，订单模块完全不需要改动。这是单职责原则在支付场景下的落地。

策略类如何获取？用简单工厂或工厂方法，将创建逻辑集中到工厂中，工厂根据支付类型返回对应的策略实例，调用方只依赖工厂接口，不依赖具体支付类，这样，即使支付方式增加，工厂内部改动也不会影响订单模块。

据统计,采用策略模式配合工厂的实现，代码变更的影响范围能从全文件缩小到单个类，维护成本降低显著。

很多开发者会问：高内聚低耦合不就是微服务吗？两者有本质区别，但微服务正是高内聚低耦合在分布式场景下的极致体现。

微服务不是唯一选择,在单体应用中，通过分层（Controller、Service、DAO）和模块化（Maven/Gradle多模块）也能实现高内聚低耦合，比如将订单逻辑拆成独立的Java包，对外暴露接口，内部实现封装，其他模块只依赖接口，不依赖实现类。

高内聚低耦合是思想,微服务只是其中一种实现方式。不要为了微服务而微服务，先保证模块级别的内聚和耦合合理，再考虑是否拆分服务。

一个简单的方法：如果改一个功能时，你需要在两个以上不同模块里改动，说明内聚不够，比如改订单状态，却要改支付模块的通知逻辑，那订单模块没把订单状态变化封闭好。理想情况下，一个功能变更只影响一个模块。

不是,接口越细，分散到多个类，虽然耦合降低，但系统复杂度增加，常见做法是根据业务变化频率来设计接口，变化部分用接口隔离，稳定部分直接依赖具体类，比如支付方式变化频繁，所以用接口；日志记录逻辑稳定，直接使用具体类即可。

高内聚让每个模块的测试用例更集中,不需要模拟大量外部依赖，低耦合让mock更容易，因为依赖的是接口，可以轻松替换为测试实现。测试成本与耦合度直接相关，耦合越低，测试越简单。

原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/515943.html