public方法承担过多职责会导致调用方难理解、测试困难、修改风险高；应按单一职责拆分为预处理、核心逻辑、副作用、结果组装等小函数，并用参数对象或Builder模式简化接口。
为什么 public 方法做太多事会出问题
公开方法承担过多职责，直接导致调用方难以理解、测试覆盖困难、修改时牵一发而动全身。比如一个 processUserInput() 同时解析 JSON、校验字段、查数据库、发通知、写日志——任何一环逻辑变更都可能破坏其他功能，且无法单独单元测试校验逻辑或通知逻辑。
这类方法往往在初期“图快”写成，但后续维护成本指数级上升。根本矛盾在于：公开接口本应表达“做什么”，而不是“怎么做”。
把大 public 方法拆成小 private/protected 方法
拆解不是随便切分，而是按单一职责原则，按**领域动作**划分：
- 输入预处理（如
normalizeInput()、validateFormat()）
- 核心业务逻辑（如
calculateDiscount()、resolveConflict()）
- 副作用操作（如
logOperation()、notifyExternalService()）
- 结果组装（如
buildResponse()）
normalizeInput()、validateFormat()）calculateDiscount()、resolveConflict()）logOperation()、notifyExternalService()）buildResponse()）这些小函数可以是 private，甚至用 static 标记（如果不需要访问成员变量），让编译器和 IDE 更容易识别其作用域与生命周期。
用参数对象或 builder 模式控制输入复杂度
当 public 方法参数超过 3 个，尤其是类型混杂（int、std::string、std::optional<Config>），就该怀疑接口设计是否已超载。
推荐做法：
- 把相关参数封装成结构体，例如
UserProcessRequest，带默认值和语义化字段名 - 避免布尔参数控制分支（如
process(..., true, false, true)），改用枚举或明确命名的标志位（ProcessingFlags::kSkipCache | kForceRetry） - 对可选行为，用 builder 模式延迟决定，而非堆砌参数（
UserProcessor().withLogging().withRetry(3).run(input)）
警惕“伪拆分”：只是把代码换行，没真正解耦 常见误区是把一个长函数复制粘贴成几个 private 函数，但它们仍强依赖同一组局部变量、共享 mutable 状态、或隐式依赖执行顺序。
判断是否真解耦，看这三点：
立即学习“C++免费学习笔记（深入）”；
- 能否把某个 private 函数抽到另一个类里，不带上下文也能编译通过？
- 该函数是否只读取输入参数，不读写
this->xxx？如果是，考虑改为static或非成员函数 - 单元测试时，能否只测
validateFormat()而不启动数据库或 mock 日志系统？
真正解耦后，public 方法会变得非常薄——通常就几行：参数检查 + 调用子流程 + 返回。最难的部分其实是给每个子步骤起准确的名字，名字不对，说明职责还没理清。
