vfabrприведенный пример может быть решен как с помощью абстрактного класса так и с помощью интерфейса вотрое на мой взгляд предпочтительнее
Обоснуй, чем предпочттельнее?
vfabrа множественное наследование имхо в 95% случаев признак неправельного проектирования
Еще один великолепный миф(с) Асприн.
Если считать абстрактный класс у которого все методы абстрактные интерфейсом (из С++) то тогда все что можно реализовать с помощью интерфейсов реализуется через множественное наследование. Но наоборот не верно. Основная причина того что множественное наследования классов отсутсвует в java это то что её не успели напистаь а для оправдания придумалим миф.

Если исходить тиз того что ЛЮБАЯ программа выполняется в машинных кодах, то тогда аналогично все что можно написать можно написать с момощью множественного наследования можно реализовать с помощью интерфейсов а также просто настучав на перфокарте машинные кода.
Но насколько изящным и красивым будет такое решение уже другой вопрос. При рассмотрении некоторые шаблоны проэктирования просто напросто решают вопрос отсутсвия множественного наследования другие вопрос отсутсвия статического вызова метода (иногда называют вызвать метод дедушки super.super)

По основному вопросу: класс подобен таблице в SQL а интерфейс VIEW. Иногда удобно работать с объектом а иногда с видом(view) на него через интерфейс. Это уже доло вкуса и эстетики.

tfинтересное, но неудачное сравнение, как ни крути класс и таблица в SQL разные вещи. как и View и interface
Ага а во что проэцируется класс при OR Mapping?

vfabr авторОбоснуй, чем предпочттельнее?

да даже только тем что интерфейсы менять нельзя (типа соглашение) :-)

только его как правило все нарушают.
vfabr
определились 1 раз и все. Абстрактный класс использовать конечно можно но врядли Вы запихнете в него какую нибуть реализацию, а если там все методы будут абстрактны то и получится по сути интерфейс так зачем это нужно?

Тем что в абстактном классе можно кимбинировать абстрактные и реальные методы а в интерфейсе нельзя.
vfabr
авторЕще один великолепный миф(с) Асприн.

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

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

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

vfabrВы наверное здесь лучше всех знаете что и как надо делать :-)

Наезд к чему?
vfabrя не буду с Вами спорить я свою точку зрения высказал. Вы высказали. Кому надо сделает выбор какой считает нужным :-)

Недавно в топиках было что Java програмист не все решает. Аналогично выбор делают за нас, под давлением общественности добавили template и перегрузку операторов для BinDecimal.
Скоро добавять я для всего остального(предполажение).
В этом отказа от множественного наследования в связи с кривым использованием решают метод головной боли отсечением головы, тоже подход но не всегда правильный.
. vfabrафтару надеюсь памагли
Могу добавить что есть еще 3-й способ стартовать поток :-)

funikovyuri Евгений Путилин
Еще один "теоретик"?

Не попал с точностью до наоборот
IMHO миф о том что множественное наследование и т.д. идет от теоретиков.
funikovyuriто что возможности множественного наследования покрывают возможности интерфейсов - это я думаю и так всем ясно. думаю всем также известны сложности с ним связанные... интерфейсы это компромисс, который позволяет решать определенный круг задач без побочных эффектов и сложностей
Зато порождают кучу других, для решения которых используются определенне шаблоны проэктирования.