Comments 20
interface MyType {}
class MyClass implements MyType {
}
class NotMyClass {}
function do_something(MyType $class){
}
do_something(new MyClass());
class MyClass implements MyType {
}
class NotMyClass {}
function do_something(MyType $class){
}
do_something(new MyClass());
Да, классное решение. Но не для простых типов.
Все таки использование switch в функции type, которая по сути для каждого типа выполняет свои действия — немножко неукладывается в объектно ориентированную парадигму. Посмотрите как сделаны валидаторы в ZF.
По-моему, для подобных утилитных классов лучше все-таки обойтись свитчем, а не создавать иерархию классов.
Если мы имели дело с какой-то концептуальной моделью, которая с высокой вероятностью будет меняться в процессе разработки, то да. А тут просто заранее известный набор типов.
Если мы имели дело с какой-то концептуальной моделью, которая с высокой вероятностью будет меняться в процессе разработки, то да. А тут просто заранее известный набор типов.
И через некоторое время понять, что функция type выросла на 120 строчек и в нее добавился еще с десяток типов. Сегодня проверяем email-ы и title, завтра нам придется проверять еще даты и некоторые данные довольно сложными регулярками. И захочется иметь этот функционал в каком-то одном месте, а не раскиданом по всему проекту.
try {
…
} catch (Exception $e) {
throw new Exception($e->getMessage());
return false;
}
Что то я не понял )
…
} catch (Exception $e) {
throw new Exception($e->getMessage());
return false;
}
Что то я не понял )
Насколько я понимаю, здесь мы ловим исключение, сгенерированное одним из валидаторов (которые не знают логического смысла проверяемого значения) и генерируем исключение с уже более информативным сообщением. Это просто упрощённый пример.
имхо, бред, мы ловим исключение, создаем точно такое же с таким же сообщением и опять его выбрасываем, зачем его тогда ловить? ну или хотя бы, выбрасывать так throw $e.
Ну включите же фантазию! Это же пример. Сходу видно как минимум два варианта:
и
} catch (Exception $e) {
throw new MyCoolClassException($e->getMessage());
return false;
}
и
} catch (Exception $e) {
throw new Exception('Упс! Нельзя добавить новую сепульку, потому что: '.$e->getMessage());
return false;
}
Тоже постоянно сталкиваюсь с подобной проблемой и посему уже много лет использую один раз выработанное правило — именовать переменные в соответствии с их типами (по первой букве).
Например: $bValidNumber, $iDigit, $sFileName, $oDbInstance и так далее.
Аналогичное правило распространяется и на имена классов/объектов.
Как неоднократно показала практика, внедрение подобного best practice в компаниях существенно облегчает понимание кода много месяцев спустя.
Да и имена становятся более приятными для чтения (вместо $var1, $str, $abc, etc).
Например: $bValidNumber, $iDigit, $sFileName, $oDbInstance и так далее.
Аналогичное правило распространяется и на имена классов/объектов.
Как неоднократно показала практика, внедрение подобного best practice в компаниях существенно облегчает понимание кода много месяцев спустя.
Да и имена становятся более приятными для чтения (вместо $var1, $str, $abc, etc).
Это называется «венгерская нотация», если не ошибаюсь. Только Вы тут смешиваете две разные и независимые друг от друга вещи.
1. Указание типа переменных
2. Значимые имена переменных.
Если убрать префиксы типов, то имена по-прежнему будут «более приятными для чтения (вместо $var1, $str, $abc, etc).»
P. S. Хочу заметить, что я не против венгерской нотации как таковой, я просто указываю на логическую ошибку.
1. Указание типа переменных
2. Значимые имена переменных.
Если убрать префиксы типов, то имена по-прежнему будут «более приятными для чтения (вместо $var1, $str, $abc, etc).»
P. S. Хочу заметить, что я не против венгерской нотации как таковой, я просто указываю на логическую ошибку.
Работал в компании, где применялась эта best practice. Недолго она применялась. Потому как для переменных классов есть PHPDoc, в котором мы можем указать нужный нам тип и IDE его спокойно может подхватить (про блокнотных девелоперов молчу). А все остальные нужно просто нормально уметь именовать. Об этом еще Макконнелл говорил в Совершенном коде. Расписав что и как там на целую главу.
А смысла добавлять s к переменной filename, которая по названию нам говорит что это строка я не вижу? Да и мое любимое — iId, имхо выглядит как полнейший маразм.
А смысла добавлять s к переменной filename, которая по названию нам говорит что это строка я не вижу? Да и мое любимое — iId, имхо выглядит как полнейший маразм.
Увы и ах, но пришлось отказаться от подобного наименования, ибо в PHP оно неэффективно.
Нередко встречаются случаи, когда изначально не знаешь, какой тип у тебя будет храниться в текущей переменной — это факт.
В качестве примера можно привести метод, принимающий переменную $array. Дальше он смотрит — если это массив — возвращает его и делов. Если строка — return explode(', ', $array);
Вот тут непонятки страшнее преимуществ, которые достигаются подобным именованием.
ЗЫ: это простейший случай ;)
Нередко встречаются случаи, когда изначально не знаешь, какой тип у тебя будет храниться в текущей переменной — это факт.
В качестве примера можно привести метод, принимающий переменную $array. Дальше он смотрит — если это массив — возвращает его и делов. Если строка — return explode(', ', $array);
Вот тут непонятки страшнее преимуществ, которые достигаются подобным именованием.
ЗЫ: это простейший случай ;)
Может быть вместо всех этих мучений перейти на жёсткотипизированный язык?
Незнаю, я в последнее время остановился на подходе:
assert('is_string($sText)');
assert('is_numeric($iNumber)');
На assert при желании можно еще повесить свой обработчик, мой например просто складирует сообщения в иерархии вида: «файл -> класс -> метод -> строка», ну или «файл -> функция -> строка», легко можно найти где произошла нестыковка, да и при желании assert можно легко отключить.
assert('is_string($sText)');
assert('is_numeric($iNumber)');
На assert при желании можно еще повесить свой обработчик, мой например просто складирует сообщения в иерархии вида: «файл -> класс -> метод -> строка», ну или «файл -> функция -> строка», легко можно найти где произошла нестыковка, да и при желании assert можно легко отключить.
Делаем PHP строго типизированным
habrahabr.ru/blogs/php/38592/
habrahabr.ru/blogs/php/38592/
Sign up to leave a comment.
Типизация и PHP