耦合

副标题 / 摘要 紧耦合通常被视为反模式，但并非绝对。本文讨论在性能与一致性优先时，何时可以接受紧耦合。 目标读者 需要做架构取舍的工程师 关注性能与一致性的团队 软件架构师与技术负责人 背景 / 动机 为了抽象而抽象会带来复杂度和性能损耗。 在可控边界内，紧耦合反而能带来更高效率。 核心概念 紧耦合：组件依赖强，替换成本高 松耦合：抽象接口降低依赖 性能与一致性：常与抽象层数量冲突 实践指南 / 步骤 评估是否存在严格的延迟预算 确认模块生命周期是否一致 记录耦合原因与边界 设置后续解耦计划或替换点 可运行示例 # 直接调用减少抽象层，提高性能 def hash_id(user_id: int) -> int: return user_id * 31 % 1000 def route_request(user_id: int) -> int: # 紧耦合：直接依赖 hash 规则 return hash_id(user_id) if __name__ == "__main__": print(route_request(42)) 解释与原理 紧耦合减少了中间层与动态分发成本，能提升性能与确定性。 代价是灵活性降低，变更成本提高。 常见问题与注意事项 紧耦合会不会让系统难以演进？ 会，因此要明确边界与风险。 什么时候一定要解耦？ 当模块演进速度不一致时。 如何控制风险？ 通过测试覆盖与明确文档约束。 最佳实践与建议 对紧耦合区域建立“可替换计划” 在性能关键路径优先考虑直接调用 用版本策略降低变更风险 小结 / 结论 紧耦合不是“坏”，而是“有成本的选择”。 当性能与一致性优先时，它可以是正确决策。 参考与延伸阅读 Clean Architecture Software Architecture Tradeoffs 元信息 阅读时长：6~8 分钟 标签：架构取舍、耦合 SEO 关键词：紧耦合, 架构取舍 元描述：说明紧耦合的合理场景与风险。 行动号召（CTA） 标记你系统里最紧耦合的模块，写下“为何如此”的技术说明。

副标题 / 摘要 内聚关注“模块内部是否紧密相关”，耦合关注“模块之间是否依赖过多”。本文给出区别与改进方法。 目标读者 需要评估设计质量的工程师 负责重构与模块划分的开发者 做架构与代码评审的团队 背景 / 动机 很多系统难维护的原因不是“功能太多”，而是模块内聚低、耦合高。 理解内聚与耦合，是设计优化的基础。 核心概念 内聚（Cohesion）：模块内部的相关性 耦合（Coupling）：模块之间的依赖程度 高内聚、低耦合：可维护性最佳 实践指南 / 步骤 识别“职责过多”的模块 拆分低内聚模块 减少跨模块直接依赖 用接口隔离依赖 引入依赖注入 可运行示例 # 低内聚示例：一个类做太多事 class OrderManager: def calculate(self): pass def save(self): pass def send_email(self): pass # 改进：拆分职责 class OrderCalculator: def calculate(self): pass class OrderRepository: def save(self): pass class OrderNotifier: def send_email(self): pass 解释与原理 内聚高意味着模块职责单一、变化集中； 耦合低意味着模块之间依赖少、替换成本低。 常见问题与注意事项 模块越小内聚就越高吗？ 不一定，小但职责混杂仍然低内聚。 完全无耦合可能吗？ 不可能，关键是控制依赖方向与数量。 怎么衡量？ 看模块修改是否牵连多处。 最佳实践与建议 一个模块只解决一个问题 把依赖集中到边界层 用接口隔离变化 小结 / 结论 内聚与耦合是判断设计质量的核心指标。 高内聚、低耦合是长期可维护系统的基础。 ...

副标题 / 摘要 迪米特法则强调“只和直接朋友说话”。本文用示例说明违规写法，并给出修复方式。 目标读者 想降低耦合的工程师 负责代码评审与重构的开发者 需要维护大型系统的团队 背景 / 动机 深层链式调用让对象之间依赖过强，改动一个结构就影响一大片。 迪米特法则就是用来控制这种耦合的。 核心概念 最少知识原则：对象只了解直接依赖 消息委托：把内部结构封装在对象内 耦合控制：减少“链式访问” 实践指南 / 步骤 识别链式调用（a.b.c.d） 让中间对象提供必要方法 封装内部结构 避免跨层访问内部字段 可运行示例 class Wallet: def __init__(self, balance): self.balance = balance def has_enough(self, amount): return self.balance >= amount class User: def __init__(self, wallet): self.wallet = wallet def can_pay(self, amount): return self.wallet.has_enough(amount) def checkout(user, amount): # 违例：user.wallet.balance # 修复：user.can_pay return user.can_pay(amount) 解释与原理 通过让 User 暴露 can_pay 方法，调用方无需知道 wallet 的内部结构。 这样 wallet 内部变化时，调用方不需要改动。 ...

副标题 / 摘要 封装不是“把字段设为 private”，而是建立稳定边界，让变化被隔离。本文解释封装的工程价值与落地方法。 目标读者 写业务系统但经常“改一处坏一片”的工程师 希望提升模块边界设计的开发者 负责代码评审和架构演进的技术负责人 背景 / 动机 没有封装，系统就像没有隔间的办公室：任何一个变化都会影响到其他部分。 封装能让变化局部化、减少耦合、提高可读性与可测试性。 核心概念 信息隐藏：内部实现细节不暴露给外部 稳定边界：对外只暴露行为和契约 高内聚、低耦合：模块内紧密相关，模块间依赖最小 实践指南 / 步骤 先定义对外行为：先有接口，再有实现。 隐藏数据结构：不要让外部直接依赖内部表示。 用方法维护不变量：禁止外部绕过规则直接改数据。 把变化集中在模块内部：外部只看到稳定契约。 为封装加测试：通过行为测试保证边界稳定。 可运行示例 class BankAccount: def __init__(self, balance: int): self._balance = balance def deposit(self, amount: int) -> None: if amount <= 0: raise ValueError("amount must be positive") self._balance += amount def withdraw(self, amount: int) -> None: if amount <= 0: raise ValueError("amount must be positive") if amount > self._balance: raise ValueError("insufficient balance") self._balance -= amount def balance(self) -> int: return self._balance if __name__ == "__main__": acc = BankAccount(100) acc.deposit(50) acc.withdraw(30) print(acc.balance()) 解释与原理 封装的本质是 把“规则”放到模块内部。 外部只调用方法，不触碰内部状态，这样就能保证不变量始终成立。 当实现方式变化时，只要接口不变，外部代码无需调整。 ...