Возможности расширения шаблона посетителя Java

Question

Я изучал шаблон посетителей и наткнулся на этот полезный пример: https://stackoverflow.com/a/2604798/974594. Пост очень ясный и очень простой для понимания, хотя у меня возникли проблемы с пониманием последней части, начиная с:

С учетом вышесказанного, посетители, как правило, излишни, и у них есть тенденция к серьезному усложнению API, и может быть очень сложно определить нового посетителя для каждого нового типа поведения.

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

class FruitPricer : IFruitVisitor
{
    public double Price { get; private set; }
    public void Visit(Orange fruit) { Price = 0.69; }
    public void Visit(Apple fruit) { Price = 0.89; }
    public void Visit(Banana fruit) { Price = 1.11; }
}

Он работает, но в чем преимущество этой тривиальной модификации:

абстрактный класс Fruit

{
    public abstract void Accept(IFruitVisitor visitor);
    public abstract double Price { get; }
}

Я не понимаю, что он говорит здесь.Я имею в виду, если теперь он хочет реализовать функцию «цена», что нужно изменить / добавить в существующий код (на основе этого подхода к шаблону)? =

Answer 1

Ответ, на который вы ссылаетесь, значительно упускает из виду посетителя.В нем говорится, что «посетители используются для тестирования типов без ущерба для безопасности типов», что просто неверно.Книга GOF гласит: «Посетители позволяют вам определять новую операцию, не изменяя классы элементов, с которыми она работает».Посетителей, безусловно, можно использовать для тестирования объектов на предметах, отличных от шрифта, и для выполнения операций с объектами, которые не включают в себя тестирование.

Часто говорят «посетитель перебивает», но обычно говорят, что люди пытаютсяиспользовать Visitor для вещей, для которых он не предназначен, а затем найти этот сюрприз - он на самом деле не работает для него.

Постер прав в том, что второй фрагмент кода, который они цитируют, являетсяболее простой способ реализации функциональности, но он упускает из виду тот пункт, в котором предназначен посетитель, когда вы не хотите изменять класс Fruit.

Answer 2

Добавьте реализацию класса для каждого подкласса.

Дело в том, что иногда Visitor является избыточным, а функциональность может быть добавлена ​​менее абстрактным способом.1005 * Теперь, имеет ли смысл Fruit иметь Price, это другая проблема.Для Item может иметь смысл иметь цену, и Item имеет Fruit, или Fruit становится подклассом Item, или они составлены, или ...