Когда перечисления НЕ являются запахом кода?

дилемма

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

Поэтому я ищу руководящие принципы и / или варианты использования, в которых перечисления НЕ являются запахом кода и фактически являются допустимой конструкцией.

Источники:

«ПРЕДУПРЕЖДЕНИЕ. Как правило, перечисления являются запахами кода и должны быть преобразованы в полиморфные классы. [8]» Seemann, Mark, Dependency Injection, .Net, 2011, p. 342

[8] Мартин Фаулер и др., Рефакторинг: Улучшение дизайна существующего кода (Нью-Йорк: Аддисон-Уэсли, 1999), 82.

контекст

Причиной моей дилеммы является торговый API. Они дают мне поток данных о тиках, отправляя этот метод:

void TickPrice(TickType tickType, double value)

где enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... }

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

Dictionary<TickType,double> LastValues

Мне это показалось правильным использованием перечисления, если они используются в качестве ключей. Но у меня возникают другие мысли, потому что у меня есть место, где я принимаю решение на основе этой коллекции, и я не могу придумать, как бы я мог исключить оператор switch, я мог бы использовать фабрику, но эта фабрика все еще будет иметь переключить заявление где-нибудь. Мне казалось, что я просто перемещаю вещи, но все еще пахнет.

Легко найти DON'Ts перечислений, но не так просто, и я был бы признателен, если бы люди могли поделиться своим опытом, плюсами и минусами.

Второстепенные мысли

Некоторые решения и действия основаны на них, TickTypeи я не могу придумать способ устранить операторы enum / switch. Самым чистым решением, которое я могу придумать, является использование фабрики и возвращение реализации на основе TickType. Даже тогда у меня все еще будет оператор switch, который возвращает реализацию интерфейса.

Ниже приведен один из примеров классов, где у меня есть сомнения, что я могу использовать неправильное перечисление:

public class ExecutionSimulator
{
  Dictionary<TickType, double> LastReceived;
  void ProcessTick(TickType tickType, double value)
  {
    //Store Last Received TickType value
    LastReceived[tickType] = value;

    //Perform Order matching only on specific TickTypes
    switch(tickType)
    {
      case BidPrice:
      case BidSize:
        MatchSellOrders();
        break;
      case AskPrice:
      case AskSize:
        MatchBuyOrders();
        break;
    }       
  }
}

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

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

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

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

В вашем случае TickType не соответствует разным поведениям. Это разные типы событий или разные свойства текущего состояния. Поэтому я думаю, что это идеальное место для перечисления.

При передаче данных перечисления не имеют запаха кода

ИМХО, при передаче данных использовать enumsдля указания того, что поле может иметь значение из ограниченного (редко меняющегося) набора значений, хорошо.

