阅读笔记：可修改性战术深度解析

核心观点：应对变化的核心战术是“防止连锁反应”。

软件唯一不变的是变化。可修改性不是让代码“好改”就行，而是要有系统性的战术来保障。其中最关键的是防止连锁反应。

关键洞察：

战术类型 具体方法 解决什么问题
信息隐藏 封装内部实现，只暴露接口 修改内部逻辑时不波及调用方
维持已有接口 新增接口而非修改旧接口 已有调用方不受影响
限制通信路径 控制数据生产者的消费者数量 数据变更时波及面可控
引入仲裁者 桥模式/调停者/代理 将直接依赖转为间接依赖
仲裁者模式的价值：当A依赖B，A修改时B可能受影响。引入中间层M后，A只依赖M，M再适配B。修改B时只需调整M，A毫发无伤。这是用“间接层”换取“稳定性”的经典手法。

局部化修改是前置动作：把预期会变的东西先集中放一起（如业务规则、配置项），变的时候只改这一个地方。与其到处“扑火”，不如先建好“防火带”。

延迟绑定是锦上添花：通过配置中心、依赖注入、策略模式等手段，把“选择哪个实现”的决定权推迟到运行时，让修改成本从“重新编译部署”降为“修改配置重启”。

一句话总结：可修改性不是“代码写得灵活”，而是通过信息隐藏、仲裁者和延迟绑定等战术，系统性地控制变更的波及范围。