Блог

Как вы думаете, хорошая ли это идея-иметь такое перечисление:

 enum AvailableSpace {
   Percent10,
   Percent20,
   SqF500,
   SqF600
}
 

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

ИЗМЕНИТЬ: Это будет использоваться для определения состояния объекта, т. Е. как свойство только для чтения, описывающее состояние объекта. Если мы знаем общее пространство (т. Е. Сам объект знает его), у нас есть возможность преобразовать его внутренне, поэтому у нас есть либо только процент, либо квадратные футы, либо и то, и другое. Аргумент в том, что «и то, и другое» — не очень хорошая идея.

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

Вопрос только в семантике имен значений, а не в содержании — т. Е. Стоит ли указывать процент в (потенциальном) перечислении int.

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

Причина: Какова связь между значениями перечисления из двух шкал, таких как Percent10 и SqF600? Как вы расширяете список значений, которые вы можете представлять в своем коде? Как вы проводите сравнение и арифметические операции с этими значениями?

Предложение (не спрашивалось, но, тем не менее, вот оно. :-)): Семантика того, что вы пытаетесь сделать, будет лучше отражена структурой, содержащей два поля — одно для абсолютной области и одно для процента, доступного для этой абсолютной области. С такой структурой вы можете представлять все, что вы можете представлять с помощью перечислений выше. Например, поставщики данных, которые предоставляют вам абсолютную площадь, представлены структурой с площадью и 100% доступностью. Поставщики данных, которые предоставляют вам процент, представлены структурой с заданным ими процентом и абсолютной областью, так что процент этой области является фактической доступной областью, о которой поставщик данных хочет сообщить. Вы получаете «нормализованное» представление данных от поставщиков обоих типов, и вы можете добавить пару операторов для сравнения и арифметических вычислений с экземплярами.

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

Если контекст позволяет это, может быть еще лучше создать два типа оболочки «Процент» и «Квадратные метры», а затем создать некоторые перегрузки операторов, чтобы вы могли выполнять такие действия, как «новые квадратные метры(500) новые проценты(20)»; и исключить использование перечислений.

Обновление: Ваша схема именования была бы уместной, если бы значения были признанными отраслевыми терминами, почти до такой степени, чтобы быть символами. Например, безопасно иметь перечисление, содержащее такие значения, как «ISO9001», а не два значения (перечисление, содержащее «ISO» и int 9001). Также было бы уместно иметь перечисление, как показано ниже:

 public enum OperatingSystem
{
    Windows95,
    Windows98,
    Windows2000,
    WindowsXP,
    WindowsVista,
    MacOSClassic,
    MacOSXTiger,
    MacOSXLeopard
}
 

Если термины «Процент 10» и «Sqf500» не являются художественными терминами или четко определены в спецификации, словаре данных и т. Д., То нецелесообразно использовать их в качестве значений в перечислении.