如何做到高内聚低耦合的代码设计

本文深入解析了如何通过SOLID原则实现真正高内聚、低耦合的代码设计，强调其本质不是教条式套用五条规则，而是围绕“职责”与“依赖”的底层逻辑——按变化原因划分单一职责、依赖稳定抽象而非具体实现、按角色提供精简接口，并将SOLID作为重构时识别设计坏味道（如频繁修改、测试困难、牵一发而动全身）的实用指南，帮助开发者写出更清晰、可维护、易演进的软件系统。

遵循SOLID原则本身不是目的，而是达成高内聚、低耦合的手段。关键不在于机械套用五条规则，而在于理解每条原则背后对“职责”和“依赖”的处理逻辑——让类只做一件事且做好，让模块之间通过抽象而非具体细节关联。

单一职责原则（SRP）：一个类只负责一个变化原因

内聚性的核心是“聚焦”。当一个类同时处理用户验证、日志记录和数据库保存时，三者任一需求变动都可能迫使你修改这个类，导致意外影响。真正的单一职责，是按“变化原因”划分，而非功能数量。

• 识别变化点：比如“登录策略调整”“审计要求升级”“数据库从MySQL迁移到PostgreSQL”，它们是不同维度的变更驱动
• 把每个变化原因封装成独立类：Authenticator、AuditLogger、UserRepository
• 避免“工具类”陷阱：Utils、Helper这类命名往往是职责模糊的信号，应替换成有明确业务语义的类名

开闭原则（OCP）与里氏替换原则（LSP）：用多态隔离变化，确保可替换性

低耦合的关键是“依赖抽象”。当高层模块直接调用具体实现（如new MySQLUserRepo()），它就和MySQL强绑定。OCP要求对扩展开放、对修改关闭；LSP确保子类能无缝替代父类——二者共同支撑起可插拔的设计。

• 定义接口或抽象类描述行为契约：interface UserRepository { User findById(String id); void save(User u); }
• 具体实现类只依赖该契约，不暴露内部技术细节（如JDBC连接、SQL语句）
• 子类重写方法时，不改变原方法的前置条件（输入范围）、后置条件（输出保证）和不变量（如“save后id必不为空”）

依赖倒置原则（DIP）：让高层模块不依赖底层模块，都依赖抽象

这是实现松耦合最直接的操作指南。它不是说“不要依赖”，而是“不要依赖具体实现”。依赖关系必须指向稳定、抽象的契约，而非易变的细节。

• 避免在Service类中直接new Repository实现类；改用构造函数注入或setter注入抽象类型
• 抽象不应由实现类决定，而应由使用方（如Service）提出需求，再由基础设施层提供适配实现
• 一个典型反例：Controller里写new HttpClient()——它本该依赖IHttpClient，由配置决定用OkHttp还是RestTemplate

接口隔离原则（ISP）：按角色提供精简接口，避免臃肿契约

大而全的接口（如包含15个方法的IEntityService）会迫使实现类承担无关职责，也导致调用方依赖未使用的部分，增加隐式耦合。ISP强调“客户驱动的接口”，谁用、怎么用，就定义什么。

• 按调用场景拆分：IUserReader、IUserWriter、IUserAdmin，而非一个IUserService
• 接口中方法应具有强语义相关性：比如findById和findAll可以共存，但findById和sendEmail就不该出现在同一接口
• 允许一个类实现多个小接口，比强迫它实现一个大接口更灵活、更安全

不复杂但容易忽略的是：SOLID不是编码前的蓝图，而是重构时的指南针。先写出清晰表达意图的代码，再用SOLID检查哪里出现了重复修改、难以测试或牵一发而动全身的情况——那里就是内聚不足或耦合过高的信号。

到这里，我们也就讲完了《如何做到高内聚低耦合的代码设计》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！