Добрый день.
Как сделать чтобы конечный класс Base мог вызывать ф-ции других классов (Test1, Test2, Test3, ...)

обычно необходимость в множественном наследовании означает неправильно выбранный способ решения задачи. Зачем понадобилось множественное наследование?

Marena, множественное наследование не поддерживается в php, по причине, о которой сказал youri.

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

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

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

Конкретный пример в студию

а к элементу хэша нельзя прицепить ссылку на объект какого-то класса?

Это сообщение отредактировал(а) gcc - 13.8.2009, 10:47

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

вот и получается, что приходится делать не универсальные решения, где приходится либо создавать объект из свойства класса:
$this->db = new DB();
но этот вариант не удобен тем, что зачем запускать ещё раз соединение с БД, если оно уже есть в другом объекте?
либо передавать объект с помощью global, что попахивает частным не гибким решением

если бы можно было отнаследовать ряд нужных классов в один, да ещё по ходу действия - это было отлично

не совсем гуд через глобал



разработчики не учли этого момента.

Добавлено через 26 секунд
Интересно, а через какой-нить изврат это удасться сделать? 

Добавлено через 44 секунды

это как?!

я не пробовал, а что нельзя?
зачем тогда придумали клонирование объекта?

1. Кроме наследования есть еще и композиция
2. Если пропустили, я тут статейку переводил про внедрение зависимостей... Посмотрите -- вам может быть интерестно

3. Что значит "построение страници для типа 1"? Чем занимается класс? Сборкой страници? Что в нем делать авторизации? Если у вас есть существенно разные типы страниц, и вы таки хотите использовать наследование, почему у вас нет:

?

Когда я говорил о конкретном примере, я имел в виду нечто более конкретное чем вы привели.

Добавлено через 4 минуты и 54 секунды

Не поверите, для клонирования объекта )
Вот простейший пример:
А ведь могут быть и сложные правила создания копии объекта, которые можно определить в __clone

А чем Вам действительно не подходит клонирование ? Создаете объекты нужных Вам классов внутри своего и пользуетесь их функциями наздоровье!?

условное название


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


да, это можно, но это то что называется от противного. т.е. создавать универсальный класс и делать два потомка с расширениями. но из-за этого придётся переписывать уже существующие. 



ну, я уж не знаю как подробнее



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

Кури интерфейсы

http://www.cyberguru.ru/web/php/php5-transition-page4.html

http://us2.php.net/manual/en/language.oop5.interfaces.php

http://phpclub.ru/faq/PHP5/Interface

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


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



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

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



Подробнее это может быть:
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?

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

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

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

Ну тогда все понятно. Единственное, что могу тебе порекомендовать, посмотреть в сторону шаблона "Декоратор" (он же Wrapper). 

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


Это сообщение отредактировал(а) perloid - 19.8.2009, 09:43

1. Тут нет задачи как таковой
2. Использование интерфейсов и абстрактных классов не делают код лучше или хуже сами по себе.
3. Использование интерфейсов и абстрактных классов ничего не меняет в архитектуре и никак не влият на структуру классов

Так что, в данном случае, интерфейс это просто умное слово, примененное не к месту.

можно взять за основу CI, в итоге получим:
index.php



index2.php


больше вариантов не вижу, или их нет, или же опыта мало (кроме использования глобал)