В чем практический смысл использования интерфейсов в PHP?

Question

[Роми]

Допустим, я не использую в коде конструкции типа

function someFunc(SomeClass $someObj) 
{ 
...

и получается, что для меня практическая ценность интерфейсов равна нулю?

Пытаюсь сейчас разобраться в нюансах ООП, и некоторые вещи - не очевидны.

В чем основной смысл интерфейсов?

Comments

[Роми]

пример кода, который я привел - использует DI, а когда я активно использую DI, интерфейсы могут иметь практический смысл, ибо я могу их внедрять вместо реализующих классов (насколько я понял).

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

я пытаюсь узнать теперь, есть ли еще какие-то смыслы в применении интерфейсов?

это как-никак - сущность ООП, и зачем-то ведь она нужна?

[dmitriy]

возьми PSR/LoggerInterface и Monolog
подумаю для чего нужны, эти классы, да и PSR в целом

Answer 1

[Gennady S]

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

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

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

В-третьих, продуманный интерфейс позволяет в большей степени создавать взаимозаменяемые реализации — конечные классы. Тот, кто использует интерфейс при разработке класса обязан разработать все обязательства интерфейса.

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

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

Добавлю, к слову, о внедрении зависимостей. Действительно, этот подход может использоваться и без интерфейсов, тот факт, что инверсия управления и внедрение зависимостей используются чаще всего с интерфейсами — своего рода совпадение. Хороший пример: фреймворк Yii 2 или библиотека Pimple, там в качестве маркеров для внедрения зависимостей часто используются произвольные (или основанные на иных соглашениях) строки. Это к тому, что DI — необязательно самый яркий пример использования интерфейсов (хотя и более ценный, чем другие варианты).

Answer 2

[Дмитрий Кузнецов]

А где вы тут интерфейс собственно увидели?

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

Т.е. вы создаёте некий класс, в котором будут предопределены некие методы, которые будут вызывать в обязательном (вроде как) порядке. Т.е., если в интерфейсе есть метод needCall(), то и в классе, где подключён интерфейс (через implements) нужно будет вызвать его.
https://www.php.net/manual/ru/language.oop5.interf...

Comments

[Роми]

спасибо кэп :)

но я о другом.

пример кода, который я привел - использует DI, а когда я активно использую DI, интерфейсы могут иметь практический смысл, ибо я могу их внедрять вместо реализующих классов (насколько я понял).

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

я пытаюсь узнать теперь, есть ли еще какие-то смыслы в применении интерфейсов?

это как-никак - сущность ООП, и зачем-то ведь она нужна?

[Hemul GM]

Роми, в других языках есть ряд вещей, которые реализуют или ограничивают интерфейсы

Answer 3

[SagePtr]

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

Comments

[Роми]

так я и так могу это сделать, если пример из сабжа

public function someFunc(SomeClass $someObj) 
{ 
...

заменю на

public function someFunc($someObj) 
{ 
...

собственно об этом и был вопрос :)

[SagePtr]

Роми, во втором случае туда можно будет что угодно протолкнуть. А весь смысл в объявлении типов параметров - как раз чтобы не допустить такой ситуации.

[Роми]

SagePtr, это я понимаю :) Но на практике я пока не сталкивался с ситуациями, когда тайп хинтинг действительно был бы нужен. Я не понимаю чего на этом все так упарываются))