单方法实现子类差异化验证技巧

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《单方法实现子类差异化验证逻辑》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

本文介绍一种基于依赖注入与模板方法模式的设计方案：将验证器（Validator）作为成员变量注入到具体子类中，使抽象父类 `Vehicle` 的 `runAllValidations()` 方法完全无参、无分支，子类按需组合自身所需的验证逻辑，彻底规避类型判断与冗余参数传递。

在面向对象设计中，当需要对不同子类执行“同名但行为各异”的批量操作（如统一触发校验），又希望避免 instanceof 判断或方法签名膨胀（如传入所有可能的 validator）时，核心思路是：将“差异”提前固化到对象状态中，而非延迟到调用时刻决策。

下面以 Vehicle 体系为例，展示如何优雅实现零条件、零冗余参数的 runAllValidations()：

✅ 正确设计：依赖注入 + 模板方法

首先，重构 Vehicle 及其子类，将验证器作为实例字段持有，并提供 setter 注入入口：

abstract class Vehicle {
    protected Tire tire;
    protected TireValidator tireValidator;

    public void setTireValidator(TireValidator tireValidator) {
        this.tireValidator = tireValidator;
    }

    protected void checkTire() {
        if (tireValidator == null) {
            throw new IllegalStateException("TireValidator not set");
        }
        tireValidator.check(tire);
    }

    public abstract void runAllValidations(); // 无参！无 if！
}

子类仅关注自身专属验证逻辑，复用父类已注入的通用验证器：

class Bike extends Vehicle {
    private Brakes brakes;
    private BrakeValidator brakeValidator;

    public void setBrakeValidator(BrakeValidator brakeValidator) {
        this.brakeValidator = brakeValidator;
    }

    protected void checkBrakes() {
        if (brakeValidator == null) {
            throw new IllegalStateException("BrakeValidator not set");
        }
        brakeValidator.check(brakes);
    }

    @Override
    public void runAllValidations() {
        checkTire();   // 复用父类逻辑
        checkBrakes(); // 扩展自身逻辑
    }
}

class Car extends Vehicle {
    private Gas gas;
    private GasValidator gasValidator;

    public void setGasValidator(GasValidator gasValidator) {
        this.gasValidator = gasValidator;
    }

    protected void checkGas() {
        if (gasValidator == null) {
            throw new IllegalStateException("GasValidator not set");
        }
        gasValidator.check(gas);
    }

    @Override
    public void runAllValidations() {
        checkTire(); // 复用父类逻辑
        checkGas();  // 扩展自身逻辑
    }
}

✅ 调用端：简洁、类型安全、可扩展

在 main 或业务层中，明确知道对象类型时完成验证器注入，后续即可统一调用：

public static void main(String[] args) {
    TireValidator tireValidator = new TireValidator();
    BrakeValidator brakeValidator = new BrakeValidator();
    GasValidator gasValidator = new GasValidator();

    // 创建并注入 —— 类型明确，注入精准，无冗余
    Bike bike = new Bike(/* ... */);
    bike.setTireValidator(tireValidator);
    bike.setBrakeValidator(brakeValidator);

    Car car = new Car(/* ... */);
    car.setTireValidator(tireValidator);
    car.setGasValidator(gasValidator);

    // 统一调用，无需关心具体类型
    List<Vehicle> vehicles = List.of(bike, car);
    vehicles.forEach(Vehicle::runAllValidations); // ✅ 完全解耦

    // 甚至可直接调用
    bike.runAllValidations();
    car.runAllValidations();
}

⚠️ 注意事项与最佳实践

• 注入时机：验证器应在对象构造后、首次调用 runAllValidations() 前完成注入；建议在 Builder 模式或工厂中封装此逻辑。
• 空值防护：如示例所示，在 checkXxx() 中主动检查 validator 是否为空，避免 NullPointerException，提升错误可追溯性。
• 可测试性：每个子类的 runAllValidations() 行为完全由其持有的 validator 决定，单元测试时可轻松 Mock 各 validator。
• 扩展性：新增子类（如 Truck 需校验 Cargo 和 Lights）只需添加对应字段、setter 和 checkXxx() 方法，并在 runAllValidations() 中组合调用，无需修改任何已有类或添加 if 分支。
• 替代方案对比：
  • ❌ 传入全部 validator → 违反“最少知识原则”，破坏封装；
  • ❌ instanceof 分支 → 违反开闭原则，每增一类需改调度逻辑；
  • ✅ 本方案 → 符合单一职责、依赖倒置、里氏替换原则，是典型的策略模式+模板方法融合实践。

该设计将“什么要验证”（类型决定）与“如何验证”（validator 实现）分离，把运行时分支转化为编译时结构，真正实现清晰、健壮、可持续演进的验证体系。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~