OUбыстро, обратно к учебникам и будет вам счастье
- думаете интерфейсы нужны именно для "кривого" множественного наледования? Боюсь Вы набрались этого из тех самых "учебников". Наверняка в своем коде Вы интерфейсов не используете (только готовые) - я прав?

OUвы все еще хотите продолжать свой глупый спор о невозможности использования interfaces для эмуляции multiple inheritance?
- Вы так и не поняли, что речь идет не о том, чтобы с помощью интерфейсов эмулировать множественное наследование о чем уже высказались в предыдущих топиках (Вы своей схемой лишний раз подвердили что получается это необычайно криво). Мне хотелось отметить что Вы пытаетесь использовать интерфейсы не по назначению. У многих авторов (видимо пытающихся перенести опыт программирования C++ на Java) можно встретить тезис о том что интерфейсы в Java предназначены для обхода отсутствия множественного наследования. Зачем разработчикам языка сначала лишать его множественного наследования, а потом через Ж. его обходить интерфейсами? Вдумайтесь в само слово "интерфейс", оцените красоту идеи, и не используйте их ни для чего иного кроме приведения типов. А если Вам необходима функциональность нескольких классов родителей применяйте вложенные классы.

2 OU
Kachalov OUдостижение эффекта multiple inheritance через использование interface всетаки достаточно эффективный, безопасный и элегантный подход.
- использование интерфейсов не является альтернативой множественному наследованию, сходство только визуальное - можно через запятую несколько интерфейсов перечислить. Вы не правильно понимаете роль и предназначение интерфейсов.
- не хочется собачится, возможно я резковато высказался, - приношу свои извинения за тон, но мне не кажется что для реализации множественного наследования (вопрос нужно ли множественное наследование предлагаю не трогать вообще, так это личное дело каждого программиста, мне например, не нужно) надо (заметьте не можно, а надо) использовать интерфейсы. Т. к. использование интерфейсов приводит в данной задаче к громозкому коду (не элегантному, не эффективному), в частности в приведенной OU схеме мы видим 3 класса и 3 интерфейса (хотя Child лишний), итого 5-6 файлов - это что элегантный и эффективный код? По безопасности тоже може проехаться - из Вашей схемы не очевидна реализация методов наследника, т. е. не факт, что методы наследника имеющие ту же сигнатуру, что и методы родителей, имеют то же тело, иначе говоря есть хороший повод накосячить. Более того в Вашем случае они точно будут иметь другое тело и лишь имитировать функционал родителей, т. е. возможно от тупого переписывания методов Вы избавились, но это множественным наследованием не назовешь. Прежде чем городить такой код желательно выяснить зачем Вам множественное наследование (МН)? Если МН Вам необходимо для получения функциональности нескольких родителей, мне кажется, заметно проще использовать вложеные классы (этот тезис Вы упорно игнорируете). Случай когда Ваша схема необходима - случай приведения типов, где наследник должен приводиться к типам нескольких родителей, а если разобраться по существу: класс Softwarer и SoftwarersMother реализуют один и тот же интерфейс Mother, но при этом Softwares никак не связан с SoftwarersMother, т. е. SoftwarersMother не является родителем для Softwarer, аналогично с веткой Father. Если избавится от шелухи Ваша диаграма выглядит так:

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

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