igordata нет, это не для скорости. и именно умышленное iliavlad Дело не в php. По приведенной мной ссылке народ исполнял схожий код на AS3 и Java - поведение аналогичное. Цитата от MiksIr на русском - Так как $child исполняется внутри $parent - ему прекрасно известны все (включая private) методы $parent. Никакого нарушения инкапсуляции нет.
igordata Конечно же нет. То, что должно быть скрыто в ParentClass - остается скрыто в нём. А как на счет попробовать самому подумать и осознать?
В большинстве случаев если вы столкнулись с этим при разработке - у вас просто кривая архитектура проекта.
igordata Да, тут тоже всё верно +1 Первое же желание было послать автора подальше и сказать, что архитектура говно. Но потом стало интересно разобраться =)
да хер с ним с этим. эта проблема всплывает при наследовании и создании экземпляра в том, кто был источником наследования. кто-то может об этом не знать и сделать какую-нить систему плагинов, где плагины какнить так хитро работают, и получится дыра, с возможностью достучаться до методов родителя, хотя они private... это хреново. А логически это ниоткуда не истекает. Это надо просто знать. Значит это очередная "мина", которую надо тупо запомнить.
Я реализую просто контроллер и соответственно action контроллеры. Наследовать в данном случае нужно, так как action контроллеру нужны ряд методов родительского контроллера, ну а делать или не делать его синглинтоном здесь не принципиально было. Отдавался просто action контроллер изначально в родительском классе, сейчас по другому уже сделал. Добавлено спустя 12 минут 37 секунд: Да кстати в той же книги "Приемы объектно-орентированного проектирования. Паттерны проектирования" в разделе Одиночка, кучу примеров как создавать подклассы. Так что плохеть от этого не должно)
Ага, только зачем в "просто контроллере" вы создаете объекты "экшн" контроллеров. Родитель ничего не должен знать о детях.
Потому что контроллер основной занимается подключением детишек, поэтому вначале прям в "чреве матери" и создавал, потом стал просто имя класса возвращать, чтобы как раз они не имели доступа к родителю. Добавлено спустя 43 минуты 1 секунду: Кстати на C++ также) Взял книжку по нему и глянул, на этом собственно перегрузка построена в C++
Да, так и есть, я их объединил. А что в этом плохого? Ясли поясните минусы такого подхода, я пойду вынесу в роутер это, пока не поздно)
Пихать все в один класс - вообще плохо. А когда этот клас - базовый для контроллеров, то тем более не нужно. Нужен роутер для финального контроллера? Нет, не нужен. Наследование - расширение функционала базового класса. Т.е. ваш базовый контроллер содержит общие методы всех финальный контроллеров. Роутер же совсем из другой оперы, это что-то вроде... сервис-локатора. Пусть вас не смущает, что в MVC - С это контроллер, это не класс имеется в виду, а набор элементов осуществляющих функцию контроллера. Мне так кажется.
Все верно, но от роутера мне в моей реализации нужен только парсинг uri, и ряд методов связанных с ним, причем как раз часть из них мне нужна в финальном контроллере, и даже сам роутер нужен, для внутренней переадресации. Те методы, которые не нужны они как раз private. Если выносить, то слишком маленький класс роутера получиться. Кроме парсинга uri в нем ничего нет. Более того я видел реализации mvc, когда в роутере выполняли подключение главного контроллера, что на мой взгляд неправильно.
Да кстати забыл добавить, что проблема доступа к ненужным методом решается абстрактным классом, в котором именно общие методы, а вот главный контроллер уже добавляет свои уникальные. Так что меня пока все устраивает)
А роутер по сути только это и делает - занимается преобразованием URI - контроллер + параметры и обратно. Ну и контроллеру ничего не мешает обращаться к роутеру. И это... чем меньше получается сделать класс, тем лучше.