Question

假设这个模型类：

public class Car extends Vehicle implements Visitable {
  .....
  void accept(VehicleVisitor visitor){
    visitor.visit(this);
  }  
  .....
}

使用访客是因为允许某些车辆被授予的决定是在很晚的时候（在Car class创建之后）做出的。

具有名为VehicleEvaluatorVisitor的基类的特定访客层次结构，其继承自CarVisitor，其目的是通知车辆是否值得奖励：

public class VehicleEvaluatorVisitor implements VehicleVisitor {

  boolean mustBeAwarded;

  public visit(Car car){
    ....
    mustBeAwarded= true;   //after some conditional
  }

  .... //other visit methods

  boolean mustVehicleBeAwarded(){
    return mustBeAwarded;
  }

}

此设计的目标是允许客户遍历任何车辆集合，以了解必须授予哪辆车：

  ...
    VehicleEvaluatorVisitor visitor = new VehicleEvaluatorVisitor ();
    for(Vehicle vehicle : vehicules){
      vehicle.accept(visitor);
      boolean mustToBeAwarded = visitor.mustVehicleBeAwarded();
      .....
  ...

我的问题是：这是一个可接受的设计吗？（当然，汽车和奖励概念只是一个理论上的例子）

Answer 1

为访客设立州是可以的。

但在大多数情况下，它过于复杂。

考虑让访问者使用泛型，您的代码将变为：

访客界面

public interface VehicleVisitor<T> {
    ...
    T visit(Car car);
    ...
}

有车等级

public class Car extends Vehicle implements Visitable {
    ...
    <T> T accept(VehicleVisitor<T> visitor){
        return visitor.visit(this);
    }
    ...
}

访客实施

public class VehicleEvaluatorVisitor implements VehicleVisitor<Boolean> {

    public Boolean visit(Car car){
        ...
        return true;
        ...
    }

}

Answer 2

关于Design Pattern清洁状态的书，访客可以积累状态（第52页“后果”一节中的第5点）。其余的是实现细节; - ）

Answer 3

我看不出这个设计有任何问题。它看起来像访问者模式的合理用例。

您已将奖励评估逻辑封装在访问者中，而不是将其暴露在Car类或客户端类中。这是使用访客模式的目的之一。当然，如果需要，您可以稍后添加更多类型的访问者。

访客模式可能包含一些状态？

3 个答案: