Реализация пользовательского шаблона посетителя

1) Это неправильная реализация шаблона?

Нет, это все еще шаблон посетителя GoF. Возможность IPaymentCalculationsVisitor обращаться к двум различным методам не меняет природу паттерна. Однако, поскольку он объединяет логику для двух разных посещений, вы можете подумать о принципах SOLID.

• Являются ли оба метода частью единой ответственности, т. е. будут ли они оба изменяться по одним и тем же причинам, или один метод потенциально может измениться независимо от другого?
• Будут ли потенциальные клиенты всегда зависеть от обоих методов? Разделение интерфейсов разделит CalculateFee и CalculateExtraCharge, чтобы клиенты могли использовать одно без другого.

Обратите внимание, что шаблон посетителя позволяет добавлять новое поведение в иерархию типов IPaymentMethod без необходимости изменять дочерние классы, такие как CreditCard и Check. Разделив интерфейс посетителя на FeeVisitor и ExtraChargeVisitor, оба можно передать в один метод посещения.

2) Должен ли я всегда называть свой метод «посещением»?

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

2) Должен ли я всегда называть свой метод «посещением»?

Нет, назовите метод более специфичным для домена способом.

1) Это неправильная реализация шаблона?

Глядя на вашу реализацию, я нашел ее немного другой.

public class CreditCard : IPaymentMethod
{
    public decimal Amount { get; set; }

    public decimal GetFee(IPaymentCalculationsVisitor visitor)
    {
        return visitor.CalculateFee(this);
    }

    public decimal GetExtraCharge(IPaymentCalculationsVisitor visitor)
    {
        return visitor.CalculateExtraCharge(this);
    }
}

Одним из методов объектно-ориентированного программирования является инкапсуляция, при которой объект хранит свои данные (не раскрывая их внешнему миру).
С помощью паттерна "Посетитель" мы можем предоставить дополнительную функциональность объекту, не раскрывая его данные снаружи.

Поскольку внутренние данные не отображаются снаружи объекта, посетителю необходимо «посетить объект внутри», где объект сможет предоставить посетителю требуемые значения, не раскрывая эти значения снаружи (не делая эти значения общедоступными).

Для случая вопроса мы можем передать калькулятор (посетитель) в класс CreditCard, где калькулятор будет принимать только необходимые данные в качестве аргументов (обратите внимание, только необходимые значения, а не весь объект).

public class CreditCard : IPaymentMethod
{
    // Following OOP principles and keep data private
    private decimal _amount;

    public CreditCard(decimal amount) => _amount;

    public decimal GetFee(IPaymentCalculationsVisitor visitor)
    {
        return visitor.CalculateFee(_amount); // provide only required data
    }

    public decimal GetExtraCharge(IPaymentCalculationsVisitor visitor)
    {
        return visitor.CalculateExtraCharge(_amount); // provide only required data
    }
}

При таком подходе класс калькулятора (посетителя) не будет зависеть от классов, которые он может посещать. На самом деле он может посетить любой класс, который может предоставить необходимую информацию.

В вашем конкретном случае, когда CreditCard предоставляет данные (имеющие общедоступное свойство Amount) - вы можете удалить избыточный шаг и передать объект кредитной карты прямо в расчеты

 public void ProcessPayment()
 {
     var paymentMethods = new List<IPaymentMethod>()
     {
            new CreditCard(),
            new Check()
     };

     var calculations = new PaymentCalculationsVisitor();

     foreach (var paymentMethod in paymentMethods)
     {
        //First i need to get the fee
        var fee = calculations.GetFee(paymentMethod);

        //Then i do do some other stuff, validations, other calculations etc

        //Finally i get the extra charge
        var extraCharge = calculations.GetExtraCharge(paymentMethod);
    }
}