一、先分清两种问题：是「过度封装」还是「同事不熟悉你的设计」

1. 真・过度封装（常见特征）

• 简单一行逻辑，拆了 3 层以上函数 / 类跳转，看业务要不停跳转文件
• 为了封装而封装，没有复用价值，只是强行分层
• 命名抽象空洞：HandleData()、ProcessCore()，看不出做什么
• 中间层只做转发：A 调用 B，B 只转发给 C，无任何加工逻辑
• 基础判断、简单计算单独抽成类，调用成本远大于阅读成本

2. 只是习惯差异（不算封装问题）

• 分层规范统一，只是同事习惯平铺代码
• 封装是为了复用、解耦、隔离第三方依赖
• 每层职责清晰，注释 / 函数名能一眼看懂流程

二、快速自查优化方案

1. 干掉无意义中转层

如果中间函数只有一行调用下级，直接内联，删除多余封装 反面示例：

// 多余中转，纯浪费跳转 void UserService::calcMoney() { m_calc->run(); }

优化：直接调用m_calc->run()，删掉一层接口

2. 分层遵循「单一职责 + 控制层数」

通用经验：业务主流程最多2~3 层调用，超过就要合并 / 简化

• 表层：接口 / 控制器（接收参数、参数校验）
• 中层：业务逻辑（核心计算、流程编排）
• 底层：工具 / 数据库 / 第三方（原子能力） 禁止套娃：控制器→A 服务→B 服务→C 工具→D 工具

3. 命名杜绝模糊，降低阅读成本

差：execTask()、doBiz()、dealInfo()好：calculateUserRechargeAmount()、queryOrderUnpaidList()函数名直接说明做什么，不用点进去猜逻辑

4. 长流程增加「扁平聚合入口」

多层拆分后别人读起来绕，可以对外提供一个聚合接口，把完整流程收拢：

// 对外统一入口，同事只看这一个方法就能看懂完整流程 Result UserManager::createRechargeOrder(Req req) { checkParam(req); auto money = calcAmount(req); auto order = saveOrder(money); sendNotify(order); return order; }

内部细节拆分，对外入口扁平，兼顾封装和可读性。