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

Если в интерфейсе Drawable есть метод draw, который в одном объекте рисует на экране, а в другом -- заставляет персонажа вынуть меч из ножен -- это не ООП, это шизофрения. Хотя интерфейс вызова соблюден, сигнатура правильная.

Макконнелл — Совершенный Код?
Кстати, вот в этой книжке очень даже здорово описано, почему и чего.

В теме отсутствуют слова полиморфизм, паттерн....

Истинно так. Поскольку при использовании объекта нам важно, какой результат мы получим, а не как оно там внутри реализовано.

Если же рассматривать интерфейс тупо как набор сигнатур -- мы получаем бесполезную хрень. Так, один добрый, лично мне известный гражданин спаял клон ZX-Spectrum, за нехваткой комплектующих использовав идентичные разъемы и для видеовыхода, и для питания. Совместимость по сигнатурам была отличная. Но вот при подаче 220В на видеовход компьютер решил, что это нарушение его контракта и сдох нафиг. :)

Добавлено через 1 минуту
...Liskov substitution principle

Crazy: Вот именно что нет :)
Интерфейс, задумывлася именно для того, что значит это слово, и вариант с омонимами как раз таки и есть демонстрация интерфейса. Это и есть прямая его функция - обеспечить совместимость, не зависимо от контекста, слово draw не вызовет ошибки. То, что в каком-то контексте данное слово будет бессмысленным - это уже вне полномочий и обязаностей интерфейса. Непосредственно для этого случая можно найти несколько применений, когда draw нужно не зависимо от значения, обработать одинаково, ну, хотябы спелчекер.
Представте, что мы тестируем какое-то утверждение на истинность. К сожалению, я не знаю точных аналогов в русском языке, но для того, чтобы рассмотреть истино ли утверждение, нам нужно сначала удостоверится, что оно valid, потом, что оно sound, и только потом, мы можем судить о его истинности (это если мы говорим о дедукции). Так вот, по аналогии, интерфейс, это средство позволяющее судить о том, что утверждение valid + sound. Или, правильнее сказать, если мы описываем взаимоотношения между двумя объектами, то интерфейсу достаточна та же мера корректности, которая нужна для того, чтобы сделать вывод о применимости объекта к контексту. Интерфейс не гарантирует полной корректности. Т.е. если вы ожидали, что в электророзетку можно воткнуть исключительно электроприборы, то, очень хорошо, что у вас нет маленьких детей, или вам сильно повезло, и ваши дети не пытались воспользоваться интерфейсом розетки в не предвиденных вами целях.

ЗЫ. Java не единственный православный вариант ООП, есть и другие. Мне, например, ближе CLOS, в котором нет специальных интерфейсов на уровне системы. Вместо этого, слово "интерфейс" используется по прямому назначению, например, интерфейс с базой данных, интерфейс с отладчиком и т.п. - это к реплике о том, что значат интерфейсы в ООП.

Это из GoF :)
не читал еще..

Т.е. описанные мной две реализации Drawable Вы находите нормальными и в своем проекте могли бы так сделать?

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

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

Спасибо, у меня более нет к Вам вопросов.