Фабрика на основе входной переменной

То, что вы там реализовали, - это шаблон стратегии, который по-прежнему является допустимым подходом. В любом случае, если вы хотите заменить весь переключатель и сделать его более удобным в обслуживании, вы можете использовать этот

public interface IProcessMail
{
     bool CanProcess(MailType type);
     MailResult GetMailResult(Mail mail);
}

Каждый почтовый процессор реализует этот интерфейс. Тогда у вас будет это

 public class MailProcessorExecutor
 {
     public MailProcessorSelector(IEnumerable<IProcessMail> processors)
     {
           _processors=processors;
     }

     public MailResult GetResult(Mail mail)
     {
         var proc=_processor.FirstOrDefault(p=>p.CanProcess(mail.MailType));
         if (proc==null)
         {
             //throw something
         }

         return proc.GetMailResult(mail);
     }

    static IProcessMail[] _procCache=new IProcessMail[0];

     public static void AutoScanForProcessors(Assembly[] asms)
     {
       _procCache= asms.SelectMany(a=>a.GetTypesDerivedFrom<IProcessMail>()).Select(t=>Activator.CreateInstance(t)).Cast<IProcessMail>().ToArray();
     }

     public static MailProcessorExecutor CreateInstance()
     {
        return new MailProcessorExecutor(_procCache);
     }
  }

  //in startup/config 
  MailProcessorExecutor.AutoScanForProcessors([assembly containing the concrete types]);

 //usage
 var mailProc=MailProcessorExecutor.CreateInstance();
var result=mailProc.GetResult(mail);

Итак, дело в том, что будет объект, отвечающий за выбор и выполнение процессоров. Статические методы являются необязательными, метод AutoScan ищет во всех заданных сборках конкретные реализации IPocessMail, а затем создает их экземпляры. Это позволяет вам добавлять/удалять любой процессор, и он будет использоваться автоматически (никаких дополнительных настроек не требуется). Также здесь нет переключателя и никогда не будет. Обратите внимание, что GetTypesFromDerived — это вспомогательный метод, который я использую (это часть моей библиотеки CavemanTools) и активатора. требуется конструктор без параметров. Вместо этого вы можете использовать DI-контейнер для получения экземпляров (если вы используете один или у процессоров есть deps)

Если вы используете контейнер внедрения зависимостей, вам не нужен метод CreateInstance. Просто зарегистрируйте MailProcessorExecutor как синглтон и вставьте его (передайте его как аргумент конструктора) туда, где вам это нужно.

В вашем случае простого рефакторинга в метод должно быть более чем достаточно.

private ISingleMailProcessor CreateMailProcessor(MailType type)
{
  switch (type)
  {
      case MailConnector.MailType.AcronisBackup:
         return new AcronisProcessor();
      case ......etc.
  }
}

public MailResult GetMailResult(mail)
{
  ISingleMailProcessor mailprocessor = CreateMailProcessor(mail.MailType);
  return mailprocessor.ProcesMail(mail);
}

Я не думаю, что использование factory поможет вам здесь. Фабрика имела бы смысл, если бы «тип почты» определялся вне кода, который фактически создает и отправляет саму почту.

Затем для каждого типа отправляемой почты будет определенная фабрика с интерфейсом для создания объекта отправителя. Но даже тогда это имело бы смысл, если бы вам каждый раз требовался новый экземпляр отправителя. В вашем случае просто передать интерфейс, который у вас есть прямо сейчас, должно быть более чем достаточно.

Вы можете прочитать мое мнение о фабриках здесь: https://softwareengineering.stackexchange.com/a/253264/56655

Для этого вам понадобится шаблон Visitor.

{
    public MailResult GetMailResult(mail)
    {
        _objectStructure.Visit(mail)
    }
    ObjectStructure _objectStructure= new ObjectStructure();
    constructor() {
         _objectStructure.Attach(new AcronisBackupVisitor());
         _objectStructure.Attach(new ...)
    }
}

class AcronisBackupVisitor: Visitor {
    public override void Visit(HereComesAConcreteTypeDerivedFromMail concreteElement)
    {
         // do stuff
    }
    public override void Visit(HereComesAConcreteTypeDerivedFromMailOther concreteElement)
    {
        //don't do stuff. We are not in the right concrete mail type
    }
}

Таким образом, мы можем различать динамический тип конкретного Mail, который вы получаете. Просто сделайте Mail абстрактным и извлеките из него почту Acronis и другие типы почты. Я начал реализацию этого примера с здесь.

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

Подводя итог веб-трансляции, вы могли видеть, что чем больше вы хотите следовать принципам OpenClosed в проблемной области «создания», тем менее безопасным для типов вы можете работать.

В результате абстрактная фабрика может также работать с некоторыми более динамическими значениями, такими как строки. Например, у вас может быть метод.

string GetAllPossibilities(); // Returns all possible kinds that can be constructed

и связанные

T Create<T>(string kind)

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

Таким образом, ваш вызов может быть примерно таким:

Factory.Create("Acronis") // Your Marker

Factory.Create("MYNameSpace.AcronisProcessor")  //TypeName

Factory.Create<AcronisProcessor>() //Type 

Таким образом, у вас не будет операторов switch вне Factory. Внутри фабрики у вас могут быть некоторые или вы могли бы подумать о создании какого-то динамического объекта.

В Factory все еще могут быть операторы swithc, переключающие ваш самодельный идентификатор или код, которые делают что-то вроде

var type = Type.GetType(kind);
return Activator.CreateInstance(type) as T;

Но поскольку это отделено от логики основного домена, оно больше не имеет такой важности, как раньше.

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

Но есть еще какая-то глубинная семантическая зависимость.

РЕДАКТИРОВАТЬ: Как вы можете видеть в обсуждении ниже, я отрезал некоторые детали, так как я думаю, что они размывают основную мысль (OpenClosed Principales и Factory Pattern). Но есть еще некоторые моменты, о которых не следует забывать. Например, «Что такое корень приложения и как его устроить». Чтобы получить все подробности, веб-трансляция (а также другие на этом сайте) - гораздо лучший способ узнать эти подробности, чем этот пост здесь.