Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>>Теперь я хочу работать с точками в 3д которые также есть графические объекты на экране.
АХ>>Что здесь более естественно чем двойное наследование?

MS>Уверяю тебя, что ты не хочешь работать "с точками в 3д которые также есть графические объекты на экране". Перефразируя, можно сказать, что точке как графическому объекту на экране не нужны операции сложения, векторного произведения и т.п. Если же получается так, что они нужны, то это означает плохой дизайн и нужно срочно что-то провить в консерватории, а не порождать неестественных классов-уродцев.

Почему это плохой дизайн я не вижу. Как лучше то?

Вот у меня есть куча точек которые есть графические объекты (скажем это частицы какие-нибудь в particle system), хочу я их все сдвинуть на вектор. Естественно для этого применить операцию которая есть в классе вектор.

А ты что предложишь?

Здравствуйте, Андрей Хропов, Вы писали:

АХ>>>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>>>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>Вот у меня есть куча точек которые есть графические объекты (скажем это частицы какие-нибудь в particle system), хочу я их все сдвинуть на вектор. Естественно для этого применить операцию которая есть в классе вектор.

Подразумевается, что кроме точек есть и другие типы объектов, так? То есть, кружочки, шарики, кубики. И у всех их должна быть операция "сдвинуть на вектор" (то есть, виртуальный метод такой). Иными словами, операция "сдвинуть на вектор" является первичной по отношению к классу "графический объект на экране" и весьма вторичной по отношению к классу "точка 3d". класс "точка 3d" может вообще не иметь этой операции,а вот "точка_3d_как_графический_объект_на_экране" — обязан по контракту. Если же у нас только точки умеют двигаться, а прочие объекты не умеют, то это надо лечить.

АХ>А ты что предложишь?

Инкапсулировать "точка_3d" в "точка_3d_как_графический_объект_на_экране" и выставлять (expose) только те методы, которые реально необходимы. На поверку как правило оказывается, что практически ничего из фуцнкциональности "точка_3d" не требуется. А если что-то требуется, то немного не так, а через какой-то адаптор. Иными словами, ты не хочешь работать с точками в 3д которые также есть графические объекты на экране.

Андрей Хропов wrote:
> Вот у меня есть куча точек которые есть графические объекты (скажем это
> частицы какие-нибудь в particle system), хочу я их все сдвинуть на
> вектор. Естественно для этого применить операцию которая есть в классе
> вектор.
> А ты что предложишь?
Вообще говоря, в графических системах обычно делается разделение между
объектами и их преобразованиями.

Таким образом, мы можем использовать одну модель (единственную particle)
и размножить ее просто используя разные преобразования.

Но это детали, мне самому MH нравится так как позволяет использовать
mixin'ы и ряд интересных приемов.

Здравствуйте, Андрей Хропов, Вы писали:

V>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>Что за глупость.
АХ>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Андрей Хропов, Вы писали:

V>>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>>Что за глупость.
АХ>>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

V>Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.
Нормально. Статической полиморфности не существует потому как это кодогенерация. Частичная специализация для шаблонов тоже кодогенерация?

C>Но это детали, мне самому MH нравится так как позволяет использовать
C>mixin'ы и ряд интересных приемов.

Согласен на 100%. МН это инструмент, который позволяет как плодить гибриды ежа с ужом, так и делать миксины которые ИМХО есть мегаудобный способ для того чтобы научить ежей плясать кадриль и ездить на велосипеде .

АХ>1) Со множественным наследованием есть проблемы (например Diamond problem). Так как если использовать его без меры граф наследования становится запутанным и становится трудно понять что к чему.

Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++. Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё есть object, это не так-то просто.

Left2 wrote:
> Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
> Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё
> есть object, это не так-то просто.
Аналогично, не помню случая когда мне Diamond понадобился бы.

Здравствуйте, GlebZ, Вы писали:

V>>>>В нединамических языках полиморфизм только через наследование и бывает.
АХ>>>Что за глупость.
АХ>>>Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

V>>Этот полиморфизм скорее к кодогенерации относится, чем к обсуждаемому ООП.
GZ>Нормально. Статической полиморфности не существует потому как это кодогенерация.

Словосочетание "статическая полиморфность" — софизм сам по себе.
Хотя я прекрасно понимаю предпосылки образования подобного сленга, ибо 12 лет в этом направлении вожусь. Вся суть в пресловутой "точке зрения", больше ни в чем.

GZ>Частичная специализация для шаблонов тоже кодогенерация?

Именно
Особенно частичная.

Или попробуй пойти от обратного и поискать здесь ОПП. Например, на шаблонных свободных ф-иях.

ИМХО, перезагрузку сигнатур ф-ий тоже стоило бы отнести к определенному виду полиморфности, если считать за таковую специализацию шаблонов. Как тебе?

