删除抽象层，推演复杂度会去哪

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你在决定是否保留一个解析包装层，已有包装实现和两个调用点。教学情况 A 中 readConfig 只转发 JSON.parse；情况 B 中它还检查必要字段并把条目按 id 排序，两个调用者都依赖这些规则。先比较删除后的职责，不立即改代码。

具体做法

列出调用者现在必须知道的接口与包装隐藏的工作。假设移除包装，分别写出两个调用者需要增加什么。纯转发的层可能合并；若校验、排序或错误处理会在调用者重复出现，则记录这份集中承担的价值。最后检查兼容约束和真实调用点，再提出保留、简化或移除的建议。

反例

审查上述两种 readConfig 包装。更多层代表更整洁，所以无论它们隐藏什么职责都保留。

改进写法

对情况 A 和 B 分别做删除推演，不直接改代码。列出移除 readConfig 后两个调用者要新增的解析、校验、排序或错误处理。若只是消除一次转发，可建议合并；若会把共同规则复制到调用者，说明保留的职责和接口。引用实际实现与调用点，并检查兼容要求后再建议修改。

为什么这样改

层数不说明抽象是否有价值。删除推演把注意力转向复杂度消失还是转移：前者提示冗余转发，后者显示模块替调用者承担了工作。这让建议有可追溯的职责依据。

如何验证

示意比较：A 删除后调用者直接 JSON.parse，没有丢失额外规则；B 删除后两个调用者各自需要字段检查和排序。

核对推演是否覆盖真实调用点，以及隐含的错误与顺序约定。如果建议只引用“类很小”或“层很多”，或者忽略公共接口兼容性，仍不足以决定删除。

适用边界

推演是分析方法，不是实际移除授权。即使是纯转发层，也可能承担稳定公共接口或迁移适配，需要单独判断；函数长度不等于接口深度。来源的删除测试已定位，审查中发现的旧行号错误另有修正记录。