Enum-switch антипаттерн

Выбрасывать исключение в конце вынуждает компилятор, которому нужно обеспечить гарантированный результат каждой функции, а проконтролировать полноту покрытия множества значений оператором switch компилятор C# не может.

Лечится плагином-анализатором к рослину. Зачем из этого целую проблему раздувать и обзывать антипаттерном — не ясно.

Чтобы не использовать enum, заведите интерфейс. Интерфейс должен возвращать информацию о свойствах объекта из описываемого множества. [...] Теперь все функции, содержащие switch, если они у вас были, удалите. Они вам больше не понадобятся, потому что код обрабатывает не конкретные объекты, а их свойства.

Круто. Теперь представьте себе, что у меня есть внешний по отношению к этому интерфейсу код (т.е., интерфейс и его реализации лежат в библиотеке, а мой код просто эту библиотеку потребляет), и мне надо расширить поведение — например, мне надо в зависимости от пары языков предоставить конвертер из одного языка в другой. Ваши предложения?

Не говоря уже о том, что enum — это всего лишь формализованное конечное множество, а преобразование из одного множества в другое — это одна из базовых операций в функциональном программировании, и что в ней плохого, спрашивается?

состояния конечного автомата

Адвокат дьявола просит напомнить вам про паттерн State.

P.S.

проконтролировать полноту покрытия множества значений оператором switch компилятор C# не может.

Почему не может-то?

По статье же — в ней было бы уместно показать еще и проблемы с обновлением enum'a (добавил поле — обнови все switch блоки). Сложности не добавит, но информация будет чуть более полной.
Пардон, пропустил в тексте.

Я сделать как «у порядочных сволочей» нельзя? В смысле — засунуть все эти методы в сам enum и бить «палкой по рукам» людей, которые будут напрямую на варинты enum'а ссыслаться вне его? В C# синтаксис, конечно, не так удобен, как в Java, но и не то, чтобы уж прямо ужасен.

После того, как вы это сделаете неожиданно весь пафос про «множество перечисляемых объектов должно быть или фиксированным, в котором уже не появится новых значений, или внутренним, которое полностью определяется и используется только внутри одной программы» неожиданно исчезает: если enum сам про себя умеет отвечать всё, что нужно — то, собственно, почему бы и нет?

Ветвления. Что с ними можно сделать
https://habrahabr.ru/post/112123/

только вместо C# — C++

Со статьей, в целом, я согласен. Однако мой опыт отличается от Вашего, нынче наблюдаю обратный процесс, люди начитавшись книг по ООП(что само по себе и неплохо) начинают выделять интерфейсы и творить «энти фабрики, стратегии» там где это излишне, так ещё для большей расширяемости интерфейс выкидывают в отдельную либу, и мы имеем пятьсотмиллионов проектов). Если расширяемость в данном месте не предполагается, можно и со switch начать, а далее перескочить недолго(если конечно не доводить до портянок в десяток case, которые используются в десятке мест).

Впервые работаю над приложением с постоянными веб запросами на каждый чих, после некоторых метаний остановился на варианте с перечислением для запросов (язык java, применение в android). Имеется интерфейс, в нем перечисление запросов в параметризованном виде с доп информацией, которая разбирается при выполнении запроса. Выглядит это так:

interface QueryParams {
  String queryGET = "GET";
  String queryPOST = "POST";
  int queryGroup_list = 1;
  int queryGroup_details = 2;
  int queryGroup_default = 0;

  enum queryParams {
    req_login("login?phonenumber=%1$s&password=%2$s", queryGET, queryGroup_default),

    req_TV_orders("get_naryad_list?tehnology=1", queryGET, queryGroup_list),
    req_PHONE_orders("get_naryad_list?tehnology=2", queryGET, queryGroup_list),
...
  }
}

Вызов через асинкТаск класс, например, для логина выглядит так

new Async_DB_work(
context, 
queryParams.req_login, 
mHandler, 
findViewById(R.id.progress_overlay)
).execute("логин", "пароль");

В самом классе есть метод, который из queryParams.req_login берет строку-запрос (через стринг билдер в %1$s и %2$s подставляются логин и пароль) и метод запроса и отправляет всё это добро на вебсервис.

