Объяснение интерфейсов в PHP

Как и когда использовать интерфейсы в PHP? С примерами.

Используете ли вы интерфейсы при создании веб-приложений на PHP? Если нет, надеюсь, вы начнете, прочитав эту публикацию.

«Интерфейсы позволяют вам определять поведение объекта, не беспокоясь о деталях реализации»

Я занимаюсь программированием много лет, но только недавно я оценил силу интерфейсов в программировании.

Раньше я ими не пользовался — в основном потому, что не понимал их.

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

Сегодня я вообще не использую абстрактные классы! Я писал об этом в предыдущей публикации:

В то время я не мог понять, какую ценность интерфейсы приносят приложению. Ведь никакого кода они не несут.

Самое важное, что нужно понять об интерфейсах, это то, что они представляют собой не что иное, как обещание того, как код БУДЕТ ПОВЕДЕН, а не то, как он точно «будет работать».

Вы чувствуете эту тонкую разницу? Можно построить вокруг этого обещания без фактического кода. Будет проще, если я покажу это в качестве примера.

Вам поручили написать новый функционал, позволяющий экспортировать заказы в файл XML.

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

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

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

Должны ли они ждать, пока вы реализуете весь функционал? Благодаря интерфейсам их не нужно ждать. Мы уже можем написать контроллер:

и издевайтесь над функциональностью:

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

В Symfony мы можем указать, что это реализация по умолчанию для использования при запросе службы OrderExporterInterface:

services:
    App\Services\OrderExport\OrderExporterInterface:
        '@App\Services\OrderExport\XmlOrderExporterMock'

В Laravel мы можем сделать то же самое в Service Provider:

$this->app->bind(
    OrderExporterInterface::class,
    XmlOrderExporterMock::class
);

На следующий день вы обнаружили, что доступна библиотека сериализатора. Давайте воспользуемся им для создания финальной реализации и просто заменим в сервисном контейнере фреймворка:

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

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

С дополнительной реализацией, которая станет основной:

Мы можем легко связать эту реализацию в сервис-контейнере, то есть в Laravel:

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

Программируйте интерфейсы, а не реализации!

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

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

Я убедил тебя? Будете ли вы любить интерфейсы? Обязательно ознакомьтесь с другими моими публикациями на DevGenius о том, как лучше писать код: