在软件开发中，良好的架构设计能够大幅降低系统的复杂度，提高代码的可维护性。而“高内聚，低耦合”正是指导我们如何合理组织代码的核心原则之一。本文将从通俗的角度解释这一概念，并结合实际案例说明其重要性。
一，高内聚：该放一起的要放到一起
高内聚（High Cohesion） 指的是一个模块（类、函数、组件）内部的各个元素（方法、变量）紧密相关，共同完成一个明确的任务。
厨房的比喻：厨房里的工具（刀、砧板、锅）都是为了“烹饪”这一目标服务的，它们紧密相关，这就是高内聚。
如果厨房里混入了办公用品（电脑、文件夹），那就破坏了内聚性，导致功能混乱
二，低耦合：不该放一起的就要分隔开，少联系
低耦合（Low Coupling） 指的是模块之间的依赖关系尽可能少，修改一个模块时，不会对其他模块造成太大影响。
公司部门的比喻：市场部、技术部、财务部各自独立运作，通过标准流程（API）协作，而不是直接插手对方的工作。
如果市场部直接修改技术部的代码，那就会导致混乱，难以维护。
代码示例
高耦合的设计（不推荐）：
class OrderService {private Database db = new MySQLDatabase(); // 直接依赖具体实现public void saveOrder() { db.save(); }
}
低耦合的设计（推荐）：
interface Database {void save();
}class MySQLDatabase implements Database { /* ... */ }class OrderService {private Database db; // 依赖抽象，而非具体实现public OrderService(Database db) { this.db = db; } // 依赖注入public void saveOrder() { db.save(); }
}
这样，OrderService 不直接依赖 MySQLDatabase，而是通过接口交互，未来可以轻松替换为 PostgreSQLDatabase 或其他存储方式。
三，高内聚与低耦合的关系
高内聚： 关注的是模块内部的组织方式，确保功能单一、职责清晰。
低耦合 ：关注的是模块之间的交互方式，确保依赖最小化。
两者相辅相成：高内聚的模块自然倾向于低耦合，因为它们只关注自己的职责，不会过度依赖外部。
四，实际应用场景
1 微服务架构
-
高内聚：每个微服务只负责一个业务领域（如订单服务、支付服务）。
-
低耦合：服务之间通过 API（REST/gRPC）通信，而不是直接访问对方的数据库。
2 前端组件化（如 React/Vue）
-
高内聚：一个组件只负责渲染特定 UI（如
Button组件只处理点击样式）。 -
低耦合：组件之间通过 Props/Events 通信，而不是直接修改对方的状态。
五，如何实现高内聚低耦合？
-
单一职责原则（SRP）：一个类/模块只做一件事。
-
依赖倒置原则（DIP）：依赖抽象，而非具体实现。
-
接口隔离原则（ISP）：不要强迫模块依赖它不需要的接口。
-
使用设计模式：如工厂模式、观察者模式等，减少直接依赖。
