Практически часто легче всего понять и понять. В связи с этим я рекомендую четко указать, какие состояния могут привести к каким другим состояниям. enum
- это просто список возможных значений. Использование int
значений enum
может показаться более кратким, но его сложнее читать и может привести к другим проблемам.
Во-первых, вот enum
и простой класс, который переключается из одного состояния в другое, если это изменение разрешено. (Я не охватил все штаты.)
enum RequestState
{
Requested,
InProgress,
Declined,
Finished
}
public class Request
{
private RequestState _state = RequestState.Requested;
public void BeginWork()
{
if (_state == RequestState.Declined || _state == RequestState.Finished)
throw new InvalidOperationException("You can only begin work on a new request.");
_state = RequestState.InProgress;
}
public void Decline()
{
if (_state == RequestState.Finished)
throw new InvalidOperationException("Too late - it's finished!");
_state = RequestState.Declined;
}
// etc.
}
Если мы основываем его на числовом значении _state
и определяем, что число может только увеличиваться, некоторые вещи могут пойти не так:
- Кто-то может изменить порядок перечислений или добавить новый, не зная, что числовое значение или позиция имеет логическое значение. Это простая ошибка, потому что это значение обычно не имеет значения.
- Возможно, вам потребуется реализовать логику, которая не так проста. Возможно, вам понадобится состояние, которому могут предшествовать некоторые значения перед ним, но не все из них.
- Вы можете понять, что есть веская причина для того, чтобы идти в обратном направлении. Что если запрос будет отклонен, и в будущем вы определите, что хотите снова открыть запросы, фактически отправив их обратно на
Requested
?
Если способ реализации этого начинается немного странно, эти изменения могут усложнить его изменение и следование. Но если вы просто четко опишите, какие изменения возможны при любом состоянии, тогда его будет легко прочитать и изменить.