Т.е. класс, который занимается ВСЕМ? 


И почему это должны быть разные классы? Не авторизирован -- это тоже состояние пользователя и набор прав. В чем отличия сборки?



что такое дополнительные прибабахи? примерно столько же сколько и что и причем тут вообще мето? Таксать откуда куда?
И т.д. и т.п.

С телепатией  у меня, видимо не очень, потому как не видя кода не могу определить что такое "прибабах", в чем заключаются различия в сборке и т.д.



Подробнее это может быть:
1. Исходный код
2. Описание взаимодействия классов. Без абстрактных фич и прибабахов, а с конкретными именами и алгоритмами.

Добавлено через 49 секунд
perloid, причем тут интерфейсы, которые не могут содержать реализации?

нет, подключение конфигов, создание главной модели, подключение к БД, разбор урла (дальше передётся только массив), перенаправление на нужный тип модуля - всё происходит раньше.


ёпрст!
вода, песок и цемент используется в разных местах, но в одном месте отливаются статуи, в другом фундамент. я что должен пользоваться одной машиной для обоих целей? мне всего лишь нужно унаследовать бетономешалку и грузовики, два класса, которые поотдельности могут использоваться и в других предприятиях



а это уже невозможно, по причине полуразобранности системы. как раз в основном потому что не нравятся такие нюансы

solenko, код с php.net


как я понимаю из этого примера, можно эмулировать множественное наследование через интерфейсы.
Хотя мне пока в голову не приходит, как именно

Это сообщение отредактировал(а) NewDima - 13.8.2009, 14:20

Интерфейс не может содержать реализации. Являясь абстрактной сущьностью он просто описывает класс. В общем, один класс может быть определен множеством интерфейсов, но всю реализацию методов должен содержать сам.

bars80080, я так и не получил ответа в чем принципиальная разница в сборке страницы



Ок. Давайте поговорим аналогиями.
А теперь представляем что все это находится на территории какого-то предприятия... Вы водителя по машине допускать будете или таки по его документам? И в разные цеха он с разными правами доступа будет ходить не по машине. 


Угу. Наследование должно получится приблизительно такое:
Автомобиль -> Грузовик -> Самосвал
Автомобиль -> Грузовик -> Бетономешалка

Вот только у Автомобиля УЖЕ есть водитель (ползователь). Для того, чтобы водить грузовик, водитель должен иметь определенную категорию (набор прав) А вот самосвал или бетономешалку он водит -- уже пофиг.


Ну тогда этот разговор так и останется о бетономешалках, пестиках и тычинках. Без конкретики это звучит так:
"У меня есть проблемма. Какая не скажу, но стандартные пути решения не подходят".

более конкретного не получишь



есть два предприятия рядом: консервное и оборонное. без документов при попытке въехать на оборонное водителя пристрелят



нет, я имел ввиду другое:

бетономешалка -> моёПредприятие
грузовик -> моёПредприятие

грузовик -> чужаяФерма
комбайн -> чужаяФерма




дык, это не моя проблема. не я топикстартер. автор задал вопрос, ему поставили в укор, что это неправильно. я далее стал разъяснять какая может быть задача.
у меня есть такая заморочка, но не слишком уж важная. однако, если есть решение или конкретное указание как тогда перестраивать ситему - хотел бы послушать

в аналогиях пока чётче получается

вы считаете, что такое наследование имеет право на существование?

Учитывая первую цитату конкретнее чем "ну вот по-другому" не получиш )


Возвращаемся к программированию... 
Водитель без документов (неавторизированный пользователь) -- не попадет никуда (смотрит только страници с общим доступом)
Пользователь с обычым допуском (авторизированный пользователь) -- попадет на консервный завод (ну... личный кабинет, например)
Пользователь с полным допуском (админ) -- попадет на оборонку (backend)

Вот только машине (мега-класс-компонующий-страницу) пофиг имеет ли ее шофер документы. Все решеия принимаются предприятиями (конкретными модулями).




Да, это совсем другое. Это непонятно какие отношения между несвязанными объектами.

в реальности как-то прокатывает


у меня с мягким знаком



да, и возникает резонный вопрос, зачем мне для перемещения между двумя городами на расстояние в 50 км космический корабль?

