Сослепу прочитал заголовок как «Ускоряем работу PHP с помощью перегрузки», и было решил, что тут про замену условий на вызов методов, а оно вон как оказалось.
Если мы используем наследование, переопределение блоков и прочиепрелести твига, то мы понимает что он выигрывает у нативного пхп синтаксисом и скоростью разработки.
Если мы посмотрим на скомпилированные шаблоны твига, то увидим что код в них написан максимально оптимально (хоть зачастую и нечитаемо совсем). Те же блоки — просто методы класса, поэтому наследование — шаблонов — обычное нативное наследование классов в php. Ввиду изложенного мы понимаем что твиг как минимум не проигрывает в скорости нативному php.
А ещё есть такие моменты как:
1. Валидация значений (например поле gender — только 'male' или 'female')
2. Динамические параметры по умолчанию — вот это самый главный плюс компонента. Это когда если один из параметров не передан явно, то на основе других параметров можно вычислить его значение.
Нет, фишка как раз таки в валидации. Компонент позволяет не создавать на каждый чих value-object в параметрами + ещё имеет огромную кучу плюх. Посмотрите пример в документации хотя бы github.com/symfony/OptionsResolver/blob/master/README.md
Интересно, а если написать полностью restful-контроллер, его можно будет без подводных камней использовать для рендеринга в браузере? Ну т.е. сделать браузер Resftul API клиентом чтоли :)
Я ездил в Егпите по акции. Обещали скидку в 50%, на деле вышло где-то около 10%, но я всё просчитал ещё до покупки купона и сделал вывод о том что 10% тоже скидка. Всё было хорошо.
Далеко не всегда оно может существовать в единичном экземпляре. У меня был проект, где все основные данные хранились в одной БД mysql, а учётные записи пользователей — в другой. Причём не было пользователя с одновременным доступом к двум базам (политика безопасности такая вот у хостера). То есть надо как минимум 2 коннекта с БД. И как тут обойтись с помощью синглтона?
Ну мы же сравниваем с синглтонами, так? То есть теми объектами, к которым уже исходя из паттерна проектирования все имеют доступ? Здесь просто другой метод доступа к ним, с явной инициализацией в конструкторе объекта-контейнера, и всё.
Ну вам наверно виднее, но я не понимаю что тут плохого. Просто этот объект запускает, координирует приложение. Какая разница где это делать — в index.php рисовать портянку инициализации классов или в Application::__construct(), а приложение запускать как Application::run(). И почему бы централизованно не хранить в нём все объекты, которые могут использоваться в любом месте программы как синглтоны? Storage, Session, Cookie, Request, Response. Мы можем писать Storage::getInstance(), а можем $this->application->getStorage(), только в первом случае мы должны за всеми классами таскать код для реализации паттерна «Синглтон», а во втором случае не должны ;-)
Подход «божественного объекта» противоположен этому принципу: основная часть функциональности программы кодируется в одном объекте. Так как этот объект хранит большое количество данных и имеет много методов, его роль в программе становится «божественной» (всеобъемлющей).
В данном случае через Application мы всего-то имеем доступ к другим объектам. Только чтобы было достаточно чётко видно где в первый раз инициализируется объект (в конструкторе Application)
Ну вообще, до нейспейсов все использовали именно этот подход. Зато с неймспейсами получается удобнее: я например могу засунуть несколько классов в одно пространство имён, называя их как "<имя_файла>_<Имя класса>" и пользоваться автолоадером. То есть неймспейс — путь до файла, имя файла — всё что до первого символа "_". Вот мой автолоадер:
//Автолоадер:
function autoloader($classname){
if (!class_exists($classname)) { //Если такой класс ещё не существует
$parts = explode('\',$classname);
$classname = $parts[count($parts)-1]; //Последний элемент - имя класса
unset($parts[count($parts)-1]); //Убираем из пути к файлу имя класса
Если мы используем наследование, переопределение блоков и прочие прелести твига, то мы понимает что он выигрывает у нативного пхп синтаксисом и скоростью разработки.
Если мы посмотрим на скомпилированные шаблоны твига, то увидим что код в них написан максимально оптимально (хоть зачастую и нечитаемо совсем). Те же блоки — просто методы класса, поэтому наследование — шаблонов — обычное нативное наследование классов в php. Ввиду изложенного мы понимаем что твиг как минимум не проигрывает в скорости нативному php.
Мой выбор — твиг.
1. Валидация значений (например поле gender — только 'male' или 'female')
2. Динамические параметры по умолчанию — вот это самый главный плюс компонента. Это когда если один из параметров не передан явно, то на основе других параметров можно вычислить его значение.
Эти штуки идут из коробки.
github.com/symfony/OptionsResolver/blob/master/README.md
github.com/symfony/OptionsResolver
Подход «божественного объекта» противоположен этому принципу: основная часть функциональности программы кодируется в одном объекте. Так как этот объект хранит большое количество данных и имеет много методов, его роль в программе становится «божественной» (всеобъемлющей).
В данном случае через Application мы всего-то имеем доступ к другим объектам. Только чтобы было достаточно чётко видно где в первый раз инициализируется объект (в конструкторе Application)