Может ли шаблон посетителя содержать некоторые состояния?

Question

Предположим, этот класс модели:

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

Использование посетителя, поскольку решение о выдаче определенных транспортных средств было принято очень поздно (после создания класса автомобилей).

И определенная иерархия Visitor с базовым классом с именем 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 очищает состояние, в котором посетители могут накапливать состояние (пункт 5 в разделе «Последствия», стр. 336).Остальное - деталь реализации; -)

Answer 3

Я не вижу никаких проблем с этим дизайном. Это выглядит как разумный вариант использования шаблона посетителя.

Вы инкапсулировали логику оценки вознаграждения внутри посетителя, вместо того, чтобы выставлять ее в классе Car или в классе клиента. Это одна из целей использования шаблона посетителя. И, конечно, вы сможете добавить больше типов посетителей позже, если потребуется.