分支逻辑的软件设计模式？测试自动化Page Object代码冗余优化

嘿，刚好我之前也踩过类似Page Object冗余的坑，来给你唠唠实用的思路！

一、适用于分支逻辑的常见设计模式 #

先回应你第一个问题，适合处理分支逻辑的设计模式除了你提到的几个，还有这些高频实用的：

• Strategy模式：把不同分支逻辑封装成独立策略类，通过上下文动态切换，适合分支逻辑差异大、需要灵活替换的场景。
• 简单工厂模式：通过工厂类根据输入参数创建不同对象，特别适合分支逻辑是生成不同实例的场景（和你当前问题高度契合）。
• State模式：适合对象状态变化驱动分支逻辑的场景，比如页面状态切换后触发不同交互逻辑。
• Chain of Responsibility：适合需要按顺序处理请求、每个节点决定是否处理或传递的分支场景，比如多步骤表单校验。

二、解决你Page Object冗余的极简方案 #

你当前的问题核心是重复的点击逻辑+不同页面对象返回，完全不需要用State或责任链这种重模式，一个通用方法就能搞定，几乎不用重构原有代码：

方案：泛型通用跳转方法（支持Java/TypeScript等主流语言） #

把重复的clickSubmitButton()逻辑抽出来，把返回的页面对象类型作为参数传入，用泛型实现通用跳转：

示例代码（Java版）

class Checkout { 
    // 保留原有私有点击逻辑
    private void clickSubmitButton() { 
        // 你的点击提交按钮实现
    }

    // 通用跳转方法，传入目标页面的Class
    public <T> T gotoNextPage(Class<T> targetPageClass) throws InstantiationException, IllegalAccessException {
        clickSubmitButton();
        // 反射创建目标页面对象并返回
        return targetPageClass.newInstance();
    }
}

调用方式

// 跳转到信用卡页面
CreditCardPage creditCardPage = checkout.gotoNextPage(CreditCardPage.class);
// 跳转到PayPal页面
PaypalPage paypalPage = checkout.gotoNextPage(PaypalPage.class);
// 跳转到错误页面
ErrorPage errorPage = checkout.gotoNextPage(ErrorPage.class);

如果是TypeScript/JavaScript版

class Checkout { 
    private clickSubmitButton() {
        // 你的点击提交按钮逻辑
    }

    gotoNextPage<T>(pageConstructor: new () => T): T {
        this.clickSubmitButton();
        return new pageConstructor();
    }
}

调用方式

const creditCardPage = checkout.gotoNextPage(CreditCardPage);
const paypalPage = checkout.gotoNextPage(PaypalPage);
const errorPage = checkout.gotoNextPage(ErrorPage);

为什么这个方案适合你？ #

• 零冗余：把N个重复方法压缩成1个，后续新增页面只需要传入对应的类即可，不用再写新方法。
• 侵入性极低：只需要新增一个通用方法，原有点击逻辑完全保留，不需要重构整个Checkout类。
• 复杂度低：不需要引入额外的模式或类，理解和维护成本都很低。

如果以后跳转逻辑需要加入不同前置判断（比如某些页面需要先勾选协议），再考虑抽成Strategy策略类也不迟，现在这个方案完全能解决你当前的问题。

内容的提问来源于stack exchange，提问作者nhle