知识卡片
应对变化的两种典型手段及其代价
内容
即便准确预测了变化，如何应对同样复杂。常见两种手段：拆成”变化层”和”稳定层”，但两者边界常不明确，接口既要稳定又要容纳差异化实现；或提炼”抽象层+实现层”（如设计模式、规则引擎），新增功能只需扩展实现层，代价是一个函数能搞定的逻辑要拆成多个类协作，维护成本上升。发散：这解释了过度用设计模式常被诟病”绕”——为可能出现的变化预付的复杂度，变化没到来前纯粹是负担。
参考来源
- 位置：《从0开始学架构》第8章《06｜复杂度来源：可扩展性》（源文件：_epub-src/OEBPS/Text/part0007_split_002.html、part0007_split_003.html）
- 结论依据：原文说明第一种方案"将变化封装在一个'变化层'，将不变的部分封装在一个独立的'稳定层'"，其复杂性在于"对于哪些属于变化层，哪些属于稳定层……不同的人有不同的理解"以及接口设计需兼顾稳定与差异；第二种方案"提炼出一个'抽象层'和一个'实现层'"，以装饰者模式为例说明"本来一个函数或者一个类就能搞定的事情，现在要拆分成多个类"。
- 原始内容：第一种应对变化的常见方案是将"变化"封装在一个"变化层"，将不变的部分封装在一个独立的"稳定层"……第二种常见的应对变化的方案是提炼出一个"抽象层"和一个"实现层"……本来一个函数或者一个类就能搞定的事情，现在要拆分成多个类，而且多个类之间必须按照装饰者模式来设计和调用。