Обеспечение входа частных / защищенные методы?
обычно, все нормальные разработчики пытаются защитить вход всех открытых методов (бросающий к надлежащим типам, проверке, санируя и т.д.)
Мой вопрос: Вы находитесь в своем коде, проверяющем также параметры, переданные защищенному / закрытые методы? По-моему, это не необходимо, если Вы securize правильно параметры открытых методов и возвращаемых значений снаружи (другие классы, дб, ввод данных пользователем и т.д....).
Но я постоянно сталкиваюсь с платформами и приложениями (т.е. prestashop для именования одного), где проверка часто повторяется в вызове метода, в теле метода и еще раз для securize возвратил значение - который, я думаю, создает производительность наверху и также знак плохого дизайна.
5 ответов
Если вы придерживаетесь мнения, что общедоступные API-интерфейсы должны иметь реализации, защищающие себя от неверных параметров, вашим критерием должна быть не видимость методов, а то, собирается ли пользователь API напрямую вызывать этот метод (или косвенно вызовите его через другой, который откладывает проверку).
Примеры методов, которые должны выполнять проверку:
class A {
protected final function myMethodDefaultImplementation(...) {
/* subclasses can just call this method in their myMethod implementations */
/* should do validation */
...
}
protected abstract myMethod(...);
public function orderByDate() {
return $this->orderBy(ORDER_BY_DATE)
}
private function orderBy($crit) {
/* should do validation */
...
}
}
Для защищенного, я думаю, вы должны проверить их, так как метод может быть переопределен или вызван из другого класса позже, и вы не можете предполагать допустимые входные данные для метода.Это особенно верно, если это компонент, который будет использоваться другими приложениями.
Что касается private, я думаю, что это пустая трата времени, потому что вы контролируете то, что передается методам, поэтому данные должны быть проверены, прежде чем вы когда-либо вызовете закрытый метод.
Точно - если вы хорошо проектируют свое приложение, то в этом не должно быть необходимости.
Дезинфицируйте ввод только при последней возможности. Я не понимаю, как семантика объектно-ориентированного программирования делает это иначе.
Например, если по какой-то причине вы не можете использовать параметризованные запросы или ORM (единственный пример, который я могу вспомнить в данный момент :), вы бы написали функцию следующим образом:
function getname($id) {
$id = intval($id);
mysql_query("SELECT * FROM users WHERE id = $id");
...
}
Теперь никакой код не может вызвать эту функцию и вызвать неожиданные результаты.
Я бы сказал, что не имеет значения, какой это метод (общедоступный, частный, защищенный), вы всегда принимаете надлежащие меры предосторожности, не обращая внимания на ключевое слово видимости.