Для чего до реализации класса определять интерфейс?

Question

[Павел]

Почему в книжках по многим языкам программирования (C#, Objective-C) сначала определяют интерфейс, а потом реализуют класс? Не проще ли сразу писать класс? Так ведь и кода меньше получается.


Почему интерфейс это не лишняя трата времени и строк кода?

Почему нужно сначала описать интерфейс, а потом реализовать класс?

Comments

[sankir]

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

Answer 1

[AlexanderG]

А подскажите что конкретно почитать?


Просто потрясающая книга. Охватывается большинство аспектов разработки ПО, от проектирования и выработки требования до советов по именованию переменных. Всё очень доступно разъясняется, но при этом не слишком заумно, но и не слишком упрощенно.

Answer 2

[Slayt]

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

for (Square s: squares) {
  s.draw();
}
for (Ellipse e: ellipses) {
  e.draw();
}
for (Diamond d: diamonds) {
  d.draw();
}
...

довольно неудобно, особенно если потом понадобится добавить еще фигуры. Куда лучше будет объявить общий для фигур интерфейс с методом draw() и использовать в коде именно его:

for (Figure f: figures) {
  f.draw();
}

Comments

[Monnoroch]

Ну вот, и тут этот пример… во всех книгах он, надоело уже, извините =\

[Анатолий]

Как насчет:
for (Figure s: squares) {
s.draw();
}
Где Figure не интерфейс а родитель всех геометрических фигур?

[Владимир Чернышев]

@taliban, интерфейс, по сути, вырожденный случай наследования и вопрос может звучать так «зачем перед реализацией делать абстрактный родительский класс?» :)

[Анатолий]

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

Answer 3

[Monnoroch]

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

Comments

[Monnoroch]

Да, забыл конкретный пример. Вот хотите вы реализовать поиск данных по ключу. У вас много вариантов, какую структуру данный сделать — можно массив пар, можно список пар, можно дерево поиска. И вы хотите не просто искать, а искать максимально быстро, но не знаете на ваших данных какая структура лучше.
И вы пишете их все — дабы выбрать лучшую. А потом все пробуете. И вот, чтобы каждый раз не менять во всех заголовках функций тип аргумента вы просто делаете интерфейс, обьявляющий метод V*Find(K*key), реализуете этот метод во всех структурах и пишете во всех заголовках функций, принимающих структуру поиска не саму структуру, а интерфейс, избавляя себя от работы каждый раз править название типов аргументов.
Дополнительный бонус — если через неделю ваш друг обьявит вас велосипедистом и расскажет вам о самой лучшей структуре, то вы спокойно реализуете ее, реализуете в ней интерфейс и не изменяете существующий код.

[Monnoroch]

Ах, да, и еще один бонус: вы предохраняете себя от написания в одной структуре метода Find, в другой find а в третей Search. Бывает полезно.

Answer 4

[Monnoroch]

По поводу дополнения к вопросу:
Ответ на вопрос «зачем?» тривиален: так удобнее.
А вот понять почему можно только на собственном опыте, это как почему сладкое вкусно. Сколько не обьясняй, пока не попробуешь не поймешь.

Answer 5

[Владимир Чернышев]

Кстати, не всегда это хорошая практика. Можно считать это преждевременной универсализацией и оопизацией во многих случаях, если вы точно не уверены, что понадобится несколько классов с разными реализациями, но одним интерфейсом (тестирование отдельный случай, во многом зависит от языка и инструментов, где-то мок/стаб легко создать без интерфейсов, где-то, наверное, невозможно). Вот когда понадобится, тогда и создадите, а достоверая оценка оценка вероятности понадобится или нет приходит только с опытом. Но лучше, имхо, для более быстрого его набирания лишний раз выделить интерфейс из уже реализованного класса, чем выделить сразу, а потом и не вспомнить, что зря его выделял и таскать по всему проекту без особой надобности. А когда интерфеейса не хватате, то это чувствуется, особенно в языках с сильной типизациейю.

Answer 6

[Анатолий]

Интерфейс не нужно описывать перед классом, а можно, это разные вещи. И как писали выше, Вы сами поймете когда оно того стоит а когда нет, нельзя точно сказать «вот тут делай интерфейс, а вот здесь не нужно».

Answer 7

[szKarlen]

Думаю, сначала нужно четко определить, что не всегда и не во всех случаях необходимо реализовывать интерфейс. Так, для класса Point2D абсолютно этого не надо, или же Vector2D, Vector3D.
Выше приводили пример с фигурами — однако, он показывает не это. Его предназначение — наследование в ООП (вспомним три постулата: полиморфизм, инкапсуляция и наследование).
Интерфейсы, на практике, определяются в большинстве случаев для:

1. уменьшения связности системы
2. классов (объектов), выполняющих роль по обработке данных
3. классов (объектов), следующих какому-либо паттерну программирования (репозиторий, стратегия)
4. на этапе проектирования для создания заглушек
5. для использования в юнит-тестировании

А так как Вы еще писали про C# — то вспомним и про явную и неявную реализацию интерфейса, что удобно, например в GUI.
Интерфейс — скелет, на котором строится вся система.

Answer 8

[VenomBlood]

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

На самом деле причин гораздо больше, тут советую почитать какие-нибудь книги по программированию (именно по программированию как таковому, а не по какому-то языку), там это хорошо объясняется.

Answer 9

[Alexander Kouznetsov]

Меня учили, что он нужен прежде всего для командной работы.
Допустим, что некий класс получает какой-то набор данных из БД. БД еще нет. Соответственно, описываем интерфейс и реализуем класс который тупо возвращает некий набор констант. Когда БД появится, кто-то уже реализует класс получающий реальные данные, а не заглушки. Процесс отладки тоже упрощается — проще изолировать код: пока для реализации интерфейса использовался класс А — всё работало, стал класс Б — всё сломалось.
Как-то так.

Если вы один, без ансамбля и жнец, и на дуде игрец, то смысла в описание интерфейсов становится гораздо меньше.

Comments

[Владимир Чернышев]

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

Answer 10

[ngreduce]

Как вариант — реализация нескольких интерфейсов в одном классе, не используя множественное наследование.

Answer 11

[Lihonosov]

Для тестов! JUnit и т.п. Например:
Интерфейс работы с БД
1. Реализация интерфейса для работы с Mysql
2. Реализация интерфейса для работы с MongoDB
3. Реализация интерфейса для работы с «In Memory DB»