Java学习随笔：拆分方法时先找变化的理由（2026-10-28）

学习 Java 时，常会听到一个建议：方法不要写得太长。这个建议有助于提醒我们关注复杂度，但如果把它理解为超过若干行就必须拆开，也可能得到另一种难读的代码：每个方法都很短，阅读一次业务却需要来回跳转很多次。今天想整理的，是怎样从职责和变化出发决定方法边界，而不是只盯着代码行数。

可以想象一个计算订单应付金额的方法。它读取商品价格，计算优惠，处理运费，再形成结果。如果所有逻辑都混在一起，修改运费时就必须小心避开优惠规则，阅读时也很难区分哪些步骤只是准备数据，哪些步骤真正改变金额。这时值得拆分的依据，是几个步骤各自回答不同的问题，并且可能因为不同的业务要求而变化。

我会先尝试用一句话说明准备提取的那段代码。如果能够明确说出它是在判断优惠资格，或者是在计算某个地区的运费，那么它通常已经有了一个可以讨论的边界。相反，如果只能叫作处理数据、执行步骤二，就说明提取后仍然没有讲清含义。这种拆分可能只是把原来连续的代码藏到了另一个位置，读者依然要打开实现才能知道它做了什么。

输入和输出也能帮助判断边界是否自然。一个计算步骤若只需要少量明确的数据，并返回含义清晰的结果，单独阅读会比较容易。如果提取后必须传入很多互不相关的参数，还要依赖调用前某个字段被修改、调用后另一个字段被补齐，就应该重新检查职责。参数多不一定说明设计错误，但它能提醒我们：这段逻辑可能仍然和外部状态紧紧纠缠，单纯换个方法名没有真正降低理解成本。

对于金额计算这样的场景，可以尽量区分计算规则和获取数据的动作。读取价格可能涉及外部依赖，优惠计算则可以在给定数据后得出结果。把两者适当分开，有助于单独讨论规则，也能更清楚地看到哪里可能失败。不过分开并不意味着数据永远不会过期，价格在读取后是否还有效、提交订单时是否需要再次确认，仍然是业务必须回答的问题。方法结构清楚，也不能代替一致性约束。

还有一个容易混淆的地方是复用。两段代码现在长得相似，不一定意味着它们应该立即合成一个方法。例如新用户优惠和活动优惠可能暂时采用相同的计算方式，但它们的适用条件、舍入要求和后续调整方向不同。过早把它们绑定在一个通用方法里，修改时反而需要增加很多条件。判断是否共享时，除了看当前写法，也要看它们是否表达同一条规则，是否应该一起变化。

反过来，同一条业务规则如果在多个位置各写一份，也会带来维护风险。某个规则调整后，漏改其中一处，就可能出现不同入口算出不同结果。此时提取共享逻辑的目的，是给规则一个可信的维护位置，而不是追求少写几行。共享方法应该说明自己负责的语义和适用范围，不能只因为名字叫公共工具，就让互不相关的业务逐渐堆进去。

拆分后的调用顺序也要让人看得懂。上层方法可以描述主要流程，较低层的方法解释具体细节。如果同一层里既有业务决策，又突然出现很细的字段拼接，读者就会不断切换关注尺度。适当保持一段流程中的表达层次接近，通常比把每一次赋值都包装起来更有帮助。简单而连贯的几行代码，有时留在一起反而更容易理解。

异常和副作用同样属于方法边界的一部分。一个听起来只计算结果的方法，如果悄悄保存订单或者发送通知，就会让调用方错误估计它的影响。命名和约定应当让这些行为有迹可循。提取代码时，还要检查异常是否被改变、资源释放是否仍然覆盖原来的范围，以及提前返回会不会跳过必要步骤。结构调整只有在行为边界仍然清楚时，才算真正改善了可维护性。

最后，我会用两个问题回头检查拆分结果：以后修改某条规则时，能否比较快地找到应该修改的位置？只阅读上层流程时，能否理解各步骤的目的，而不必立刻钻进每个细节？如果答案更清楚，拆分才有实际价值。方法长度可以作为发现问题的线索，但更值得追求的，是让代码的边界对应业务含义和变化理由。这样的方法即使不是最短，也更容易被下一次修改正确地理解。