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

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

Вопрос вот в чем: что мне мешает вообще не использовать интерфейсы? Ведь внешне, в плане вызова метода у объекта класса ничего не меняется?! Что мне мешает не использовать @Override а просто сделать метод внутри класса и использовать его?

Blazkowicz,

А если два разных класса реализуют один интерфейс? А если их не два, а много?
Это я как раз понимаю. К примеру объект ob1 класса Rectangle (реализующий интерфейс) пользуется методами calculatePerimeter();
и calculateSquare();




а объект ob2 класса Circle (также реализ. интерфейс) пользуется методами с теми же названиями но уже другой "начинкой" (т.к. площадь и периметр у окружности считаются по другому)




В итоге выгода от использования интерфейса у меня какая? Да, объекты классов разные а методы называются всё также одинаково. Это наверное удобно, но причем здесь интерфейс? Даже если классов не два а много, ведь все равно реализация методов она будет своя внутри каждого класса. В чем бонус то? ))

Добрый вечер!
Смотрю ветка подросла. Параллельно в интернете нашел кучу примеров с интерфейсами, но все они то ли какие то неудачные, то ли я такой трудный.
Очень понравилось пояснение пользователя Blazkowicz с


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

Итак. Рассмотрим ситуацию к реальной жизни не имеющей отношения, но показательную (наверно) в плане понимания темы интерфейсов.

Есть группа разработчиков из Васи, Пети, Вовы и их руководителя (Team lead?)
Собирает он их вместе и говорит: ребята, появилась работа!

Заказчик ОАО "Рога и копыта" хочет от нас три класса "Окружность", "Прямоугольник" и "Треугольник". Ему надо чтобы фигуры рисовались методом рисования Draw и заливались методом заливки Fill.
К тому же, у заказчика есть собственный программист Серёжа, который до кучи сделает класс "Звезда" и так же будет использовать методы Draw и Fill.

А затем Teamlead говорит: Вася, Петя и Вова - мне всё равно как вы будете рисовать и заливать эти фигуры, сделайте только чтобы они правильно рисовались и заливались.
Ок.

Вася подумал и решил, что окружность он будет рисовать и заливать по точкам.
Петя решил, что прямоугольник он будет рисовать линиями, а заливать точками.
а Вова треугольник нарисует извращенским методом деления параллелограмма пополам.

Сказано - сделано.
Получив классы, заказчик попросил дорисовать "Звезду" у Серёжи.

Теперь, благодаря анонсированным "заголовкам" методов "Draw" и "Fill" в интерфейсе, "ОАО Рога и копыта" может рисовать и заливать фигурки двумя методами "Draw" и "Fill" абсолютно не зная особенностей рисования.

Всё ))))))

Если моя мысль верна - подвердите плз. или укажите на ошибки.

Petro123,

Приветствую.

Полиморфизм как раз в плане понимания достаточно прост: класс В наследует класс А чтобы поиметь доступный функционал класса А. Чтобы не изобретать велосипед с нуля а воспользоваться уже готовыми "наработками" класса А.

Плюс ко всему, переопределив в классе В (@Override) нужные методы класса А, реализуя их по своему, мы получаем нечто новое "по старым наработкам".

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

Так?

Blazkowicz,

Но сценариев применения интерфейсов много, это всего лишь один из них.
Вы мне один из сценариев показали ранее. Какие ещё есть?

booby,


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

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

P.S. Я заранее прошу прощения за (местами) не точную формулировку некоторых вещей. Я буду стараться выражаться правильно и придерживаться правильных "концепций". Но сейчас у меня задача понять суть. Понять причины, почему же в конкретном случае применяется интерфейс а не то или это...

Petro123,

Аффтар! Хорош теории. Давай код со звёздами, периметрами и площадями. - дык код этот давно уже есть. Он работает. Проблем нет. Т.е. я понимаю код с использованием интерфейсов, но выгода от их применения, для меня, на данный момент, пока сомнительная.

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

Blazkowicz,
Примеров мы походу не дождемся?
Мне запостить полностью пример проекта с использованием интерфейса? Т.е. выложить тексты java-модулей что я навоял? Я Вас правильно понял?