Считаю предпочтительным передачу произвольной stringsили ints. Строки могут вызывать проблемы из-за изменений в написании и заглавных буквах. Ints позволяют передавать из диапазона значений и имеют мало семантики (например , я получаю 3от вашего торгового обслуживания, что же это значит? LastPrice? LastQuantity? Что - то еще?

Передача объектов и использование иерархий классов не всегда возможны; например, wcf не позволяет принимающей стороне различать, какой класс был отправлен.

В моем проекте служба использует иерархию классов для воздействия операций, непосредственно перед передачей через DataContractобъект объект из иерархии классов копируется в unionподобный объект, который содержит enumтип для указания типа. Клиент получает DataContractи создает объект класса в иерархии, используя enumзначение для switchсоздания объекта правильного типа.

Другая причина, по которой не нужно передавать объекты класса, заключается в том, что для службы может потребоваться совершенно другое поведение для переданного объекта (такого как LastPrice), чем для клиента. В этом случае отправка класса и его методов нежелательна.

Являются ли заявления о переключении плохими?

ИМХО, единственное switch утверждение, которое вызывает различные конструкторы в зависимости от, enumне является запахом кода. Это не обязательно лучше или хуже, чем другие методы, такие как рефлексия на имя типа; это зависит от реальной ситуации.

Включение enumповсюду - это запах кода, oop предлагает альтернативы, которые зачастую лучше:

• Использовать объекты разных классов иерархии, которые имеют переопределенные методы; т.е. полиморфизм.
• Используйте шаблон посетителя, когда классы в иерархии редко изменяются и когда (многие) операции должны быть слабо связаны с классами в иерархии.

Что делать, если вы пошли с более сложным типом:

    abstract class TickType
    {
      public abstract string Name {get;}
      public abstract double TickValue {get;}
    }

    class BuyPrice : TickType
    {
      public override string Name { get { return "Buy Price"; } }
      public override double TickValue { get { return 2.35d; } }
    }

    class BuyQuantity : TickType
    {
      public override string Name { get { return "Buy Quantity"; } }
      public override double TickValue { get { return 4.55d; } }
    }
//etcetera

тогда вы можете загрузить свои типы из рефлексии или построить его самостоятельно, но главное, что вы здесь делаете, это то, что вы придерживаетесь принципа Открытого Закрытия SOLID

TL; DR

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

Прошу прощения, как я рефакторинг тонн моего старого кода. / вздох; ^ D

Но почему?

Довольно хороший обзор, почему это так от LosTechies здесь :

// calculate the service fee
public double CalculateServiceFeeUsingEnum(Account acct)
{
    double totalFee = 0;
    foreach (var service in acct.ServiceEnums) { 

        switch (service)
        {
            case ServiceTypeEnum.ServiceA:
                totalFee += acct.NumOfUsers * 5;
                break;
            case ServiceTypeEnum.ServiceB:
                totalFee += 10;
                break;
        }
    }
    return totalFee;
} 

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

Небольшое отступление: перечисления - очень ограниченная структура данных. Если вы не используете enum для обозначения целого числа, обозначенного как целое число, вам нужен класс для правильного моделирования абстракции. Вы можете использовать удивительный класс Enumeration Джимми, чтобы использовать классы и использовать их в качестве меток.

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

public interface ICalculateServiceFee
{
    double CalculateServiceFee(Account acct);
}

...

Теперь мы можем создать наши конкретные реализации интерфейса и прикрепить их [к] учетной записи.

public class Account{
    public int NumOfUsers{get;set;}
    public ICalculateServiceFee[] Services { get; set; }
} 

public class ServiceA : ICalculateServiceFee
{
    double feePerUser = 5; 

    public double CalculateServiceFee(Account acct)
    {
        return acct.NumOfUsers * feePerUser;
    }
} 

public class ServiceB : ICalculateServiceFee
{
    double serviceFee = 10;
    public double CalculateServiceFee(Account acct)
    {
        return serviceFee;
    }
} 

Еще один случай реализации ...

Суть в том, что если у вас есть поведение, которое зависит от значений перечисления, почему бы вместо этого не иметь различные реализации аналогичного интерфейса или родительского класса, который гарантирует, что значение существует? В моем случае я смотрю различные сообщения об ошибках, основанные на кодах состояния REST. Вместо того...

private static string _getErrorCKey(int statusCode)
{
    string ret;

    switch (statusCode)
    {
        case StatusCodes.Status403Forbidden:
            ret = "BRANCH_UNAUTHORIZED";
            break;

        case StatusCodes.Status422UnprocessableEntity:
            ret = "BRANCH_NOT_FOUND";
            break;

        default:
            ret = "BRANCH_GENERIC_ERROR";
            break;
    }

    return ret;
}

... возможно, я должен обернуть коды статуса в классах.

public interface IAmStatusResult
{
    int StatusResult { get; }    // Pretend an int's okay for now.
    string ErrorKey { get; }
}

Затем каждый раз, когда мне нужен новый тип IAmStatusResult, я его кодирую ...

public class UnauthorizedBranchStatusResult : IAmStatusResult
{
    public int StatusResult => 403;
    public string ErrorKey => "BRANCH_UNAUTHORIZED";
}

... и теперь я могу убедиться, что более ранний код понимает, что он имеет IAmStatusResultобласть действия, и ссылаться на него, entity.ErrorKeyа не на более замысловатый deadend_getErrorCode(403) .

И, что более важно, каждый раз , когда я добавляю новый тип возвращаемого значения, не нужно добавлять никакого другого кода для его обработки . Хоть знаешь, то enumи switchбыли кодовые запахи.

Прибыль.

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

• Организовать код в соответствии с операциями. В этом случае вы можете использовать перечисление для тегирования разных типов и иметь оператор switch в каждой процедуре, которая использует тегированные данные.
• Организовать код в соответствии с типами данных. В этом случае вы можете заменить перечисление интерфейсом и использовать класс для каждого элемента перечисления. Затем вы реализуете каждую операцию как метод в каждом классе.

Какое решение лучше?

Если, как указал Карл Билефельдт, ваши типы фиксированы, и вы ожидаете, что система будет расти в основном за счет добавления новых операций к этим типам, тогда лучше использовать enum и оператор switch: каждый раз, когда вам нужна новая операция, вы просто реализуйте новую процедуру, тогда как при использовании классов вам придется добавить метод к каждому классу.

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

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

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

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

Итог: перечисления не обязательно являются запахом кода.