Как избавиться от множественного наследования?

Вот не понимаю я паранойи последнего времени на тему избавления новых языков от множественного наследования.

Вот уткнулся сейчас в проблему вообще в банальном PHP...

Задача - есть набор классов (с большим набором методов) тех или иных web/db-ресурсов. Это может быть простой ORM-маппинг, может быть дерево, хитро извлекаемое из БД, список...

Их наследники - конкретные типы объектов. Грубо говоря - простая страничка сайта, или вывод сложной формы...

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

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

Пока нам хватает стандартных настроек - всё прекрасно.

Но вот нам для раздела сайта требуется ряд общих настроек. Например, идентификаторы баннеров, имя шаблона...

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

Но что делать, когда страницы должны принадлежать разным базовым классам??

Будь у нас множественное наследование - никаких проблем. Скажем, дерево категорий наследуем от базового дерева и базового набора свойств раздела.

А вот без него - фиг.

Каким боком тут можно прикрутить те же интерфейсы, скажем - просто не представляю.

Как быть-то?

Рома, может я чего-то не понял из твоего поста.
Но избавляться пытаются от множественного наследования классов, но не интерфейсов.
Т.е. базовых классов всегда не больше одного, а вот интерфейсов которые ты в классе имплементишь может быть много.
Т.е. у тебя есть интерфейс IHierarchy (дерево), есть интерфейс IForm (просто форма), есть интерфейс IElementList (список чего-нибудь).
Есть базовый класс Page который представляет из себя базовую реализацию страницы.
Ты делаешь свой класс страницы наследуя его от Page и интерфейсов IHierarchy и IForm.
И дело сделано.
Если ты хочешь использовать уже готовыю реализацию интерфейса IHierarchy из другого класса - то делаешь агрегацию.

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

Мне нужно, чтобы некий класс принял два базовых, описанных в других местах набора методов.

Один - собственно, основная работа класса (данные страницы, заголовок и т.п.)

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

В принципе, я задачу сейчас решил, но - костылём. Загрузчик классов проверяет наличие в том же каталоге, откуда грузится нужный класс файла другого класса с зарезервированным именем и при его наличии - грузит и инициализирует, передавая в качестве параметра только созданный наш объект. Поскольку (повезло) все общие параметры конечных классов в этом частном случае можно задать через set-методы, то этот вторичный "класс-инициализатор" этим занимается. А все классы данной категории сайта лежат в одном каталоге, так что и инициатор для них - тоже один.

К сожалению, это очень частный случай.

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

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

В общем, куда ни кинь - одни костыли выходят.

И ради чего? Ради отказа от естественного представления объектов в окружающем мире.

Яблоко - это растение, объект зелёного цвета, пища.

Звезда - это астрономический объект, природный термоядерный реактор, центр планетарной системы...

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

И ООП, которое изначально сделало шаг в этом направлении, потом за совершенно неадекватными оговорками делает шаг назад и начинает вводить костыли в виде интерфейсов, композиций и т.п....

Главный (и единственный?) аргумент против множественного наследования - неоднозначности в случае появления одинаковых методов у разных родителей.

Но любой, даже самый тупой компилятор должен уметь отлавливать эти неодноначности на этапе компиляции.

Так откуда тогда могут взяться неоднозначности?

Мне, всё же кажется, что тут у народа какой-то массовый заскок.

Возможно, в отрыве от практики задача выглядит непонятно, постараюсь показать (упрощённо) ключевые моменты кода:

1. Есть базовый класс "страница сайта", содержащий массу методов, возвращающих параметры страницы (из которых система потом и собирает эту страницу):
title() - заголовок страницы
description() - её описание
source() - текст
body() - скомпилированный (разметка -> html) текст, по умолчанию сам собирается из source()
create_time() - дата создания
modify_time() - дата изменения
и т.д. и т.п.

У базовой страницы методы в основном абстрактные, но у неё куча наследников. Страницы, которые извлекают данные из файлов файловой системы, страницы, которые извлекают данные и базы данныех и т.п.

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

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

В случае множественного наследования проблем нет. Скажем, наш список наследует классы def_dbtree и my_section и в нём пишется, подчас, буквально несколько строк кода. Запрос, генерирующий данные для дерева (само дерево соберётся методами из def_dbtree, которые будут делать этот запрос), небольшая подстройка данных по умолчанию в my_section (скажем, у всех страниц единый ID баннера в баннерной сети, но для отдельного класса страниц он должен быть иной).

Но у нас множественного наследования нет.

Что можно предложить взамен?

Композиция отпадает сразу. Потребуются обёртки для многих десятков параметров.

Копипаст?

Мой вариант с вторичным инициализатором в конкретных условиях?

Костыли, одни костыли...

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

Скорее всего, в будущем система и будет на Питоне.

Но будет это не раньше, чем Питон массово появится на виртуальных хостингах Пока же это, ИМХО, в принципе невозможно. На сколько я знаю, никакая из реализаций связки Питон + веб-сервер не обеспеивает per-user виртуального хостинга :-/

2timochka
В Питоне множественное наследование обычно используется в качестве микс-инов. Скажем так - я ещё ни разу не видел, чтоб его применяли в каком-то другом случае. Очень хорошая штука, когда мне нужно добавить к какому-нибудь классу из сторонней библиотеки несколько функций - я пишу свой класс, и добавляю его к предкам библиотечного - voila, всё работает. Я так понимаю, что Балансеру сейчас нужно как раз что-то подобное.

