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

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

[Flags()]
public enum LightColors
{
    unknown = 0,
    red = 1,
    yellow = 2,
    green = 4,
    green_arrow = 8
}

Текущее состояние света может быть установлено как:

LightColors c = LightColors.red | LightColors.green_arrow;

И запрошен как:

if ((c & LightColors.red) == LightColors.red)
{
    //Don't drive
}
else if ((c & LightColors.green_arrow) == LightColors.green_arrow)
{
    //Turn
}

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

Однако статические члены класса прекрасно подходят для часто используемых объектов. Члены System.Drawing.Color являются отличными примерами, поскольку они представляют цвета с известными именами, которые имеют неясные конструкторы (если только вы не знаете свои шестнадцатеричные цвета). Если бы они были реализованы как перечисления, вам пришлось бы делать что-то подобное каждый раз, когда вы хотите использовать значение в качестве цвета:

colors c = colors.red;
switch (c)
{
    case colors.red:
        return System.Drawing.Color.FromArgb(255, 0, 0);
        break;
    case colors.green:
        return System.Drawing.Color.FromArgb(0,255,0);
        break;
}

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

Редактировать: @stakx, я думаю, вы тоже наткнулись на что-то важное, в ответ на сообщение @Anton, и это сложность или, что более важно, для кого это сложно?

С точки зрения потребителя я бы предпочел статические члены класса System.Drawing.Color, а не необходимость писать все это. Однако с точки зрения продюсера писать все это было бы мучением. Поэтому, если другие люди будут использовать ваш код, вы можете избавить их от многих проблем, используя статические члены класса, даже если вам потребуется в 10 раз больше времени для написания/тестирования/отладки. Однако, если это только вы, вам может быть проще просто использовать перечисления и приводить/преобразовывать по мере необходимости.

Я действительно боролся с чем-то подобным на работе.

Он был основан на примере, который был опубликован Джон Б в статье блога Джона Скита "Расширенные перечисления в C#"< /а>.

Кое что нашел за это время, если кому интересно:

• Блоки switch не будут работать с перечислением-как-классом.

• Пользователь empi упомянул сходство приведенного выше примера перечисления как класса с перечислениями Java. Похоже, что в мире Java существует общепризнанный шаблон под названием Typesafe Enum; очевидно, этот шаблон восходит к книге Джошуа Блоха Effective Java.

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

public enum Legacy : ushort
{
  SomeFlag1 = 0x0001,
  SomeFlag2 = 0x0002,
  // etc...
}

Тогда сортировка в P/Invoke менее удобочитаема из-за приведения, необходимого для преобразования перечисления в соответствующее значение.

Если бы это была константная переменная класса, приведение не требовалось бы.

Оба подхода действительны. Вы должны выбрать в каждом конкретном случае.

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

Существует очень похожий рефакторинг под названием «Замена перечислений шаблоном стратегии». Ну, в вашем случае это не совсем полно, так как ваш Цвет пассивен и не действует как стратегия. Однако почему бы не рассматривать это как частный случай?

Да, оригинальное издание «Effective Java» Джошуа Блоха, которое было выпущено до Java 1.5 и встроенной поддержки перечислений в Java, продемонстрировало шаблон Typesafe Enum. К сожалению, последний выпуск книги ориентирован на Java > 1.5, поэтому вместо него используются перечисления Java.

Во-вторых, вы не можете преобразовать int в enum в Java.

Color nonsenseColor = (Color)17; // compile-error

Хотя я не могу говорить за другие языки.