зачем нужны примеси, если есть множественное наследование?

А ты зачем-то пытаешься поместить ребенка во множество его родителей.

Это было бы так, если бы оба родителя были бы абстрактными сущностями, которые не могут существовать сами по себе в принципе :-)

Это не «было бы», это так и есть - ты пытаешься. Естественно, в результате у тебя получается унылое месиво.

Если ты о том, что Вася может в определенный момент в рантайме перестать стать футболистом, то для динамических ООП-языков тут проблем нет, можно и «отнаследовать», в смысле, выкинуть из наследия класс в любой момент

Это не «было бы», это так и есть - ты пытаешься.

Добро пожаловать в реальность :-)

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

Причём тут я? :-)

В Яве 1.8 ввели множественное наследование.

Нет, начался активный поиск общности, как то велел делать тот же Страуструп :-)

Искать общность - это прекрасно. Но ты нашел общность, а думаешь, что нашел базовый класс.

В чем проблема изменяемости(для нормальных ООП языков)? В чем конкретно проблема? Приведи пример, пожалуйста

Проблема в том, что ты очевидно понимаешь под «нормальными ООП-языками» только языки с динамической типизацией.

Father и Mother это Human и имеют общую часть реализаци

Пример не в тему. Я не являюсь ни мамой, ни папой. Кажется, что это мелочь, а если вдуматься, то это не мелочь уже.

Но ты нашел общность, а думаешь, что нашел базовый класс.

Не думаю, а знаю :-) Общность в ООП выражается только с помощью родительского класса :-)

Я не являюсь ни мамой, ни папой. Кажется, что это мелочь, а если вдуматься, то это не мелочь уже.

Вот что надо делать, а не какие-то там кул-язычки :-)

Да, термин «ООП» принадлежит Алану Кею, он имел в виду именно динамические языки, статику он не рассматривал, ее позже за уши притянули. Естественно, статика концепцию нормально реализовать не может

но примеси сами по себе могут образовывать ромб

Не могут

Разберусь - напишу. Во всяком случае, раз есть линеаризация в Скале, то нет дыма без огня.

Но ты нашел общность, а думаешь, что нашел базовый класс.

Не думаю, а знаю :-)

Думаешь, что знаешь.

Общность в ООП выражается только с помощью родительского класса :-)

Только? Да ты реально болен.

Думаешь, что знаешь.

Знаю, что знаю :-)

Только? Да ты реально болен.

А кто реально здоров? :-) Ты что-ли? :-)

Пример не в тему. Я не являюсь ни мамой, ни папой. Кажется, что это мелочь, а если вдуматься, то это не мелочь уже.

А в чем проблема то? наследуй от Human JustHuman и будешь не-мамой-не-папой

А в чем проблема то? наследуй от Human JustHuman и будешь не-мамой-не-папой

А если от Android JustAndroid? :-)

От ситуации. Я, собственно, не вижу проблем наследовать его объект непосредственно от самого Человека, этот JustHuman может быть и лишним, хз, что у него там за случай.

Короче, вот пример.

Допустим, имеем классы Человек, Мама, Папа, Ребенок.

Как концептуально правильно надо тут выстроить иерархию? На мой вхгляд так: Ребенок наследуем от Человек Мама Папа. Мама и Папа — от Человек.

Наследовать ребенка нужно от человека в первую очередь, потому что Мама может быть инвалидом, у неее одна рука, ребенок же должен иметь 2. Ни мама ни папа не должны затирать в ребенке ничто человеческое в общем случае.

А путаются в 2-х соснах:)

приведи пример

RTFM. А слабо обсуждать конкретно тему? Я ж не для вброса спросил.

Пишут, что это связано с default methods. Как это именно сделано - мне не слишком интересно.

Default methods allow an author of an API to add new methods to an interface without breaking the old code using it. Although it was not their primary intent, default methods also allow multiple inheritance of behavior (but not state).

На просторах ЛОРа обнаружен мальчик, воспитанный материалистическими диалектиками.

Не совсем понял, причем тут материалистическая диалектика. И почему именно материалистическая, а не идеалистическая?

Human father1;
Human father2;

Тонко!

Нарэтэфээмил только про интерфейсы. Никакого extends Class1, Class2 не нашел.

Параметрического и ад-хок.

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

Чтобы обойти это в восьмой жабе сделали интерфейсы с реализацией.

Т.е. diamond problem снова с нами ;)

Как концептуально правильно надо тут выстроить иерархию? На мой вхгляд так: Ребенок наследуем от Человек Мама Папа. Мама и Папа — от Человек.

А потом заказчик говорит, что все они живут в Древнем Риме и у папы есть раб. И вы заводите класс Slave, наследуете его от Human и добавляете в Father композицией, потому, что раб папе принадлежит. Верно?

Вот я ещё не проснулся с утра, а ты меня уже почти отговорил от ООП насовсем. Потому что в реляционных СУБД 3-я нормальная форма и подобные проблемы даже не возникают :)

странная логика

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

Это больше похоже на какие-то когнитивные аномалии

Ещё немного, и мы дойдём до идеи Entity System.