как бы вроде стандартное решение, особенно в синглтонах.
только удобнее использовать не Application::getInstance(), а self::getInstance(), тогда не забудем поменять имя класса при рефакторинге возможном :)
для своей хоумпаги писал что-то подобное, только там было 2 возможных модели урлов — /controller/action и произвольные роуты, ну и немного другая модель переменных, без всяких ассертов, сразу в маршруте пишем регулярку.
Примерно так:
/updates/get попытается вызвать updatesContoller->getAction
/blog/get/123 blogController->getAction, и сиглтон Request будет содержать параметр id = 123.
хе, вы правы, ~15% разница.
Основная проблема в том, что компилятор не распознаёт то, какую функцию мы вызываем. И не может соптимизировать — инлайн не выполняется, оптимизация по регистрам тоже невозможно, так как не известно в каком окружении вызывается табличная функция, и какие регистры свободны, для case'ов такой проблемы нет.
Действительно, насчет производительности я был не прав.
switch -> call table а внутри функций из этой таблицы будет вложенность 2-3, судя по коду.
На производительности это ни скажется ни разу, ибо современные компиляторы сами используют такой подход при генерации кода.
Единственный минус такой замены в плюсах/си только то, что мы не сможет в case'ах падать вниз, что самом по себе является дурным тоном.
Ну вроде такого:
case 'a':
doSomeForA();
case 'b'"
doSomeForAB();
break;
Ну а насчет «красивости» — мне свитчи совсем не нравятся, использую таблицы вызовов довольно часто. Здесь дело вкуса.
В гугле объясняют свои предпосылки.
С этим правилом, как я понял, ситуация такая, что хотят сохранить однородность кода, ибо уже много написанного, который следует этому правилу.
А вообще вместо 80 можно подставить своё, суть не поменяется, кроме того что лимит должен быть обязательно, ибо не у всех 22"-30" мониторы.
ну опять же — не у всех цель карьера, а например заниматься любимым делом за неплохую зарплату гораздо лучше для них чем быть менеджером за отличную зп.
Параметр crossDomain
только удобнее использовать не Application::getInstance(), а self::getInstance(), тогда не забудем поменять имя класса при рефакторинге возможном :)
Примерно так:
/updates/get попытается вызвать updatesContoller->getAction
/blog/get/123 blogController->getAction, и сиглтон Request будет содержать параметр id = 123.
А в ваш код неплохо было бы добавить autoload.
имхо, это не особо корректно :)
Основная проблема в том, что компилятор не распознаёт то, какую функцию мы вызываем. И не может соптимизировать — инлайн не выполняется, оптимизация по регистрам тоже невозможно, так как не известно в каком окружении вызывается табличная функция, и какие регистры свободны, для case'ов такой проблемы нет.
Действительно, насчет производительности я был не прав.
На производительности это ни скажется ни разу, ибо современные компиляторы сами используют такой подход при генерации кода.
Единственный минус такой замены в плюсах/си только то, что мы не сможет в case'ах падать вниз, что самом по себе является дурным тоном.
Ну вроде такого:
Ну а насчет «красивости» — мне свитчи совсем не нравятся, использую таблицы вызовов довольно часто. Здесь дело вкуса.
да, причём не только можно, но и нужно :)
ну и функции декомпозировать, если больше 2х сферических экранов.
С этим правилом, как я понял, ситуация такая, что хотят сохранить однородность кода, ибо уже много написанного, который следует этому правилу.
А вообще вместо 80 можно подставить своё, суть не поменяется, кроме того что лимит должен быть обязательно, ибо не у всех 22"-30" мониторы.
например у гугла
длинные if'ы с кучей условий не всегда влезают в 80 символов.