vdimas wrote:
> ИМХО, перезагрузку сигнатур ф-ий тоже стоило бы отнести к определенному
> виду полиморфности, если считать за таковую специализацию шаблонов. Как
> тебе?
Ну как бы оно тоже считается "статическим полиморфизмом".

Здравствуйте, Cyberax, Вы писали:

C>Left2 wrote:
>> Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
>> Ибо это практически всегда ошибка дизайна. Конечно, в Java/C# когда всё
>> есть object, это не так-то просто.
C>Аналогично, не помню случая когда мне Diamond понадобился бы.

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

D>А он не и надобится, он сам приходит. Причем внезапно. Решили вы, например, унаследоваться от двух невинных на вид классов, а они оказываются имеют общего предка в десятом колене. И причем, этот общий предок, как назло, был унаследован невиртуально.

Как раз приведённую ситуацию я считаю ошибкой дизайна — попыткой получения ужеежей.

Ну и если Diamond будет запрещён, то и виртуального наследования никакого не будет.

Здравствуйте, Left2, Вы писали:
L>Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
Ага. И прощай <stdio>?
L> Ибо это практически всегда ошибка дизайна.
Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в stdlib.

Sinclair wrote:
> L>Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
> Ага. И прощай <stdio>?
> L> Ибо это практически всегда ошибка дизайна.
> Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
> stdlib.
А где там оно используется?

Здравствуйте, Cyberax, Вы писали:

C>Sinclair wrote:
>> L>Я б с лёгким сердцем просто запретил бы Diamond По крайней мере, в С++.
>> Ага. И прощай <stdio>?
>> L> Ибо это практически всегда ошибка дизайна.
>> Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
>> stdlib.
C>А где там оно используется?

имеется ввиду наверное <iostream>. класс iostream наследуется от istream и от ostream, которые, в свою очередь, имеют общего предка ios.

Здравствуйте, Left2, Вы писали:

C>>Но это детали, мне самому MH нравится так как позволяет использовать
C>>mixin'ы и ряд интересных приемов.

L>Согласен на 100%. МН это инструмент, который позволяет как плодить гибриды ежа с ужом, так и делать миксины которые ИМХО есть мегаудобный способ для того чтобы научить ежей плясать кадриль и ездить на велосипеде .

Вот из-за таких как вы приходится неделями разбираться в коде где ежи на велосипедах ездют, хотя ето вообще не надо. Заглядывайте почаще в ветку Архитекрура ПО, Множественное наследование — это зло.
Кстате, полиморфизм — это не главная причина наследования, лучший полиморфизм достигается при помощи делегирования. Наследование только усиливает связь объектов, тем боллее множественное, а это в свою очередь приводит к усложнению отладки, расширения и вообще можно потеряться понимание того что пишешь. Я не говорю что наследование это плохо, просто применять надо грамотно.

dshe wrote:
>> > L> Ибо это практически всегда ошибка дизайна.
>> > Да это ж гордость дизайна С++! Даймонд вперед всего применили именно в
>> > stdlib.
> C>А где там оно используется?
> имеется ввиду наверное <iostream>. класс iostream наследуется от istream
> и от ostream, которые, в свою очередь, имеют общего предка ios.
Точно. Ну если ради запрета diamond придется передизайнить библиотеку
потоков — то это еще один большой плюс Потоки в С++ — это самая
неудачная и запутанная часть стандартной библиотеки.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Ramzes_, Вы писали:

R_>>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность.

MS>Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

Согласен. Добавлю к сказанному от себя.

Чисто теоретически, множественное наследование действительно иногда может быть уместным. Это тот очень редкий случай, когда производный класс является полной суммой своих предков. Но проблема множественного наследования заключается в том, что предвидеть этот случай на этапе проектирования крайне трудно. В итоге, практика использования множественного наследования сводится к следующему сценарию:

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

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

3) Ввиду того, что при применении наследования, и тем более, множественного наследования у нас получается весьма железобетонная архитектура (антоним гибкой), то начинаются пляски с бубном, которые выражаются в:
-- жутких архитектурных хаках
-- банальном copy/paste
-- нагромождении if/switch
На подобные шалости уже закрываются глаза, так как "проект надо было сдавать еще вчера". В итоге, код становится помойкой.

Но наследование, как и множественное наследование имеют известную альтернативу в виде интерфейсов+агрегирования+делегирования. Конечно, интерфейсы имеют свои недостатки, среди которых, например, то, что на начальном этапе реализации проекта приходится писать немного больше кода, чем если бы использовалось [множественное] наследование. Но зато, получается очень гибкая, а следовательно, и устойчивая архитектура, которая легко поддается развитию и рефакторингу.

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

Мои 2 копейки в защиту множественного наследования.

Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

есть альтернативы ?

Здравствуйте, McSeem2, Вы писали:

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

Да!
Только вот это уже не наследование называется, а ad-hoc полиморфизм.
В haskell еще кстати система типов так и устроена.