Где я должен проверить тип переменной с PHP 7?
С появлением версии 7 PHP представил скалярные типы, обнуляемые скалярные типы и возвращаемые типы. Их использование сразу же полезно (самодокументируемый код, фатальные ошибки во время выполнения, список можно продолжить), но я не уверен, с какого момента в моем коде я должен начать их использовать. Я чувствую, что ответ должен быть «как можно скорее».
До PHP 7 большая часть моего кода была похожа на пример класса. Мой контроллер инициализирует класс и передает ему переменные POST. Затем я сделал бы проверку типов переменных внутри класса, чтобы убедиться, что все переменные верны.
class User {
public function createUser($username, $password, $some_float)
{
// Check types, validate vars and create user
}
}
С PHP 7 я могу сделать это
class User {
public function createUser(string $username, string $password, float $some_float)
{
// Validate vars and create user
}
}
Если бы я пошел со вторым примером, это означало бы перемещение большей части кода проверки типов из класса User в вызывающий его контроллер. Мне не очень нравится идея раздуть мои контроллеры с помощью проверки типов.
Решение
Я полагаю, что любой ответ на этот вопрос будет определен в определенной степени, и мы окажемся в серой зоне, если он действительно подходит для stackoverlow. Тем не менее я постараюсь ответить максимально объективно.
Согласно моему опыту, прочность имеет более высокий приоритет по сравнению с любыми другими соображениями, такими как производительность во время выполнения или ремонтопригодность, которые выиграли бы от лучшей документации для разработчиков.
Исходя из этого, сохраняйте проверку входных данных (проверка типов — это только один вид проверки входных данных. Также существуют проверки диапазона и т. Д.) Как можно ближе к месту, где фактически используются входные данные. В вашем случае это кажется моделями для приложения Model-Controller-View. Насколько я понимаю, ваш пример кода, пользовательский класс, будет моделью.
Обоснование: Код будет развиваться со временем, и риск того, что вы или еще хуже ваши коллеги внесут изменения в одном месте и забудет о втором месте, возрастет. Другими словами, если изменения необходимы, этот риск меньше, если связанные части кода близки друг к другу.
дополнительный более ранние проверки, например на уровне HTML5 использование javascript или на уровне контроллера имеет свои преимущества, они могут быть даже необходимы, но они «далеки» от кода, где действительно используются входные данные, поэтому я бы не стал отказываться от проверок на более низком уровне. В идеале, реализовать все эти проверки. Если вам не хватает времени, сначала пожертвуйте проверки уровня HTML5, затем любые проверки javascript, а затем проверки уровня контроллера. Но отбрасывать проверки уровня модели не стоит. Другими словами, начните осуществлять проверки на уровне модели, а затем внедрите проверки более высокого уровня.
Это подходит к вашему последнему предложению:
Мне не очень нравится идея раздувать мои контроллеры с типом
проверка.
Это также подразумевает, что контроллеры являются хорошим местом для большей части обработки ошибок.
Примечание: то же самое касается проверки входных данных в базе данных. Это ваша «последняя линия обороны». В случае утечки плохих данных корректирующие действия будут очень дорогими. Поэтому добавьте как можно больше входных данных в структуру базы данных. В худшем случае эти ограничения могут быть смягчены позже, и ваша база данных останется чистой.
Другие решения
Других решений пока нет …