Это помогает избежать изменения этих предположительно постоянных значений только потому, что кто-то переставляет класс. Скажем, у вас есть новый сотрудник, который решает, что «Нет» должен идти в конце списка:
public enum EmployeeRole
{
Manager,
Admin,
Operator,
None
}
Ну, если бы вы только когда-либо обращались к этим значениям непосредственно из EmployeeRole. Как бы то ни было, это не так уж сложно. Но большинство перечислений, которые я видел, в какой-то момент преобразуются в целочисленные значения, когда они сохраняются в базе данных. Это означает, что все ваши «None» элементы в хранилище были просто преобразованы в «Manager».
Та же проблема возникнет, если кто-то просто вставит новую EmployeeRole между, скажем, Admin и Operator.
Другое преимущество возникает, когда вы не считаете подходящим значением по умолчанию для вашего перечисления. Например, если кто-то забыл сопоставить поле EmployeeRole в ORM, объекты, извлеченные из хранилища, всегда будут иметь роль None
(0 всегда является значением по умолчанию для перечислений). В зависимости от того, как ваше программное обеспечение обрабатывает None
, этот тип ошибки может оставаться не исправленным в течение некоторого времени. Но если вы сделаете это:
public enum EmployeeRole
{
Manager = 1,
Admin = 2,
Operator = 3
}
... и затем, комбинируя это с отказоустойчивыми методами, вы можете быстро отлавливать ошибки, если было предоставлено недопустимое значение "0":
public RightsManager GetByEmployeeRole(EmployeeRole role)
{
Require.That(role.IsDefined()); // throws an exception if role is not defined.
// find the rights manager for this role.
}