Смысл интерфейса (не GUI) и зачем он вообще нужен?
Здравствуйте!
Прочитал пару тем, в итоге сделал на основе прочитанного вывод, что интерфейс нужен для своеобразного обязательного каркаса класса, который этот самый интерфейс реализует.
Т.е. создавая класс, и реализуя интерфейс, разработчик обязан определить поля/свойства/методы интерфейса в классе.
Но я тут задался вопросом целесообразности данного решения. Что нам мешает изначально на стадии планировки классов, включить в них определенные поля/свойства/методы не прибегая к интерфейсам?
На ум лишь приходит один вариант целосообразности, что разработка ведётся группой людей, и вот как-раз таки интерфейс обязует проектировщиков различных классов придерживаться некого стандарта в структуре классов.
Т.е. могу сделать вывод, что интерфейс в сущности своей, предназначен скорее для удобства и организации в структурах различных классов, т.е. дать им общее, но реализуемое в каждом по своему, при этом, обязать реализовать именно все, что указано в интерфейсе.
Надеюсь, вопрос понятен, и возможно я сам на него и ответил, но все же, хочу быть уверенным в том, что мои выводы верны, дабы в будущем не попасть в нелепую ситуацию.
Если мои доводы неверны, прошу грамотно объяснить смысл и область применения интерфейсов.
Например, есть интерфейс, описывающий оружие, (урон, тип урона, объем боезапаса, тип боезапаса), и есть классы, описывающие различные виды оружия, но в тоже время они обязаны иметь этот интерфейс, для своего же описания.
Интерфейс - иной уровень абстракции. Это более продвинутое программирование на уровне что надо сделать, а не как надо сделать.
Как использовать библиотеку? Как связать две программы, два разных куска когда? Как заложить гибкость в проект? Как предусмотреть модернизацию программы? Надо использовать интерфейс.
Один из распространенных кейсов - это использование интерфейса как обобщенного типа данных для разных классов.
Например, есть интерфейс "Фигура", в котором есть два метода - "посчитать площадь" и "посчитать периметр".
Есть классы, реализующие этот интерфейс - квадрат, круг, треугольник, трапеция.
И где то вам нужно хранить что то вроде "текущая фигура" по смыслу - вот вы можете и использовать "Фигура" как тип данных.
"Например, есть интерфейс "Фигура", в котором есть два метода - "посчитать площадь" и "посчитать периметр".
Есть классы, реализующие этот интерфейс - квадрат, круг, треугольник, трапеция."
Frip, классический пример для объяснения ООП и наследования просто. И достаточно понятный. Можно найти и из другой предметной области примеры.
У этого примера есть вторая сторона - ЛЮБАЯ фигура имеет площадь и периметр. Поэтому ЛЮБАЯ фигура реализует эти методы. И т.к. достаточно сложно дать универсальные формулы - то базовым классом тут не обойтись.
GavriKos, почему в данном случае мы не можем сделать абстрактный класс фигура и определить в нем два абстрактных метода? Почему лучше использовать интерфейсы? Тоже часто задаюсь этим вопросом.
Павел, смотря что за язык уже ) Отвечу только со стороны c#. Потому что абстрактный класс в данном случае избыточен - если в нем только 2 метода без реализации. А множественного наследования нет - потом могут быть трудности. Поэтому абстрактный класс нужен тогда, когда только часть методов не содержат реализации и/или есть поля класса обязательные.
Павел, Разница между интерфейсом и абстрактным классом в одном - в абстрактном классе могут быть реализованы в том числе и не астрактные методы.
Например, методы "посчитать площадь" и "посчитать периметр" будут абстрактными т.к. имеют разную реализацию, а то, что будет иметь общую реализацию для дочерних классов можно выделить в не абстрактные методы.
Допустим, наши фигуры в программе где-то отрисовываются, и у всех будет метод "стереть" с одинаковой реализацией. Вот он и будет в этом классе не абстрактным.
Процитирую отсюда https://ru.stackoverflow.com/questions/235352/Отли... (дельный пост):
"В некоторых языках (С++) специального ключевого слова для обозначения интерфейсов нет.
Можно считать, что любой интерфейс — это уже абстрактный класс, но не наоборот."
Простой пример. У вас есть какая то программа которая должна передавать отчет. Сегодня вы реализовали класс с сохранением в файл, а завтра вам надо будет переслать этот отчет другим способом. И каждый раз будете писать новый класс переписывая логику программы? Зачем. Когда создается интерфейс и при передаче отчета куда либо будет использоваться метод интерфейса. А вот как уже он будет реализован это дело десятое. Главное, что метод для передачи нужных данных будет четко задан за счет интерфейса.
Интерфейс это четкий набор методов для реализуемого его класса или структуры, требуемый в программе. И дело тут не в команде программистов. Вот один из паттернов в котором применяются интерфейсы, где вызывается конкретный метод а за его реализацию отвечает совсем другая часть программы.
но ведь мы изначально можем реализовать набор методов в классе и структуре, не прибегая к интерфейсу?
Пример для меня, увы не простой, а какой-то смутный и запутанный, увы
Frip, ну ок, вы можете, а если вам нужно написать УНИВЕРСАЛЬНЫЙ код для других программистов? а у всех свои системы и свои классы, просто отдайте им интерфейс и они под него напишут решения
Frip, На самом деле вы почти правильно ответили сами же на свой вопрос.
Т.е. могу сделать вывод, что интерфейс в сущности своей, предназначен скорее для удобства и организации в структурах различных классов, т.е. дать им общее, но реализуемое в каждом по своему, при этом, обязать реализовать именно все, что указано в интерфейсе.
А терзающие вас сомнения со временем уйдут. Увидите больше проектов, напишите сами. Вообщем с опытом все понимание придет.
Если не видели вот это видео, посмотрите. Возможно вы найдете подтверждение или опровержение вашему представлению об полезности применения интерфейсов.
Поставил + многим, и добавлю.
Прочитайте про SOLID, букву D.
Вы ничего не должны делать просто потому что так делают другие. Но вам желательно это понять, если хотите писать не домашние пет проекты а чуть более сложный софт который годами будут поддерживать множество людей.
Инверсия и полиморфизм это очень важная тема в разработке ПО и ООП. На этом завязано много паттернов, принципов.
GOF, SOLID, GRASP.
Вы даже тесты не сможете написать без интерфейсов.
Все это придумано не для того что бы вам голову морочить, это результат работы многих программистов которые десятилетия шли к ним самстоятельно.
Т.е. могу сделать вывод, что интерфейс в сущности своей, предназначен скорее для удобства и организации в структурах различных классов, т.е. дать им общее, но реализуемое в каждом по своему, при этом, обязать реализовать именно все, что указано в интерфейсе.
Это задача абстрактного класса, а не интерфейса. Интерфейс же в первую очередь предназначается для описания взаимодействий между классом и клиентским кодом. Он описывает функциональные возможности который должны быть у класса что бы клиентский код корректно работал.
Т.е. могу сделать вывод, что интерфейс в сущности своей, предназначен скорее для удобства и организации в структурах различных классов, т.е. дать им общее, но реализуемое в каждом по своему, при этом, обязать реализовать именно все, что указано в интерфейсе.
Надеюсь, вопрос понятен, и возможно я сам на него и ответил, но все же, хочу быть уверенным в том, что мои выводы верны, дабы в будущем не попасть в нелепую ситуацию.
Если мои доводы неверны, прошу грамотно объяснить смысл и область применения интерфейсов.
Ваши выводы неверны. Суть в том, что интерфейс нужен не для удобного описания какого-то класса, а в первую очередь для клиента этого класса, а также контекста, в котором клиент пользуется интерфейсом. Когда вы создаете интерфейс, вы должны думать не о классах, которые его реализуют, а классах, которые будут использовать этот интерфейс.
Интерфейс позволяет переключаться между реализациями, когда меняется контекст, при этом клиент интерфейса от этого контекста не зависит, можно сказать, что интерфейс позволяет отгораживаться от переменчивого контекста. А обязательство реализации требуется для того, чтобы гарантировать клиенту интерфейса, что он получит нужные данные.
