Явное поведение с проверками против неявного поведения

Question

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

Мы работаем над клиентом.серверное приложение с winforms.И у нас есть элемент управления, который автоматически вычисляет некоторые поля при заполнении другого поля.Таким образом, у нас есть поле валюты, которое при заполнении пользователем будет определять автоматическое заполнение другого поля, может быть, больше полей

Когда пользователь заполняет поле валюты, объект Валюта будет извлекаться из кэша на основе строки, введенной пользователем.Если введенная валюта не найдена в кэше, объект кэша возвращает нулевую ссылку.Далее при запросе прикладного уровня вычислить другие поля на основе валюты, учитывая нулевую валюту, будет возвращено определенное нулевое поле.Таким образом, неявное поведение по умолчанию - очистить все поля.Что является ожидаемым поведением.Просто чтобы было более понятно, когда пользователь вводит «недоступную валюту», он, конечно, получает уведомление, но также следует очистить поля, которые зависят от введенной валюты.Это делается путем установки определенных значений элемента управления равными нулю.

То, что я бы назвал явной реализацией, состояло бы в том, чтобы проверить, что объект Currency является нулевым, и в этом случае зависимые поля очищаются явно.* Я думаю, что последняя версия более понятна, менее подвержена ошибкам и более тестируема.Но это подразумевает форму избыточности.Предыдущая версия не так ясна и подразумевает определенное поведение на уровне приложений, которое не выражено в тестах.Может быть, в тестах нижнего уровня, но когда возникает необходимость изменить нижние уровни, чтобы при нулевой валюте было возвращено что-то еще, я не думаю, что тест, который говорит просто, что без мотивации будет препятствием длявведение ошибки в верхних слоях.

Что вы, ребята, думаете?

Answer 1

Явное лучше, чем неявное.- Дзен Питона, Тим Питерсне очевидно с первого взгляда).

Answer 2

Во-первых, Дину Флорин прав, явное обычно лучше, чем неявное (но один размер не подходит всем, поэтому есть исключения).

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

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

Answer 3

Насколько я понимаю ваш вопрос, вы сравниваете, следует ли полагаться на NullReferenceException или нулевой объект для определения следующего действия.

Вот мои мысли:

1. если вы хотите положиться на исключение, поместите его в исключение вашего собственного приложения, например в CurrencyNotFoundException. Абоненты должны будут проверить это исключение и вести себя соответственно. Таким образом, гораздо яснее, что происходит под капотом.
2. если вы ожидаете, что ситуация, когда валюта не будет найдена в кеше, встречается часто, вы можете избегать исключений (это не «ИСКЛЮЧЕНИЕ» из обычного случая). Вы можете выбрать нулевой шаблон объекта. С шаблоном вы возвращаете объект NullCurrency обратно. Вызывающая сторона может иметь подходящие стратегии отображения, и одной из них будет NullCurrencyDisplayStrategy. Таким образом, вам никогда не придется полагаться на нулевую проверку. Возвращенный объект является допустимым объектом в его бизнес-домене.

Надеюсь, это поможет