Для чего все-таки нужны интерфейсы?

Question

[Paul Fawkes]

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

Comments

[EVGENY T.]

Суть в том, чтобы писать универсальный код.

Например интерфейс Clickable. Все кликабельные объект его могут имплементировать. И эти объекты могут быть очень разные: кнопки, фоточки, ссылки. Ты можешь спокойно обрабатывать клик в каждом их них, но вдруг тебе нужно одинаковое поведение всех элементов на правый клик. Писать в каждом классе одинаковые обработчики - плохо. Зато можно обойтись одним универсальным методом:

void clickRight(Clickable clicked) {
message("Right on " + clicked.toString());
}

[Amffore]

а почему нельзя этот метод создать так же в разных классах??

Дублирование кода

Answer 1

[kova1ev]

Представь у тебя есть какой-нибудь метод, который принимает в агрументах объект, например, типа User
doSomething(User user)
Ты можешь передавать в этот метод любой объект типа User или объекты классов, наследующих User.
Но можно сделать еще гибче, например описать некий интерфейс UserInteface и указать в определении метода его:
doSomething(UserInterface user)
Теперь ты можешь передавать в метод объект любого класса, который реализует интерфейс UserInterface.
Разумеется, изначальный класс User из этого примера тоже должен реализовывать этот интерфейс.

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

И, как уже написали выше, один класс может реализовывать несколько интерфейсов.

Answer 2

[Рональд Макдональд]

Костыль для множественного наследования.

UPD через день: много бугурта из-за слова "костыль". Хорошо, не костыль, а фича и удобная примочка, облегчающая написание программ на C#. Простити меня, пожалуйста :(

Comments

[nrgian]

Да какой это костыль.
Вполне себе полезная вещь.

Как пример, есть и в других языках - в Java, где наследование множественное имеется; в Go, где классов вообще нет.

[Михаил]

nrgian, сейчас бы для такого вопроса go приплетать. Там вообще интерфейсы хуже всего реализованы (ИМХО)

[nrgian]

makarychev13,

сейчас бы для такого вопроса go приплетать. Там вообще интерфейсы хуже всего реализованы (ИМХО)

Что-то конкретное имеете ввиду?

Имхо, интерфейс вещь настолько простая или, даже можно сказать, примитивная, что сделать там что-то лучше или хуже - невозможно.

[DevMan]

о чем вы спорите вообще? очевидно же, что автор ответа либо не шарит в програминге, либо неудачно набросил на вентилятор.

[Рональд Макдональд]

DevMan, «О чем вы спорите по существу? Очевидно же, что нужно перейти на личности!».

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

[d-stream]

Костыль для множественного наследования.

на самом деле - нет. конечно было бы интереснее иметь и мн и интерфейсы, но это надо выдумывать свой язык.

[#]

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

ps но да - это его назначение, но и не единственное

Answer 3

[Иван Воробей]

Ремонтируем подводную лодку: крепление винта — 16-листовая резьба с 29 дюймами (только что выдумал). Не нужно каждый раз делать новую подводную лодку - нужно заменить винт согласно характеристикам. Какой винт будет - реализация. Необходимые параметры для того, чтобы винт подошел - и есть интерфейс.

Интерфейсы скрывают реализацию в черный ящик.

Более сложный пример: интерфейс добавляет свойства-поведение классу, но не реализует. Колесо может крутиться, но чтобы поменять нипель - нужно реализовать протокол шиномонтаж: в нем бы был указатель на нипель, диаметр, тип резины и т.д. На шиномонтаже бывает много колес, но при условии что колесо реализовало протокол - мастера смогут помочь. А вот с пластиковыми колесами не помогут - нипеля нет, протокол не реализовать.

Comments

[GavriKos]

С винтом плохой пример - это просто свойство класса. Интерфейсы не диктуют свойства.

[Иван Воробей]

GavriKos, пример с колесом тоже плохой - зачем шиномонтажу протоколы, у них на входе Василий сидит.

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

[stictt]

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

[#]

по моему сложновато (уж тем более для новичка так излагать)
Рональд Макдональд и Много Знаю вполне конкретны и достаточно точны. разве что со словом "костыль" я бы не спешил соглашаться ))

[Рональд Макдональд]

#, да я уже десять раз пожалел, что так выразился :)

Answer 4

[Vitaly]

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

Вот допустим я пишу модуль, который должен стучать, по всему тому, что можно постучать. Есть у меня функция "knock(IKnockable o)" ну и соответствующий интерфейс. Клиенты, кому надо воспользоваться этим модулем, реализуют этот интерфейс в своих классах и пользуются. Но мой модуль вообще ничего не знает об клиентах, он просто работает со всем, что реализует определённый протокол взаимодействия (интерфейс). Это ещё и связанность понижает.

Comments

[Ruslan Ruslanov]

т.е. функционально они не влияют ни на что и лишь выступают в роли дополнительной абстракции для удобства разработки? или я неправильно понял что-то?

[Vitaly]

Ruslan Ruslanov, что вы имеете ввиду под “функционально не влияют“?

[Ruslan Ruslanov]

Vitaly, ну, например, наследование позволяет дочернему классу наследовать методы родителя.
а интерфейс просто определяет, какие методы и\или свойства будут в классе, который его (интерфейс) реализует?

[Vitaly]

Ruslan Ruslanov, это уже от языка зависит. Где-то, например, разделения между интерфейсом и абстрактным классом на уровне языка нет.

[Ruslan Ruslanov]

Vitaly, понятно, спасибо.