Командные сообщения - вопрос разработки классификации

Question

Я пытаюсь спроектировать один сервис, используя источник событий. Один из вариантов использования - когда приходит команда, я должен выполнить некоторую логику и преобразовать объект из одного РЕЖИМА в другой. Теперь «проблема», с которой я сталкиваюсь, заключается в выборе между этими двумя вариантами командных сообщений:

Опция 1: (поместите режим непосредственно в имя командного сообщения)

SetToManualModeCommand{
  int val = 22;
}
SetToAutoModeCommand{
  int val = 22;
}
SetToSemiAutoModeCommand{
  int val = 22;
}
SetTo...ModeCommand{
  int val = 22;
}

Вариант 2: (поместите режим в виде enum внутри единственного командного сообщения)

enum Mode{
  AUTO, 
  SEMI_AUTO, 
  MANUAL;
}

SetToModeCommand{
  Mode mode;
  int val = 22;
}

• режимы меняются не так часто - но они могут меняться. Если они меняются - в варианте 1 я должен сделать новый класс. В варианте 2 мне нужно добавить одно дополнительное значение перечисления.

Видите ли вы какие-либо недостатки / преимущества любого из этих двух вариантов или они более менее одинаковы?

Answer 1

Из контекста, который вы дали, я не вижу убедительного аргумента в любом случае. Я знаю, что вы говорите о командах, а не о событиях, но попробуйте подумать об этом с точки зрения подписчиков событий. Значительным событием является то, что режим каким-то образом изменился или изменился на определенное значение? Другими словами, хотят ли подписчики одного события ModeChanged с подробностями внутри события, или некоторые подписчики хотят только ModeChangedToManual, а другие просто хотят ModeChangedToAuto и т. Д. Вы можете рассмотреть систему хранения событий, которую вы используете, и насколько легко ее создать. фильтрованная подписка.

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

Answer 2

Мой общий подход - не включать классификацию как структуру. Классификация в качестве данных кажется более простой.

Еще один пример, похожий на ваш, - это различные типы клиентов: GoldCustomer, SilverCustomer или BronzeCustomer. Некоторое время спустя (2-3 года) предприятие может решить добавить PlatinumCustomer.

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

С этой целью я хотел бы, чтобы некоторая концепция предметной области представляла режим более общим / изменчивым образом, но YMMV.

Answer 3

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

Если используется код для каждогорежим находится в разных местах - тогда для каждого места легко подписаться на правильный режим - создайте разные события для каждого режима.

Answer 4

Как общий принцип - сделайте неявное явным. Поэтому составьте команду для каждого «режима». Но я, честно говоря, не думаю, что в этом есть что-то особенное.

Ясно, что то, что вы на самом деле делаете, очень зависит от контекста системы, которую вы строите. Как часто появляются новые режимы?

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