高内聚业务体要求方法专注单一职责，入参精简明确（≤4个、语义命名、禁布尔开关），返回值精准承诺（非null、不混副作用），执行体严格履约（无全局依赖、逻辑线性）、接口抽象单一能力（命名清晰、方法≤5个、依赖抽象而非实现）。
高内聚的业务体，本质是让每个方法只专注做一件事，并且这件事的输入、输出和行为边界清晰。入参和返回值不是语法细节，而是业务契约的具象表达——定义得越精准，内聚性就越强。
入参精简：只收“必须由调用方决定”的数据
方法的参数列表就是它的责任边界声明。传什么，决定了它要参与什么协作；不传什么，恰恰说明它不该承担哪些职责。
- 参数数量控制在 4 个以内，超过就暗示职责过载，应考虑封装为 DTO 或拆分方法
- 拒绝“捎带式”传参：比如方法只需用户 ID，就别传整个 User 对象；需要扩展时再重构，而非提前透支设计
- 用业务语义命名参数（userId 而非 id），类型明确（LocalDateTime orderTime 而非 Object time）
- 避免布尔参数控制行为分支（如 boolean withCache），这类信号往往意味着该方法已在承担多个职责，应拆成 getOrder() 和 getCachedOrder()
返回值聚焦：承诺什么，就交付什么
返回值是方法对调用方的唯一正式交付物。它必须与方法名、职责完全一致，不能含糊，也不可附带副作用。
Free Ride - Unlimited free AI
下载
一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。
- 只做动作不产结果，就用 void；一旦声明了返回类型（如 Order），所有执行路径都必须返回有效实例
- 禁止用 null 表示“无”或“失败”，改用 Optional
或抛出明确业务异常（如 OrderNotFoundException） - 不混杂控制流与数据流：一个方法不该既返回计算结果，又打印日志或更新缓存——那是另一层的职责
- 对外暴露统一响应体（如 CommonResponse
），但内部方法仍应直接返回领域对象，避免把 API 层契约污染到业务逻辑层
执行体收敛：所有逻辑只为兑现入参与返回值之间的契约
方法体不是代码容器，而是履约过程。它只处理“从入参到返回值”这一条主线，其余一律隔离。
- 不读取静态变量、不依赖全局配置、不调用未声明依赖的服务——这些都会让方法行为不可预测、难以测试
- 复杂判断或转换逻辑抽成私有方法，主流程保持线性可读，例如：validateInput() → calculateFee() → buildResult()
- 变量作用域最小化，声明即使用，避免堆砌一堆未立即使用的中间变量
- if/else 分支必须覆盖全部可能路径，尤其注意 else 缺失导致的返回遗漏——这是内聚断裂的常见信号
配合接口设计：用抽象进一步固化内聚边界
单个方法内聚只是基础，多个方法组合成接口后，整体是否仍高内聚，取决于接口是否表达单一能力契约。
- 接口名体现业务意图（如 OrderCalculator），不出现 Utils、Helper 等模糊后缀
- 接口方法数不超过 5 个，若持续增长，说明它正变成“万能接口”，该按场景拆分为 DiscountCalculator、FeeEstimator 等
- 方法签名只描述“做什么”，不暴露“怎么做”：返回 OrderSummary 而非 Map
，参数用 OrderRequest 而非 JSONObject - 策略类（如不同运费计算规则）统一实现同一接口，主业务方法只依赖接口，不感知具体实现——内聚靠接口约束，耦合靠注入解耦
