Здравствуйте. Возник вопрос, как и где на практике применяют интерфейсы. Допустим, абстрактный класс может быть удобен, когда есть общие для всех подклассов методы, но некоторые ведут себя иначе, их реализацию мы и определяем в новом классе, который наследует базовый абстрактный класс.
А как применять интерфейс и зачем? Допустим, при помощи него можно реализовывать множественное наследование, но какой в этом толк, если необходимо реализовывать все наследуемые методы? А если мне, скажем нужны не все? То есть, наследовать больше одного интерфейса нет смысла, в основном, т.к. внутренний класс получается слишком огромным, а концепция ООП напротив, стремится к уменьшению кода.
Но ведь из названия ясно, это "интерфейс", он реализует архитектуру всех реализующих его классов. Т.е. обязует их реализовать все его методы. Но опять же, зачем? Зачем этот шаблон нужен?
Вот например, реализую я интерфейс animals, в нем несколько методов, например run(), breathe(), eat(), etc. Далее, его реализует класс doge, в данном классе реализуются все методы интерфейса animals. А зачем писать лишний код? Неужели сразу нельзя определить методы без наследования?
Допустим, для чёткого следования архитектуре родительского класса. Дабы не забыть определить какой-нибудь метод. НО если я буду писать класс и не определю какой-либо метод, этот класс не заработает. И я в любом случае это пойму уже в процессе написания данного класса, потому что если я пишу класс для работы с БД, я не могу не написать метод коннекта или метод записи данных в БД.
К тому же, если я буду определять класс shark, то класс animals мне совершенно не поможет, ибо класс shark не должен наследовать метод run().
Разумеется, я не говорю что интерфейсы бесполезны. Напротив, очевидно что они необходимы, в противном случае их бы никто не реализовал. Я просто не до конца понимаю, как их использовать.
P.S. В литературе и на ютубе как правило рассказывают только о том, как они объявляются и как реализуются в рамках классов. Хотелось бы услышать ваше мнение.
P.S.S. Слышал, что множественное наследование это не лучшая практика. Это так?
Две последние буквы SOLID для вас ( https://en.wikipedia.org/wiki/SOLID_(object-orient... ). Вообще рекомендую прочитать всю эту статью, она очень дельная (+ все ссылки из секции Design and development principles). Использование этих принципов позволят писать относительно неплохой код даже без понимания (которое приходит с опытом обычно). Кстати, в этих статьях должны быть ссылки на книги по ОО-проектированию (ну в любом случае они неплохо гуглятся).
Необходимость в интерфейсах и абстрактных классах возникает в основном в больших коммерческих проектах. Использование интерфейсов позволяет понизить связанность компонентов системы (их уровень знания друг о друге), что, в свою очередь, позволяет легче модифицировать систему, работая в команде. Например пишет один программист какой-то класс для запуска задач и делает у него метод, который принимает интерфейс IRunnable (возможно с одним методом run()) и описывает контракт (правила, как метод run() должен себя вести). После этого, любому другому программисту достаточно будет реализовать интерфейс по контракту и он сможет пользоваться классом для запуска задач. При этом, класс для запуска задач вообще понятия не имеет о том что он запускает, ему важно знать, что это можно запустить, и любому другому классу нет необходимости знать, как его запускают, достаточно просто реализовать метод.
Приведу самый часто встречаемый случай в моей практике, где нужны интерфейсы.
Есть база пользователей, и у пользователя есть адрес, который состоит из нескольких полей (страна, регион, город, улица, дом, квартира, этаж и т.д.). Адреса хранятся в отдельных таблицах, но привязаны в конкретному пользователю, кстати адресов у пользователя может быть более одного, например, адрес прописки, фактический адрес проживания или адрес доставки и т.д.
Также у пользователя есть телефоны, которые тоже хранятся в отдельной базе данных, там хранится какой телефон основной, какой оператор, какая страна, есть ли подписка на рассылку SMS.
А еще у пользователя может быть должность, которая тоже состоит из нескольких полей, но зависит типа должности.
Таким образом когда создаем нового пользователя, тогда используем интерфейсы адресов, телефонов, должностей.
А разве принцип записи в БД адресов/телефонов/должностей не похож?
Допустим, создать класс или трейт с 3 методами(и реализациями этих методов) :
setAdress, setPhone, setPost. Каждый из кторых контачится к своей БД и записывает адреса, телефоны и должности. Ведь в базу они записываются единообразно.
Xveeder, Адреса и телефоны могут быть привязаны не только к конкретному пользователю, но допустим к организации. И тогда при сохранении телефона организации мы можем дополнительно сохранить контактное лицо у телефона или признак факса.
Суть именно в том, чтобы базы адресов и телефонов вообще были не связаны ни с чем. Именно потому определяют только CRUD-интерфейс для работы с ними. А вот как эти данные связываются с пользователями или организациями зависит от конкретной реализации.
Алексей, ну ведь в конечном итоге всё равно придётся писать реализацию метода. Так почему её не написать сразу и не снабдить логикой, которая предусматривает разные условия для записи в БД?
Xveeder, Вы правы, когда говорите об одном проекте, но когда делаете независимый модуль, который может применяться в нескольких проектах, тогда вам придется сделать интерфейс, чтобы при подключении модуля в любом проекте были реализованы все необходимые методы описанные в интерфейсе.
При этом, в разных проектах, реализация может быть различной. Более того, возможно, ваш отличный независимый модуль окажется настолько хорош, что вы решите его опубликовать, например, на гитхабе, чтобы другие тоже смогли воспользоваться вашим модулем. В этом случае они просто склонируют ваш модуль себе и напишут реализацию только необходимых методов, описанных в интерфейсе. Это очень удобно для всех.
Первое: интерфейсы принадлежат не уровню реализации, а уровню использования.
Что значит?
У вас есть проект самолета.
Есть транспортная компания перевозящая грузы.
Есть пассажирская - соответственно перевозящая пассажиров.
у транспортной есть некий шаблон под названием транспортное средство. Все что подпадает под этот шаблон может компанией использоваться.
У пассажирской - все что подпадает под шаблон "средство перевозки пассажиров"
Т.е. по большему счету им не важно что будет самолет или автобус.
Вы хотите, что бы ваши самолеты использовались. Вам нужно реализовать интерфейс (шаблон использования) грузоперевозчик. Для одной компании. Для пассажирской вы можете реализовать шаблон пассажироперевозчик.
Т.е. интерфейс это некая договоренность, способ использования. И он лежит не на уровне библиотеки (т.е. на уровне реализации класса), а на уровне более высокой логики. (транспортное средство)
Интерфейс становиться неким шаблоном между двумя частями системы. Он достаточно стабилен. Из этого мы получаем разделение большой системы на две части. и соответственно мы можем разрабатывать раздельно эти части, не боясь что-то нарушить в другой части.
По части использования. Интерфейсы очень широко применяются. Даже в небольших проектах. Они разбивают на части систему, что очень полезно для построения прозрачных моделей. Также это дает возможность работать нескольким людям над одним проектом (или одному. Над частями проекта)
Это дает возможность Сосредотачиваться на логике проекта, оставляя реализация на "позже" - делая простые затычки для тестирования.
В примере с животными. Есть зоопарк где животные. По большей части они работают с интерфейсом животные (кормят, ограждают и т.е.) И все что подпадает под интерфейс животное легко там содержится. Если им привезти новое животное, они его посадят в клетку, будут кормить и показывать детям. Т.е. Животное - это скорее договоренность, а не сущность. (для зоопарка)
Средний
