本文介绍一种基于依赖注入与模板方法模式的设计方案：将验证器（validator）作为成员变量注入到具体子类中，使抽象父类 `vehicle` 的 `runallvalidations()` 方法完全无参、无分支，子类按需组合自身所需的验证逻辑，彻底规避类型判断与冗余参数传递。
在面向对象设计中，当需要对不同子类执行“同名但行为各异”的批量操作（如统一触发校验），又希望避免 instanceof 判断或方法签名膨胀（如传入所有可能的 validator）时，核心思路是：将“差异”提前固化到对象状态中，而非延迟到调用时刻决策。
下面以 Vehicle 体系为例，展示如何优雅实现零条件、零冗余参数的 runAllValidations()：
✅ 正确设计：依赖注入 + 模板方法
首先，重构 Vehicle 及其子类，将验证器作为实例字段持有，并提供 setter 注入入口：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
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 实现）分离，把运行时分支转化为编译时结构，真正实现清晰、健壮、可持续演进的验证体系。
