这个java案例是否预设了多种剧本？

wen java案例 2026-08-13 2

Java案例背后的“剧本”陷阱：预设多种分支,是设计智慧还是过度设计？

这个java案例是否预设了多种剧本？

目录导读

案例的“剧本”从何而来？ —— 拆解一个典型Java业务案例的结构
预设多种剧本的三种典型场景 —— 状态机、策略模式与事件驱动
“剧本”过载的代价 —— 可读性、维护性与性能的三重考验
如何判断“预设”是否合理 —— 基于需求频率与变化率的决策框架
实战问答：当面试官问“你这段代码预设了几种剧本” —— 常见话术与避坑指南

案例的“剧本”从何而来？

在Java开发中，我们常看到这样的案例：一个OrderService类，同时处理pending、paid、shipped、completed、canceled五种状态，每个状态又有create、pay、ship、complete、cancel五种动作，代码里充斥着if-else或switch，甚至引入状态机框架（如Spring StateMachine），这类案例天然预设了多种“剧本”——每个状态转移就是一个剧本。

问题来了：这个Java案例是否预设了多种剧本？ 答案几乎是肯定的，但关键不是“有”或“没有”，而是预设到什么程度是合理的。

预设多种剧本的三种典型场景

场景A：状态机 —— 显式剧本化

电商订单、审批流、游戏任务等，状态数量有限且转移条件明确，用enum + Map<State, List<Transition>>显式定义所有剧本，优点是可枚举、可测试，缺点是一旦新增状态,所有涉及该状态的剧本都要改。

场景B：策略模式 —— 平行剧本集

比如支付渠道（微信、支付宝、银联），每个策略类就是一个独立剧本。优点：新增渠道只需加一个类，不改旧代码。陷阱：如果策略间有相互依赖，微信支付后要更新库存，支付宝支付后要发短信”，这种跨剧本逻辑容易写进策略类内部,导致剧本间耦合。

场景C：事件驱动 —— 隐式剧本

使用@EventListener + @Async，每个监听器处理一种事件，剧本被拆散到不同方法中。优点：扩展性强，缺点：调试困难，因为执行顺序不再由调用栈决定，而是由事件派发器决定，这种剧本是“隐形的”，如果没有文档,后人很难重建完整流程。

“剧本”过载的代价

我们先看一个反例：

public void handle(Order order, Action action) {
    if (order.getStatus() == Status.PENDING) {
        if (action == Action.PAY) {
            // 剧本1
        } else if (action == Action.CANCEL) {
            // 剧本2
        }
    } else if (order.getStatus() == Status.PAID) {
        if (action == Action.SHIP) {
            // 剧本3
        }
    }
    // ... 更多嵌套
}

这个案例预设了至少 2×5=10 种剧本（5个状态×2个动作），但实际业务可能只需要其中3种，多出来的7个分支是纯“防御性代码”——它们可能永远不会被执行，但在阅读时，程序员必须在大脑中模拟这些剧本,导致认知负荷飙升。

代价清单：

可读性：嵌套深度超过3层，代码审查效率下降50%以上。
维护性：修改一个剧本，需要排查所有if-else分支,容易漏改。
性能：虽然现代JIT会优化，但switch链在长分支下仍比哈希查找慢（微秒级，通常可忽略，但框架层不可忽略）。

如何判断“预设”是否合理？

核心指标：业务剧本的“变异频率” vs “确定性频率”。

如果某个剧本在需求文档中明确存在，且未来半年内不会删改，那么预设它是合理的，例如订单取消后自动退款,这是确定性剧本。
如果某个剧本是“以防万一”加上的，万一用户点击了取消但库存已扣”，那么这种剧本应该通过校验逻辑处理，而不是通过状态分支处理——校验失败直接抛异常，比在状态机里加一个“取消但扣库存”的分支更安全。

实用决策框架：

剧本类型	预设建议	替代方案
确定性业务规则	✅ 显式状态机或策略	无
低概率异常流程	❌ 不预设	用异常捕获 + 补偿事务
未来可能扩展	❌ 延迟到第一个真实需求	YAGNI原则（你不需要它）
外部系统交互（如回调）	✅ 设置超时/重试剧本	用事件+重试队列

实战问答：当面试官问“你这段代码预设了几种剧本？”

问题：你写的OrderService用了状态机，预设了哪些剧本？为什么不用简单if-else？

推荐回答（含深度） ：

“这个案例预设了5个核心剧本：支付、发货、完成、取消、超时关闭，我没有用if-else，是因为每个剧本涉及的副作用不同——支付要调微信API，发货要更新物流单号，取消要回滚库存，若用if-else，10种组合会导致循环复杂度超过15，测试用例难以穷尽，我用状态机 + 策略表，将‘状态转移’和‘副作用执行’解耦，这样新增一个剧本只需在表中加一行，避免改动既有逻辑。”

加分点（避免踩坑）：

主动说出“有一个剧本我没有预设：用户支付后立即申请退款但货已发出”，这时说明你用了RefundRequest事件 + InterventionHandler，而不是在状态机里加一个“已发货可退款”状态——因为那是真实运营规则，需要人工介入,不属于自动化剧本。
如果面试官追问“你怎么证明你的预设不冗余？” 回答：“我做了需求追踪矩阵，每个剧本对应一条用户故事或缺陷单，无对应需求的剧本一律移除，改用IllegalStateException拦截非法操作。”

回到最初的问题：这个java案例是否预设了多种剧本？ 答案不能简单地“是”或“否”，真正的问题是——你的案例是否预设了“恰当数量”的剧本，并且这些剧本是“有弹性的”而非“僵硬的”？ 好的Java设计，不是把所有可能路径都写进代码，而是为高确定性路径建立自动化剧本，为不确定或异常路径留出扩展点（如SPI、事件、回调），当你能清晰回答“我的代码里有多少个剧本，每个剧本对应什么业务事实”时，你就超越了90%的Java开发者。

最后一道思考题：如果你接手一个老系统，发现它的OrderService里嵌套了12层if-else，这相当于预设了多少种剧本？正确的重构方向应该是先抽状态机，还是先写文档？——答案：先补测试，再重构，因为测试是唯一能证明“剧本”不会在你重构时丢失的保险。