技术思考问题48：抽象藏细节，反而更难懂？原创

你有没有遇到过这样的接口？文档写的清清楚楚，封装的漂漂亮亮，可团队每次改动都心惊胆战。问题往往不在代码本身，而在于调用者必须同时记住太多东西。今天我们由奥卡姆剃刀和认知符合这两个模型给抽象好坏一个检验的标准。奥卡姆剃刀做的是是在满足需求时优先选择更少必要假设的解释，放到架构里就是好。抽象应该减少调用者必须同时理解的概念，而不只是增加一层统一接口。如果封装后你还是种异常规则配置开关和影视副作用，那复杂度并没有真正下降。认知负荷告诉我们，同时维持过多规则会损害人的判断以及想象你开车时。

既要看路，又要记3条临时交规，还要随时准备切换手动模式，你还能开好吗？接口一样，每多一个影视规则，调用者就多一份认知负担，出错概率就高一分。怎么落地？第一步，为每层接口列出调用者、必须制造者前置条件，第二步，把错误、超时、重置和密灯，第4步，删除重复开关和透传字段，建立视例与回归测试。做完这4步，抽象是真是假就清楚了。单要注意边界，抽象并非越少越好，对变化频繁或有安全边界的领域，明确分层可能比省代码更重要。比如支付风控，你宁可多一层显示校验，也不能把规则藏进黑河。

所以，判断标准不是抽象程序，而是调用值是否少抽筋。一句话，小姐，隐藏时间不等于降低复杂度，让使用者少操心才算抽象成功。下次设计接口时，先问自己，调用者还需要同时记住哪些规则？如果答案超过3条，就该重新想想。从今起，用前置条件和契约把影示规则显示化，让抽象真正为团队减负。