Одна команда для каждого государства или одна команда для управления ими всеми - PullRequest
Новая
       5

Одна команда для каждого государства или одна команда для управления ими всеми

1 голос
/ 28 января 2012

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

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

  • работа была выполнена (StartDate, EndDate)
  • работа не была выполнена полностью по нашей вине (Комментарий)
  • работа не была выполнена, но это вина владельца (ReasonId)

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

Но есть еще один уровень сложности, потому что есть три основных вида очистки, которые может выполнять предприятие, и каждый из них может иметь разные вещи, которые можно добавить к этим командам (например, количество мест для очистки или площадь и описание).

Только с этим у меня уже 9 дел. Я чувствую, что разъединение всего этого - правильный путь, потому что это обеспечивает большую гибкость в будущем.

Но правильно ли я считаю, что эти три вещи разные, если они не будут одной большой командой, такой как:

  • Я расскажу вам, что мы сделали (StateOfWork, StartDate, EndDate, Comment, ReasonId, NbSeat, AreaQuantity, AreaDescription ...)

Мне совершенно не нравится мысль о том, что объект наполовину полон, потому что он охватывает слишком много вещей ..

Спасибо за ваше чтение и ваши мысли,

1 Ответ

5 голосов
/ 28 января 2012

Вы выдвинули хороший аргумент в пользу развязанного подхода - хороший принцип для использования разделения интересов.

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

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

Наличие метода с (впо крайней мере) 8 параметров - это запах кода - он говорит мне, что метод делает слишком много и в итоге будет очень сложным и сложным в обслуживании.

...