Balancer> - Есть тонны кода, который придётся тупо переписывать.

It is irrelevant to the topic. You asked why multiple inheritance is bad (more exact, why new languages get rid of that), not how to refactor your project.

Balancer> - Получаем заметное падение производительности, поскольку у нас появляется лишняя операция извлечения этого DataProvider.

Nothing even close to this. What are you talking about? Do you put your JDBC operators to one method? All those methods should be separated. This is business logic, it should be clearly separated from the interface. If we are talking about the problem you described, the best way to do this would be put all business logic apart, to EJB methods. If you think it would be not fast enough, think - financial institutes do it this way for millions of transactions and it's good enough for them.

Balancer> - Наконец, придётся переписать всю систему шаблонов, так как используемая не понимает метода от метода для класса. Ну вот такие у Smarty ограничения.

Irrelevant to the topic.

Balancer> Итого - имеем человекомесяц лишней работы... Да проще уж, действительно, всё на Python переписать, где это множественное наследование есть Объём работы сопоставим будет. И перспективы, опять же...

It depends on what you want. It cannot prove that multiple inheritance is a good approach to design.

PS Sorry for English, don't have Russian keyboard. No need to answer English, though, I can read Russian.

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

Ибо с тем или иным количеством костылей можно избавиться от всего.

Я приду домой и напишу большой пост. На работе нет времени. Попробую порассуждать на всё темы сразу.

Несколько мыслей.

Множественное наследование, простое наследование. На примере С++.

Было время, когда множественного наследования не было. Было только простое. И люди жили. Само наследование было нужно для того, чтобы наследовать код и данные, т.е. то, что определяет поведение и текущее состояние объекта. При этом получилось так, что и полиформизм тут помогал в своей обычной манере. Но не более. И само наследование, которое было призвано сократить труд по переписыванию кода много раз, а значит и уменьшить количество ошибок и т.п., не срабатывало когда надо было наследовать от нескольких объектов. Инкапсуляция тоже играла роль, ограничивая возможности наследования путём создания уровней доступа к методам и членам. Точнее не ограничение наследования, а возможности модификации этого самого поведения.

Так появилось множественное наследование. Логичное продолжение простого. А полиморфизм просто засиял — ведь объект мог быть всем, что было в базе. Проблемы начались, когда стали думать об эффективной реализации. Не выходил каменный цветок. Точнее выходил, но не такой. Для виртуальных методов(статические методы и name mangling пока не трогаем — это не совсем реальный полиморфизм — это статический полиморфизм). Это было понятно — просто таблицей адресов методов было не обойтись (в этом смысле ООП было ещё в форме файлов значительно раньше — когда для открытого файла можно было назначить свои процедуры обработки конца файла, конца страницы и т.д.). Приходилось тащить целую кучу таблиц. Что выливалось в понижении эффективности. Ну тут начались и те проблемы, что многие таблицы, методы и члены могли включатся много раз. Разрешить? Запретить? Так появились виртуальные базовые классы.

Но множественное наследование — это статическое дело. И применять его для решения некоторых динамических задач можно, но не нужно. Но поезд не остановить. Особенно пяткой. Народ стал использовать. Что послужило одним из толчков к разработке паттернов в программировании. Банда четырёх проанализировала код и вывела 25 патернов. И пошло и поехало. Действительно, оказалось, что можно и нужно использовать аггрегирование и композицию вместо множественного наследования. И это было правильно. Джава создатель решил, что множественное наследование не нужно в таком виде. Но отказаться от всех преимуществ полиморфизма в множественном наследовании не хотелось. Так появились интерфейсы. Но...интерфейс приходится имплементировать каждый раз заново. Т.е. интерфейс есть, а наполнения — ноль. Вот она — цена счастья. Но иногда хочется тянуть методы и алгоритмы при том, что типы членов не известны. В С++ есть templates (Степанов занимался generic programьing ещё в 70-е годы — АТП, Ада — generic packages, другие языки). GP в чистом виде код без данных — полная абстракция от типов данных. Ну и, как результат, статический полиморфизм за счёт генерации кода. Правда, в С++ ввели специализацию для уменьшения того, что называют code bloating. А в Джаву новую добавили templates.

Поэтому я не совсем согласен с riven-mage — множественное наследование изменилось. И сильно. А вот как результат пришлось в некоторые языки вводить небольшие костыльки. multiple interfaces не есть полноценная замена множественного наследования — наполнение интерфейса приходится делать каждый раз заново. Но это и понятно — не получается полностью имплементировать интерфейс, если не известен объект, для которого надо его имплементировать. Так сказать чисто теоритический залепон. Темплэйты единственный выход. Плата за это — приходится таскаться по дереву наследования на несколько уровней выше, а вниз — даункастом. Что очень не кошерно.

С точки зрения вышесказанного — дизайн, что у Ромы требует полного рефакторинга. Не ложаться странички сервера нормально на множественное наследование. Композиции, агрегации и т.д. нужны. Тут я Сергеем и Тимочкой соглашусь на 100%.

Как переделать малой кровью? Темплэётами, если они есть. Если нет — рефакторить. Со сменой дизайна.

Лиспу хотите?