Kachalov в приведенном примере если требуется дефолтная реализация метода, Вам нужен не интерфейс а абстрактный класс, причем не полностью абстрактный
Я как раз и пытаюсь показать, что граница между этими понятиями надумана. Представьте себе следующую последовательность событий: изначально я реализовал интерфейс с методами getCount и getObject; это интерфейс, не так ли? Затем я добавляю в него getIcon - при этом интерфейс остается интерфейсом - понимаю, что для него была бы удобна дефолтовая реализация - и только из-за этого вроде_бы_концептуальное_понятие "интерфейс" вдруг меняется на нечто другое. Так выходит при Вашем строгом понимании "интерфейса".

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

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

KachalovИнтерфейс представляет собой "спецификацию" класса, необходимую для приведения типов и гарантирующую наличие требуемых методов (java.lang.Runnable) или сигнализирующую что класс удовлетворяет некоторым требованиям (java.io.Serializable), а абстрактный класс представляет собой частичную реализацию - "полуфабрикат", на основе которого легко построить что то новое опираясь на чужой код.
По большому счету (с точностью до формулировок) я с этим согласен. Вопрос не в конкретном синтаксисе, а в предназначении, в применении того или иного класса-интерфейса. Обратите внимание, здесь нет принципиального требования отсутствия реализации в интерфейсе; от того, что мы добавим реализацию getIcon в пример выше, применение MyModel как "спецификации, необходимой для приведения типов и гарантирующей наличие" ничуть не убудет. Собственно, применение останется ровно таким же.

Kachalov с точки зрения програмирования на Java случай полностью абстрактного класса представляется бессмыслицей не имеющей практического значения.
Безусловно. По той причине, что в этом случае разумнее объявить этот абстрактный класс интерфейсом и не связывать себя ограничениями единонаследия.

Kachalov Кстати Вы реально используете полностью абстракные классы?
Каждый раз, когда использую интерфейсы :) Если не считать этого, сходу вспоминаю единственный случай, класс TAbstractStep - это "шаг тестирования" в моем автотестере.

Kachalov- кстати, разница между интерфейсом и классом у которого все методы абстрактные, с точки зрения Java, более существенна. Любой класс является наследником от java.lang.Object
Если помнить об этом, то "полностью абстрактных классов" в Java, как впрочем и в Delphi, вообще не бывает - поскольку методы, унаследованные от Object/TObject, вполне себе конкретные. Но я полагаю, это малосущественная деталь.

Kachalov- а я пытаюсь доказать обратное :)
Вот и определились :)

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

Таким образом, если вспомнить пример с MyModel и рассмотреть его предполагая наличие в языке множественного наследования, дискуссия упирается в следующий вопрос: добавление реализации getIcon - принципиальное изменение или нет?

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

KachalovКогда Вы создаете интерфейс Вы создаете "спецификацию", когда Вы создаете абстрактный класс Вы делаете "запас на будущее". Мне кажется что разница между "консервами" и "стандартом на консервы" довольно велика (извините за идиотские аналогии, но они, на мой взгляд, хорошо отражают идею).
Я нисколько не против аналогий, сам их активно использую. Данная конкретная представляется мне не совсем верной, не совсем удобной для рассуждений, но не более того (она безусловно образна и хорошо раскрывает Вашу мысль).

Если Вы не против, давайте проведем маленький натурный эксперимент. Я показываю кусок кода, а Вы скажите, это "консервы" или "стандарт на консервы", и почему именно:


P.S. Мне действительно интересно, появится ли на этом сайте когда-нибудь качественная подсветка синтаксиса, или нет.

KachalovКроме того обсуждение Java-интерфейсов на примере другого языка заведет нас в неведомые дебри :)
Хм. Я до сих пор полагал, что мы обсуждаем концепцию вообще, а не применительно к Яве. Имхо обсуждать множественное наследование "применительно к Яве" глупо, его здесь просто нет.

Kachalov- из интерфейса класс точно не сделаешь
Why?

Kachalovа разница все таки принципиальная.
Где? Если в Java - безусловно. Но представьте язык, где есть множественное наследование; какая принципиальная разница там?

Kachalov- извините, но если можно, примерчик на Java
Хм. Попробую; проблема в том, что я уже успел подзабыть синтаксис Явы. Будет примерно так:


Kachalov а главное не помню есть ли в нем такое понятие как интерфейсы?
Есть.

он жеСкажу лишь, что в Java все параметры передаются по ссылке
В смысле, как в Фортране? Странно, если я успел это забыть. Хотя наверное бывает.

он жеВот уж не знаю, как в Фортране.
Именно что все передается по ссылке. С этим связан классический прикол - можно было сделать примерно так:


и в результате в вызов sub2 параметром передавалась десятка.

он жеПередаются по ссылке все кроме примитивных типов
Ээ, нет. То, что Вы говорите - это передача по значению. Просто для "непримитивных" типов значением является ссылка.

он жеЛично мне привычнее считать, что
Я понимаю. Вопрос в том, к каким последствиям это приводит.

Если смотреть на ситуацию "как она есть", то достаточно трех концепций: двух общих - "объект есть указатель на объект" и "манипуляции со String приводят к появлению нового String-объекта" - и одной с параметрами - "параметры передаются по значению". Этого достаточно, чтобы понимать все возможные ситуации.

У Вас же получилось так, что Вы описали три правила только для параметров:

- примитивные типы передаются по значению
- непримитивные кроме String передаются вроде как по ссылке
- String передается скорее по значению

Две общих концепции по-прежнему необходимо помнить, итого пять, да еще помнить, что вторая-третья из частных концепций верны условно. Усложнение на пустом месте.

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