Стратегический шаблон - это правильно?

Это более или менее правильный способ сделать это красиво. В какой-то момент вашего кода вам придется принять решение, следует ли использовать v1 или v2, поэтому вам все равно придется иметь условный оператор (if или switch). Однако при использовании стратегии и фабрики (фабричный метод или фабричный класс) вы принимаете это решение централизованно.

Однако я бы сделал свой фабричный метод для абстрактного класса статическим. Кроме того, я бы использовал шаблон метода шаблона: то есть общедоступный, непереопределяемый метод GetData, который вызывает защищенный виртуальный (абстрактный) метод, который должен быть переопределен в конкретной реализации.

public abstract class SoapProcessor
{

    protected SoapProcessor() { /* protected constructor since public is of no use */  }

    public static SoapProcessor Create( SoapVersion version )
    {
          switch( version )
          {
               case SoapVersion.Version1 : return new SoapV1Processor();
               case SoapVersion.Version2 : return new SoapV2Processor();
               default: throw new NOtSupportedException();
          }
    }


    public string[] GetData()
    {
         return GetDataCore();
    }

    protected abstract GetDataCore();
 }

}

Есть разница, если у вас есть переключатели только на фабриках или во всем коде. У вас есть свое решение (какую реализацию выбрать) в одной точке.

В подобных случаях я выбираю между рефлексией и if/case по следующему критерию: если поддержка новых версий должна добавляться динамически (как плагины), я выбираю рефлексию, иначе - if/case. Как упоминалось в других ответах, внутри фабричного метода должно быть единое место для создания вещей. Стоит отметить, что Strategy — это поведенческий паттерн, а то, что вы просили, похоже на творчество.

Вам не нужны операторы switch или if.
Просто используйте делегирование.
Т.е. конкретные реализации абстрактного класса будут выполняться по мере необходимости (например, SoapV1, SoapV2 и т. д.), а клиент устанавливает соответствующий экземпляр в ссылке на объект.
У вас есть только ссылка на базовый класс и соответствующий подкласс устанавливается клиентом. Ваш код просто вызывает методы базового класса (который во время выполнения является одной из производных реализаций). Например. пример (ОТВЕТСТВЕННОСТЬ: код не скомпилирован. Только образец)

public abstract class SoapHandler
{

    protected abstract string[] getData();
 }

public class SoapHandlerV1 extends SoapHandler
{

    public string[] getData(){
        //V1 implementation
    }

}
public class SoapHandlerV2 extends SoapHandler
{

    public string[] getData(){
        //V2 implementation
    }

}


public class SoapProcessor{

    public SoapHandler soapHandler;

    public setSoapHandler(SoapHandler h)
    {
                soapHandler = h;
    }

    public String[] getData(){
        //delegate to specific version
        soapHandler->getData();
    }
}


//in your code
SoapProcessor soap = new SoapProcessor();
soap.setSoapHandler(new SoapHandlerV1());
String[] soapData = soap.getData();//Will get the appropriate version
//use soap data
//do stuff

Проверьте пример GoF для стратегии, чтобы увидеть, что я имею в виду, если это не ясно

Поскольку version известен только во время выполнения, он определенно сведется к некоторому условному выражению (если или переключаться, или использовать карту между строками и прототипом и т. д.).

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

Вы должны программировать интерфейс, а не реализацию.

Имейте отдельный сервисный интерфейс, который вы можете использовать со стороны вашего клиента.

public interface IService
{
    string[] GetData();
}

и закодируйте своего клиента как -

IService srvice = ServiceFactory.GetProxy();
string[] value = service.GetData();

Таким образом, ваш клиентский код не изменится при изменении прокси-сервера службы.

Затем вы для начала можете перенести условную логику для создания соответствующего прокси в класс ServiceFactory. Позже вы можете изменить его, чтобы удалить условную логику, используя следующие методы, такие как:

1. Чтение класса реализации и имени сборки из файла конфигурации и создание его с помощью отражения.
2. Создание словаря экземпляров прокси с мыльной версией в качестве ключей.