MAULERbooby,


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

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

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

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

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


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

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

MAULER А методы взаимодействия с конечным пользователем "торчали наружу" через public.
В этом случае - потребовалась бы перекомпиляция?

Интерфейс в любом случае public. По крайней мере по отношению к использующему коду.
Вот есть процедура сортировки специфически ночных горшков.
Если писатель класса горшков меняет и реализацию и спецификацию метода сравнения сравнения, добавляя к параметру МестоПроисхожденияГлины параметр ЗаводПроизводитель или НомерСмены, то нет шансов после такого изменения не перекомпилировать и код сортировки вместе с изменениями в классе горшков.

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

MAULER,
авторТакое В ПРИНЦИПЕ возможно?

Да. Так делают (пусть это будет утиная типизация в рамках данного разговора).
А в некоторых средах (языках программирования) именно что-то такое либо рекомендуемый,
либо вообще единственный способ реализовать идею интерфейса.
Я думаю, что во внимание следует принимать как минимум следующие два обстоятельства:
а) в какой момент желательно получение ошибки - в момент компиляции кода, или в момент времени выполнения кода.
Закладка на явно объявленные интерфейсы определенно позволят провести кодирование так, чтобы ошибки вроде отсутствия
подходящей реализации выявлялись на этапе компиляции.
Наивная реализация этой идеи в java однозначно ведет к ошибке времени выполнения.
Не наивная может иметь смысл, но не будет бесплатной ни в смысле порождения (нескольких) дополнительных оберток для поддержки не наивности, ни в смысле накладных расходов на вызовы сквозь полученные конструкции.

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

Идея интерфейса в архитектурном плане, с моей точки зрения, вообще один из самых краеугольных камней программирования.
Не владея ею свободно, вы вообще не понимаете, что вы делаете как программист.
Если продолжать строительно-архитектурные сравнения, то получится как-то так: 2 подхода к архитектуре.
1) Пусть дана планировка дома. Размеры помещений и их техническое оборудование заранее известны.
Это подход со статически заявленными интерфейсами. Кухня может быть только в этом помещении, потому что в него подведена вода и сделана вытяжка. А спальню разумно организовать именно в этом, потому что оно самое тихое и дорога именно из этой комнаты в туалет не загорожена несущим столбом, вокруг которого с делан коридор.
Использование статических интерфейсов производится архитекторами и инженерами, заранее планирующими и продумывающими
строительство дома заданных характеристик.


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

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

Сергей Арсеньев,

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

Petro123...
эк вас торкнуло)). Это перебор.
Свободно владеть, это значит знать где надо и не надо).

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

В связи с вышеизложенным докладываю, что не представляется интересным - как Вы сами себя называете ( даже если Вы называете себя программистом).

Интересным представляется вот что - на каком основании Вы ожидаете, что другой программист признает Вас за такового,
если Вы даже не претендуете не только на представление шедевра, но и даже на понимание того, где надо применять ту или иную специфическую технику, а где не надо?

Petro123Двайте вы перечислите недостатки interface. А то вы разочаруете...)

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

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

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

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