есть первичный класс, который определяет в какую часть сайта лезет пользователь. каждая отдельная часть имеет свой механизм работы, к примеру, блок независимых модулей имеет в классе-построителе всего два метода, первый ищет модуль, второй отдаёт ему управление, блок непосредственно сайта имеет более сложную структуру, включающую построение меню, наполнение различных контентных частей, подключение обязательных сопроводительных модулей /типа календари, погодники и прочая/, и отдаёт управление только в конце.
но вполне логично, что блок сайта и блок админской части имеют схожее построение, за исключением нескольких методов и свойств. но методы эти громоздкие и требуют дополнительных ресурсов на обслуживание. 
если пытаться сварганить нечто единое, то получится, что интерпретатору придётся постоянно лишний раз обрабатывать кучу лишнего кода. вот, просто нафига?
если сделать два класса отдельно (как оно сейчас реализовано), то во-первых, тупо душит программерская жаба, наблюдая кучу дублированного кода, а во-вторых, внесение любого изменения в код (сейчас во время разработки) вызывает необходимость проводить теже изменения и в другом блоке. если зазеваешься, в итоге можешь что-нибудь не то удалить



а что тут непонятного? по такой системе мы к примеру подключаем разные библиотеки include(), require().
подключаем только то что нам нужно в каждой конкретной ситуации.

а что, будет код, который будет использовать поля/методы этого объекта, пришедшие из всех родителей? Т.е. речь идет о наследовании интерфейса, а не реализации?


мне тоже непонятно, зачем запускать еще одно соединение с БД. Можно сделать глобальную точку доступа к объекту БД, можно вообще БД статическим классом сделать. Возможно, имеет смысл почитать Управление зависимостями в PHP-коде

множественное наследование, насколько я знаю, используется для наследования реализации, а не интерфейса. Т.е. у нас есть некоторый класс (F), и мы хотим воспользоваться его функциональностью в классе (A), принадлежащем некоторой иерархии, а делать доступным извне добавленный класс (F) вовсе не нужно. Scott Meyers в Effective C++ (Item 40: Use multiple inheritance judiciously) приводит пример, когда множественное наследование имеет смысл (тоже несколько абстрактный, мог бы привести по-крайней мере пару конкретных примеров, когда он с этим сталкивался). Проблема, описанная мной выше, решается довольно просто - композиция. Так как не нужно менять интерфейс класса A, то мы просто создаем поле в этом классе, в которое помещаем объект класса F и пользуемся этим объектом. Но есть некоторые частные случаи, специфичные для C++. Если мы хотим немного подправить класс F перед использованием, а сделать это можно с помощью наследования (переопределить виртуальные функции), то в этом случае может пригодиться множественное наследование, но мы унаследуемся от класса F так, что никто, кроме класса A этого не заметит (т.е. никто не получит доступа к полям/методам класса F как части класса A). И вот я не могу похвастаться, что сталкивался с необходимостью в множественном наследовании или знаю конкретные случаи, когда оно имеет смысл

а по поводу твоей ситуации, bars80080, я понял следующее. Есть несколько классов, унаследованных от общего класса, которые генерируют страничку или часть ее. И вот в какой-то из этих классов нужно добавить некоторую функциональность из другого класса. Раз ты почему-то до сих пор не объяснил, о каких конкретных классах речь идет, давай строить догадки (потому что говорить абстрактно действительно нету смысла). Есть классы News и Menu, унаследованные от Element. News генерирует список новостей, Menu - меню соответственно. Надо добавить в News функциональность авторизации. Есть два варианта: 1) либо необходимо ее в интерфейс добавить и получим класс NewsAndAuthorization, 2) либо надо просто воспользоваться функциональностью класса Authorization, в результате получим класс EnhancedNews. Жду твоих комментариев ;)

 <sarcasm>Да, конечно, разработчики вообще тупые.</sarcasm>

Конкретно к "примеру выше" посоветую просто учить ООП.
Более конкретно: кроме is-a есть has-a.

еще можно почитать
http://phpclub.ru/talk/showthread.php?s=&a...%E2%E0%ED%E8%E5
http://phpclub.ru/talk/showthread.php?s=&a...%E2%E0%ED%E8%E5

Можно я тоже совет подкину?

Барс, почитай про шаблоны проектирования и MVC в частности.

ну да, и как отнаследовать в класс EnhancedNews функциональность класса Element и класса Authorization?

Не вижу необходимости наследовать блоку новостей авторизацию. Эта логика должна лежать поверх реализации компонента.