Я смущен в отношении того, является ли вызывающий или ответственным лицом ответственность за соблюдение законности данных.
Если контрольная группа проверяет, должны ли аргументы pass-in не быть null и соответствовать некоторым другим требованиям, чтобы метод вызываемого пользователя мог нормально и успешно выполняться и улавливать любые потенциальные исключения? Или это обязанность звонящего сделать это?
Проверка на стороне покупателя (клиент) и поставщика (API).
Клиенты должны это делать, потому что это означает лучший опыт. Например, почему сеть в оба конца, чтобы сказать, что у вас есть одно плохое текстовое поле?
Поставщики должны это делать, потому что они никогда не должны доверять клиентам (например, XSS и человек в средних атаках). Как вы знаете, что запрос не был перехвачен? Подтвердите все.
Существует несколько уровней valid:
Только сторона провайдера может выполнять # 2 и # 3.
Для API вызывающий должен всегда выполнять правильную проверку и выдавать описательное исключение для недопустимых данных.
Для любого клиента с накладным клиентом IO также необходимо выполнить базовую проверку...
Проверка: Caller vs. Called
Версия TL;DR - это оба.
В длинной версии подразумевается, кто, почему, когда, как и что.
И
Оба должны быть готовы ответить на вопрос "могут ли эти данные работать надежно?" Известно ли нам об этих данных, чтобы сделать что-то значимое? Многие полагают, что надежность данных никогда не должна быть надежной, но это только приводит к проблеме с курицей и яйцом. Преследование его бесконечно с обоих концов не обеспечит значимой ценности, но в какой-то степени это важно.
Оба должны проверять форму данных для обеспечения удобства использования базы. Если какой-либо из них не распознает или не понимает форму данных, нет способа узнать, как дальше обращаться с ним с любой надежностью. В зависимости от среды данные могут нуждаться в определенном "типе", что часто является простым способом проверки формы. Мы часто рассматриваем типы, которые представляют доказательства общего линеала назад определенному предку, и сохраняют важные черты, чтобы обладать правильной формой. Другие характеристики могут быть важны, если данные - это нечто иное, чем структура памяти, например, если это поток или какой-либо другой ресурс, внешний контекст.
Многие языки включают проверку формы данных как встроенную функцию языка посредством проверки типа или интерфейса. Однако, когда предпочтение композиции над наследованием, предоставление хорошего механизма для проверки существования признаков лежит на исполнителе. Одна из стратегий достижения этого - динамическое программирование или, в частности, путем интроспекции, вывода или отражения типа.
Вызывается
Вызываемый должен проверить домен (набор входов) данного контекста, к которому он будет работать. Дизайн вызываемого всегда предполагает, что он может обрабатывать только так много случаев ввода. Обычно эти значения разбиваются на определенные подклассы или категории ввода. Мы проверяем домен в вызываемом, потому что вызов является интимным с локализованными ограничениями. Он лучше всех знает, что является хорошим вкладом, а что нет.
Нормальные значения: эти значения карты домена относятся к диапазону. Для каждого foo существует один и только один bar.
Вне диапазона/вне значений области: эти значения являются частью общего домена, но не будут отображаться в диапазоне в контексте вызываемого. Для этих значений не существует определенного поведения, и поэтому допустимый выход невозможен. Часто проверка вне диапазона включает диапазоны, ограничения или допустимые символы (или цифры или составные значения). Проверка мощности (множественность), а затем проверка наличия (нуль или пусто), являются специальными формами проверки диапазона.
Значения, которые приводят к поведению Illogical или undefined: эти значения являются специальными значениями или крайними случаями, которые в противном случае являются нормальными, но из-за конструкции алгоритма и известных ограничений среды могут привести к неожиданным результатам. Например, функция, которая работает с числами, должна защищать от деления на ноль или аккумуляторов, которые будут переполняться, или непреднамеренной потери точности. Иногда операционная среда или компилятор может предупредить, что эти ситуации могут произойти, но полагаться на среду выполнения или компилятор не является хорошей практикой, поскольку она не всегда может вывести то, что возможно, а что нет. Этот этап должен быть в значительной степени проверен с помощью вторичной проверки, что вызывающий обеспечивал хороший, полезный, значимый ввод.
Caller
Вызывающий является специальным. У вызывающего есть две ситуации, в которых он должен проверять данные.
Первая ситуация заключается в изменении присвоения или явного состояния, когда изменение происходит по меньшей мере с одним элементом данных с помощью какого-либо явного механизма, внутри или снаружи чем-то в его контейнере. Это несколько выходит за рамки вопроса, но что-то нужно иметь в виду. Важно учитывать контекст, когда происходит изменение состояния, и затрагивается один или несколько элементов, описывающих состояние.
Вторая ситуация - когда данные вызывают функцию. Вызывающий может ожидать от вызываемого только так много. Вызывающий должен знать и уважать, что вызываемый признает только определенный домен. Вызывающий также должен быть заинтересован в себе, поскольку он может продолжаться и сохраняться задолго до того, как вызываемые завершатся. Это означает, что вызывающий должен помочь вызываемому быть не только успешным, но и уместным для задачи: плохие данные в результате генерируют плохие данные. В то же время даже хорошие данные в отношении и вызывается в отношении вызываемого не могут соответствовать следующей вещи в терминах вызывающего. Хорошие данные могут фактически быть плохими данными для вызывающего. Вывод вызываемого может аннулировать вызывающего абонента для текущего состояния вызывающего абонента.
Хорошо, достаточно комментариев, что должен проверить конкретный вызывающий?
Логично и нормально: учитывая данные, называется хорошая стратегия, которая соответствует цели и намерению? Если мы знаем, что это сработает с определенными значениями, больше нет смысла выполнять вызов без соответствующих охранников. Если мы знаем, что вызов не может обрабатывать нуль, не спрашивайте его, поскольку он никогда не будет успешным. Что более дорого и сложнее в управлении: [избыточное (мы знаем?)] Предложение охраны или исключение [которое происходит поздно в возможно более длительном, зависящем от внешних ресурсов ресурсе)? Реализации могут меняться и внезапно меняться. Предоставление защиты в вызывающем абоненте снижает влияние и риск при изменении этой реализации.
Возвращаемые значения: проверьте неудачное завершение. Это то, что вызывающий может или не должен делать. Прежде чем использовать или полагаться на возвращаемые данные, проверьте альтернативные результаты, если в конструкции системы учитываются успешные и неудачные значения, которые могут сопровождать фактическое возвращаемое значение.
Сноска: В случае, если это не ясно. Null - проблема домена. Это может быть или не быть логичным и нормальным, так что это зависит. Если нуль является естественным входом функции, и функция может быть разумно ожидаемой для создания значимого вывода, тогда оставьте ее вызывающей стороне использовать ее. Если домен вызывающего абонента таков, что null не является логическим, то защитите его в обоих местах.
Важный вопрос: если вы передаете null вызываемому, а вызывающий что-то производит, разве это не скрытый шаблон создания, создающий что-то из ничего?
Все о "контракте". Это отзыв, который определяет, какие параметры являются точными или нет.
Вы можете добавить в документацию, что параметр "null" недопустим, а затем бросать NullPointerException или InvalidArgumentException в порядке.
Если возвращающий результат для нулевого параметра имеет смысл - укажите его в документации. Узумно такая ситуация - плохой дизайн - создайте переопределенный метод с меньшим количеством параметров вместо принятия значения null.
Помните только о том, как бросать описательные исключения. По правилу:
NullPointerException или InvalidArgumentException)getPermissionsForUser(Integer userId) вызывающий абонент пропускает userId, не зная, существует ли такой пользователь, но это непустой целое число. Ваш метод может вернуть список разрешений или указать a UserNotFoundException. Это может быть проверенное исключение.Ну... это зависит.
Если вы можете быть уверены в том, как обрабатывать недопустимые данные внутри своего собеседника, тогда сделайте это там.
Если вы не уверены (например, потому что ваш метод довольно общий и используется в нескольких разных местах и путях), позвольте вызывающему абоненту решить.
Например, представьте метод DAO, который должен получить определенную сущность, и вы ее не найдете. Можете ли вы решить, нужно ли исключать исключение, возможно, откажитесь от транзакции или просто подумайте об этом? В подобных случаях определенно зависит от того, как вызывающий абонент решает, как с ним справиться.
И. Это вопрос хорошей разработки программного обеспечения с обеих сторон и независимо от среды (C/S, web, внутренний API) и языка.
Вызов должен проверять все параметры в соответствии с хорошо документированным списком параметров (вы его задокументировали, правда?). В зависимости от среды и архитектуры должны быть реализованы хорошие сообщения об ошибках или исключения, чтобы дать четкое представление о том, что не так с параметрами.
Вызывающий должен гарантировать, что в вызове api передаются только соответствующие значения параметров. Любые недопустимые значения должны быть пойманы как можно скорее и каким-то образом отражены для пользователя.
Как часто бывает в жизни, ни одна из сторон не должна просто предполагать, что другой парень пойдет правильно и проигнорирует потенциальную проблему.
Я буду рассматривать другую точку зрения на этот вопрос. Работая внутри прилагаемого приложения, оба вызывающего и вызываемого абонента находятся в одном коде. Тогда любая проверка, требуемая договором вызываемого лица, должна выполняться вызываемым лицом.
Итак, вы написали функцию, и ваш контракт говорит: "Не принимает значения NULL". вы должны проверить, что значения NULL не были отправлены и вызывают ошибку. Это гарантирует, что ваш код верен, и если кто-то еще что-то делает, он не должен знать об этом раньше.
Кроме того, если вы предполагаете, что другой код правильно вызовет ваш метод, а он не будет, , это затруднит отслеживание источника потенциальных ошибок.
Это важно для "Fail Early, Fail Часто" , где идея состоит в том, чтобы поднять условие ошибки, как только обнаружена проблема.
Зависит от того, произвольно ли вы программируете, оборонительно или полностью.
В большинстве случаев вы запрограммировали бы защищенную (отказоустойчивую) или полностью (отказобезопасную). Номинальное программирование является рискованным ИМО и его следует избегать при ожидании ввода от внешнего источника.
Конечно, не забывайте документировать все (особенно при программировании номинально).
Ответственность отвечает за достоверность данных. Это объясняется тем, что только вызываемый знает, что действительно. Также это хорошая практика безопасности.
Он должен быть как на стороне клиента, так и на стороне сервера (вызываемого и вызывающего).
Клиент:
Сервер:
В общем, 1. Если данные поступают из пользовательского интерфейса, всегда лучше проверять уровень пользовательского интерфейса и выполнять двойную проверку на уровне сервера. 2. Если передача данных осуществляется на самом уровне сервера, нам необходимо проверить на вызове и для двойной проверки, мы также должны делать на стороне абонента.
Спасибо
В моем скромном мнении и в еще нескольких словах, объясняющих, почему это чаще всего вызывает ответственность, но это не значит, что вызывающий абонент всегда свободен от стрессов.
Причина в том, что вызываемая женщина находится в лучшем положении, чтобы знать, что ей нужно для выполнения своей работы, потому что она делает работу. Таким образом, это хорошая инкапсуляция для объекта или метода для самооценки. Если вызываемый может не работать с нулевым указателем, это недопустимый аргумент и должен быть отброшен как таковой. Если есть аргументы вне диапазона, это также легко защищать от.
Однако "незнание закона не является защитой". Это не очень хороший образец для звонящего, чтобы просто засунуть все, что он дал, в свою вспомогательную функцию, и позволить вызываемому разобраться в этом. Вызывающий не добавляет никакой ценности, когда он делает это, во-первых, особенно если то, что звонит вызывающий в вызываемый объект, - это данные, которые он сам дал своему собеседнику, что означает, что этот уровень стека вызовов, вероятно, является избыточным. Это также делает код вызывающего и вызываемого кода очень сложным, так как обе стороны "защищают" от нежелательного поведения другим (вызывающая сторона пытается спасти что-то работоспособное и все тестирует, а вызывающий агент завершает вызов в заявлениях о попытках, которые пытаются исправьте вызов).
Поэтому вызывающий должен проверить, что он может знать о требованиях к переданным данным. Это особенно актуально, когда есть время, связанное с выполнением вызова, например при вызове служебного прокси. Если вам нужно подождать значительную часть секунды, чтобы узнать, что ваши параметры ошибочны, когда потребуется сделать несколько тиков, чтобы сделать одну и ту же клиентскую сторону, преимущество очевидно. Оговорки охранника - это именно то, что; последняя линия защиты и изящная неудача, прежде чем что-то уродливое будет выброшено из реальной рабочей процедуры.
Между абонентом и вызываемым абонентом должно быть что-то, что называется контрактом. Вызов гарантирует, что он поступает правильно, если входные данные указаны в заданных значениях. Он по-прежнему должен проверить, соответствуют ли входящие данные в соответствии с этими спецификациями. В Java вы можете нажать InvalidArgumentException.
Вызывающий должен также работать в соответствии с условиями контракта. Если он проверяет данные, которые он передает, это зависит от случая. В идеале вы должны запрограммировать вызывающего абонента таким образом, чтобы проверка была необработанной, поскольку вы уверены в правильности ваших данных. Если это, например, пользовательский ввод не может быть уверен, что он действителен. В этом случае вы должны это проверить. Если вы не проверяете это, вы, по крайней мере, должны обрабатывать исключения и соответственно реагировать.
Ответчик обязан проверить, что данные, которые он получает, действительны. Неспособность выполнить эту задачу почти наверняка приведет к ненадежному программному обеспечению и предоставит вам потенциальные проблемы безопасности.
Сказав, что если у вас есть контроль над кодом клиента (вызывающего), вы также должны выполнить хотя бы некоторую проверку там, так как это приведет к лучшему опыту.
Как правило, старайтесь как можно раньше уловить проблемы с данными, это приводит к гораздо меньшему количеству проблем в дальнейшем.