Смущающий меня момент как раз таки в километровом свиче, который обрабатывает ответ в зависимости от запроса (а точнее, в зависимости группы, в которую я отнес этот запрос). И не спасает даже параметр группировки, который я ввел в элементы перечисления для однотипных ответов.

Можно ли как-то облагородить схему?

Фреймворк, интерфейс, провайдер — унылое императивное ООП. Не надо этого. В F#-пе я использую примерно такой подход:

type Language =
    | Java
    | CSharp
    | TSQL
    | CustomLang of LangInfo

    static member info = function
        | Java ->   LangInfo.new' "java"  true "bean.svg"
        | CSharp -> LangInfo.new' "cs" true "cs.svg"
        | TSQL  ->  LangInfo.new' "sql" false "tsql.svg"
        | CustomLang x -> x

module Helpers = 
    let langConfig : LangInfo list = 
        // взять конфигурацию из внешнего источника
        ...

type Language with
    static member values =         
        [ Java; CSharp; TSQL ] @ (List.map CustomLang Helpers.langConfig )

1. На мой взгляд пример, вокруг которого строится повествование, несколько надуман.
Именно в этом примере проблема кроется вовсе не в самой сущности перечислений, а в неверном их употреблении. God-объект возник вовсе не из-за того, что было использовано перечисление, а из-за того, что нарушен SRP. Никто не мешал поместить перечисление в корне компановки и инкапсулировать логику, подходящую конкретным языкам в отдельные сущности. Использовать switch с перечислением так же вовсе не обязательно. Ситуацию удобнее разрулить словарем — пожалуйста.

2. Если ставить вопрос о необходимости предоставления возможности подключать к готовому продукту новые языки или разрабатывать их в параллель. То связь Язык — Реализация должна перекочевать в конфигурацию. И естественным образом никаких перечислений не будет, т.к. изначально из постановки ясно, что набор поддерживаемых языков расширяем. Логично, что это только в том случае, если и язык, и реализация могут быть предоставлены извне.

3.

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

Компилятор не вынуждает выбрасывать исключения. Вынуждает логика — если мы не можем обработать неизвестный элемент без ошибки, то не важно, строка это или перечисление или что-то иное.
Исключением мы лишь выражаем тот факт, что реализация не допускает произвольных значений, что если появится новый элемент, то его обработку нужно реализовать.
В примере с иконками можно было вернуть специальную иконку для неподдерживаемого языка в default.
Т.е. проблема опять же не в перечислении, а в том, что на момент реализации мы можем не иметь возможности предусмотреть поведение по умолчанию. И отказ от перечисления нас не спасет с учетом корректной реализации (п.1).

4.

Между TransactSQL и Java вообще может не быть ничего общего кроме того, что кто-то захотел открыть их в одном текстовом редакторе

И этого вполне достаточно для их объединения на соответствующем уровне абстракции. Например, в списке поддерживаемых языков. Проблема из п.2 — перечисление просто не подходит для этой сущности.
Но не в самом перечислении проблема, как языковой конструкции. Аналогичная картина с предложением использовать интерфейс: Выясняется, что сущность Язык более сложная в контексте использования в коде, естественно, что перечисление не подходит для ее отражения.

Для чего я считаю нормальным использовать перечисления.
Предположим, что у нас есть конченый на момент реализации список состояний сущности БД.
Например, On и Off.

При чтении из БД я преобразую эти значения в соответствующее перечисление:
public enum SomeState
{
On,
Off
}

Что я получаю: Методы, использующие эти состояние будут строго типизированы.
Например:
public interface IStateHandlerFactory
{
IStateHandler Create(SomeState state);
}

Если не использовать перечисления, то какие у нас есть варианты? Использовать само значение из БД. Предположим, что мы храним строки «On», «Off».
Что получаем:
public interface ISomeStateHandlerFactory
{
IStateHandler Create(string state);
}

С точки зрения клиента этого интерфейса может быть совершенно непонятно, какое значение туда можно передать, откуда его взять. Если у сущности несколько «состояний»?
Так же, не посмотрев в БД, сложно определить все возможные значения.
Как обрабатывать строку, по которой будет работать фабрика? Только сравнивая с самой строкой — а это уже дублирование. Как от него уйти — статический класс с константными строками, ничего не напоминает? Не наше ли это перечисление?

Или еще проще. Предположим, в БД мы включаем/выключаем функционал.
И в коде надо написать:
if (entity.State == State.Off) return;

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