shasoftX, есть в таком случае какие-то причины наследовать NodeB от Node? Может и то и другое должны наследоваться от интерфейса или абстрактного класса, но не наследовать один от другого?
Какую вы задачу решаете? Если метод protected, то он задекларирован с вызываться из наследников.
Если единственный вариант - кривые проверки - это признак того что все надо переделывать
Да, я погорячился, сейчас как раз занимаюсь проектом где большой нестед сет. Таблица в которой нестед сетов точнее говоря. Она у меня является основой, вот и как-то ступил…
В общем я к тому что на практике никаких проблем нет, если разделить сущности. Джойны иногда конечно бывают по 10-12 таблиц, но там что 10, что 20 не важно. Главное никаких проблем с этим нет.
Если в шаблоне для какого-то action описано два параметра, то функция должна принимать два параметра.
И вообще нужно создавать такие шаблоны, чтобы не было этого самого fatal. И не зачем недалать дополнительные проверки, ибо если руки кривые, все равно где-нибудь будет косяк.
Вы видели в каких-нибудь фреймворках чтобы так делали? Лол, как вы будете проверять параметры если допустим входящие параметры должны быть (int) или (float).
Например в cakephp в action параметры приходят уже после того как url сравнится с массивом шаблонов и если будет совпадение он парсится и только тогда они попадают в action. Что исключает момент когда параметров может быть больше или меньше чем нужно.
А через ReflectionFunction проверять это костыль
Ну тогда если вы нормально реализуете роутинг, интернационализацию/локализацию, никаких проблем с относительными сылками не будет. А на счет сложнее/проще все уже написал XRay39.
Ну тут же вопрос был не про диплом, а про учебу… ) Диплом — это бумага, а систематическое образование — это СИСТЕМАТИЧЕСКОЕ ОБРАЗОВАНИЕ… Оно лишним никогда не будет
Может вам лучше фреймворк какой-то взять. Думаю практически во всех реализован роутинг, предусмотрены инструменты для интернационализации и локализации…
Да что-то CI не особо впечатлил… (ИМХО) Он скорее для опытного программиста, который хочет иметь бОльшую свободу действия, но при этом не писать с нуля фреймворк основанный на MVC
Ну тут разные пути бывают… Мне например чтобы прийти к тому же результату, не потребовалось писать свой фреймворк…
Имея опыт программирования 2-3 года и впервые столкнувшись с MVC фреймворком никаких проблем не испытывал.
С другой стороны разбирать готовый фреймворк не имея большого опыта программирования, вряд ли под силу среднестатистическому человеку. Для этого как минимум нужно знать что такое ООП и четко представлять его преимущества, ну и нужно иметь хоть какое-то понимание что такое MVC
