Перечисления и регистры

Question

Я ищу веские причины, если мы должны попытаться избежать операторов switch / case и как это сделать для перечислений, и предложений как, рассмотрим следующий пример: (обратите внимание, что этот switch / case может быть разбросан по всему кодуbase)

switch (theEnum)
{
    case MyEnum.Enum1:
        // dosomething
    case MyEnum.Enum2:
        // do something
    case MyEnum.Enum3:
        // do something
    default:
       throw new Exception("Unsupported enumeration: " + theEnum.ToString());

}

против

public Dictionary<MyEnum, StrategyBase> BuildMapper()
{
    var mapper = new Dictionary<MyEnum, StrategyBase>();
    mapper[MyEnum.Enum1] = new Strategy1();
    mapper[MyEnum.Enum2] = new Strategy2();
    mapper[MyEnum.Enum3] = new Strategy3();
return mapper;
}

BuildMapper()[MyEnum.Enum1].DoSomething();

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

Можно утверждать, что такие принципы, как switch / else, будут нарушать, например, open-close.

Answer 1

Я бы пошел за выключателем, если он просто в одном или двух местах. Если, как вы говорите, «этот переключатель / регистр может быть разбросан по всей базе кода», перейдите ко второму решению.

Это не только больше ОО, что хорошо, но и легче поддерживать в вашей ситуации. Опасения по поводу производительности и потребления памяти в этом случае совершенно не имеют значения, сначала нужно упростить обслуживание и оптимизировать при необходимости (но я не думаю, что вам когда-либо потребуется оптимизировать это ).

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

Answer 2

Я бы сделал BuildMapper статическим (также только для чтения), потому что он всегда будет возвращать вам один и тот же словарь.

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

Answer 3

Для ОО вы должны использовать Шаблон посетителя

Answer 4

Полагаю, вы сравниваете апельсины и яблоки.

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

Конечно, этот переключатель потребляет гораздо меньше памяти, чем довольно сложный объект, такой как Словарь.

Наконец, перечисления не ограничены объявленными параметрами, но могут быть объединены как «флаги». Эта функция не будет доступна при использовании хэш-карты.

Это удовлетворительно?

Answer 5

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

Answer 6

Я думаю, что первый вариант лучше, потому что он выглядит более читабельным и явным.