Проверка параметров в цепочке услуг

У нас есть цепочка обслуживания A -> B -> C -> D. A определяет формат некоторых параметров, например ParamA B определяет формат определенных параметров, например ParamB

D - это тот, который фактически использует эти параметры, а C передает их в D. Роль C состоит в том, чтобы получить данные из D и сделать бит бизнес-логики поверх этого и вернуть, что B и B вернутся к A .

Хорошо ли, что C проверяет параметры ParamA и ParamB или C, не стоит беспокоиться о параметрах и пусть D принимает решение, потому что если изменения формата (один тип проверки) смены C необходимо обновить. Каковы ваши предложения?

3 голоса | спросил Adams 20 +03002017-10-20T06:44:02+03:00312017bEurope/MoscowFri, 20 Oct 2017 06:44:02 +0300 2017, 06:44:02

2 ответа


3

Решающий вопрос, который вы должны задать себе: . На каких параметрах на практике приходят?

Если вы знаете, что все эти методы в конечном счете предназначены для более четкого понимания для сопровождающего, а B, C и D вызываются только из A, тогда нет смысла проверять параметры в нескольких местах. Очевидным местом для этого является A, как только после получения их возможно.

Но, конечно, разработка программного обеспечения процветает при повторном использовании, поэтому, если B, C или D должны были повторно использоваться один день, чтобы другие части системы вызывали их напрямую, это больше не выполняется. Вот почему четкое документирование того, что пред- и пост-условия для ваших методов, так важно.

ответил Kilian Foth 23 +03002017-10-23T11:14:03+03:00312017bEurope/MoscowMon, 23 Oct 2017 11:14:03 +0300 2017, 11:14:03
0

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

  • Проверять только параметры общедоступных методов в публичных классах

Исключения из этого правила:

(первые три идут, если вы хотите быть более защищенными от достоверности аргументов)

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

Применительно к вашему примеру, я бы сказал, что ответственность за каждую проверку параметров будет только в одном месте. Позвольте мне уточнить. Проверка работоспособности параметров может быть выполнена на стороне источника. Предположим, что ParamA должен быть положительным числом. A легко проверить, кто-то положил 0 или -5 в качестве значения в ParamA. Тем не менее, семантическая проверка обычно может выполняться только на стороне назначения, которая в этом случае означает D.

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

В любом случае я не вижу причин, по которым C должен проверять достоверность аргументов, переданных D. C, очевидно, является просто прокси здесь, и единственное, что C должно проверить, - это данные, которые он получает от D, чтобы выполнить независимо от того, что он делает.

ответил Vladimir Stokic 23 +03002017-10-23T13:49:27+03:00312017bEurope/MoscowMon, 23 Oct 2017 13:49:27 +0300 2017, 13:49:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132