Чтобы зависеть от абстракции, а не от конкретного класса. Удобно делать моки при юнит тестировании. На класс можно навешать несколько интерфейсов, но нельзя унаследоваться одновременно от нескольких классов (в некоторых языках можно).
Ещё очень удобно становится писать конфигурируемый код для разных ситуаций и окружений. Например, если есть загрузка файлов, то можно её реализовать через локальную файловую систему и через AWS, и в зависимости от окружения выбирать нужную реализацию (чтобы не нагружать AWS тестовыми файлами при локальной работе). То же самое можно провернуть с отправкой писем, SMS, пуш уведомлений... Да даже все потенциальные запросы в БД можно временно подменить на фейковую реализацию, которую можно быстро написать.
Плюс к этому через интерфейсы (и полиморфизм) реализуются многие шаблоны проектирования, которые позволяют переиспользовать код при необходимости. Шаблонные методы там, стратегии, абстрактные фабрики, декораторы и прочее: что-то более полезное, что-то менее.
в моем понимании интерфейс нужен для того, чтобы задать для определенных обьектов определенную общую структуру, которой они должны следовать, но без деталей, доступных извне.
например интерфейс "Транспорт". в нем допустим есть пропертя "Количество колес". в даном случая этот интерфейс просто указывает, что любой обьект, который относит себя в транспорту (наследуется от этого интерфейса) должен иметь колеса. какое количество колес - это уже решает каждый обьект для себя, реализуя эту пропертю у себя. то же самое и с методами. например каждый "Траспорт" должен обязательно "Передвигаться" (метод), а как он передвигается (на суше, в воде, в воздухе, вперед, вверх, вниз) - это уже решает обьект.
если же есть определенное действие, которое общее для всех обьектов, то между классом и интерфейсом в цепочке наследований можно еще вставить абстрактный класс, где описать реализацию этого общего метода/проперти.
с одной точки зрения, поскольку у абстрактного класса не обязательно должна быть реализация, то можно было бы вообще заменить интерфейс абстрактным классом в этих наследованиях, но с другой стороны, в некоторых языках (например в C#) интерфейс решает проблему множественного наследования, когда один класс, один обьект должен обладать сразу несколькими разными признаками. например есть интерфейс "Растение", есть интерфейс "Дерево". и мы для класса "Береза" делаем наследование от этих обеих интерфейсов. и если например у нас будет другой класс, "Трава", то он тоже вроде как "Растение", но он не "Дерево".
так же интерфейс, как по мне, в какой то мере, помагает поддерживать целосность кода. например какой то программист А делает свою библиотеку. в свое коде он делает определенный интерфейс, наследуется от уже существующего интерфейса (который он не может поменять). программист В использует эту библиотеку и видит для доступа к обьектам этой библиотеки только эти интерфейсы. через некоторое время программист А решает изменить что-то в свое коде и обновить библиотеку. но поскольку его методы унаследованы от определенных интерфейсов, то он обязан и дальше следовать их структуре, тому же названию методов, тому же количеству и типу параметров. и когда он обновит свою библиотеку, программист В ее скачает и ему не нужно будет ничего менять в своем коде.
Чтобы зависеть от абстракции, а не от конкретного класса. Удобно делать моки при юнит тестировании. На класс можно навешать несколько интерфейсов, но нельзя унаследоваться одновременно от нескольких классов (в некоторых языках можно).
Комментарий недоступен
Ещё очень удобно становится писать конфигурируемый код для разных ситуаций и окружений. Например, если есть загрузка файлов, то можно её реализовать через локальную файловую систему и через AWS, и в зависимости от окружения выбирать нужную реализацию (чтобы не нагружать AWS тестовыми файлами при локальной работе). То же самое можно провернуть с отправкой писем, SMS, пуш уведомлений... Да даже все потенциальные запросы в БД можно временно подменить на фейковую реализацию, которую можно быстро написать.
Плюс к этому через интерфейсы (и полиморфизм) реализуются многие шаблоны проектирования, которые позволяют переиспользовать код при необходимости. Шаблонные методы там, стратегии, абстрактные фабрики, декораторы и прочее: что-то более полезное, что-то менее.
ООП программисты. Жесть
Комментарий недоступен
в моем понимании интерфейс нужен для того, чтобы задать для определенных обьектов определенную общую структуру, которой они должны следовать, но без деталей, доступных извне.
например интерфейс "Транспорт". в нем допустим есть пропертя "Количество колес". в даном случая этот интерфейс просто указывает, что любой обьект, который относит себя в транспорту (наследуется от этого интерфейса) должен иметь колеса. какое количество колес - это уже решает каждый обьект для себя, реализуя эту пропертю у себя. то же самое и с методами. например каждый "Траспорт" должен обязательно "Передвигаться" (метод), а как он передвигается (на суше, в воде, в воздухе, вперед, вверх, вниз) - это уже решает обьект.
если же есть определенное действие, которое общее для всех обьектов, то между классом и интерфейсом в цепочке наследований можно еще вставить абстрактный класс, где описать реализацию этого общего метода/проперти.
с одной точки зрения, поскольку у абстрактного класса не обязательно должна быть реализация, то можно было бы вообще заменить интерфейс абстрактным классом в этих наследованиях, но с другой стороны, в некоторых языках (например в C#) интерфейс решает проблему множественного наследования, когда один класс, один обьект должен обладать сразу несколькими разными признаками. например есть интерфейс "Растение", есть интерфейс "Дерево". и мы для класса "Береза" делаем наследование от этих обеих интерфейсов. и если например у нас будет другой класс, "Трава", то он тоже вроде как "Растение", но он не "Дерево".
так же интерфейс, как по мне, в какой то мере, помагает поддерживать целосность кода. например какой то программист А делает свою библиотеку. в свое коде он делает определенный интерфейс, наследуется от уже существующего интерфейса (который он не может поменять). программист В использует эту библиотеку и видит для доступа к обьектам этой библиотеки только эти интерфейсы. через некоторое время программист А решает изменить что-то в свое коде и обновить библиотеку. но поскольку его методы унаследованы от определенных интерфейсов, то он обязан и дальше следовать их структуре, тому же названию методов, тому же количеству и типу параметров. и когда он обновит свою библиотеку, программист В ее скачает и ему не нужно будет ничего менять в своем коде.
Комментарий недоступен