Инверсия зависимостей — PHP: Полиморфизм

Каждый раз, когда внутри функции создается объект, появляется зависимость функции от класса этого объекта. Другими словами функция жёстко завязана на работу в паре с конкретным классом. Есть формальный способ, позволяющий легко проверить насколько ваш код завязан в узел. Возьмите любую функцию и мысленно представьте, что вы переносите её в другой проект. Сколько за собой она потянет зависимостей (а те в свою очередь свои зависимости)? Если перенос функции потребует переноса большого количества кода, то говорят, что в коде высокая связанность.

Для развязки кода придуман даже специальный термин: Принцип Инверсии Зависимостей. Ещё он известен как DIP из SOLID. Вот его формулировка:

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

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

Кроме того, DIP говорит о завязке на интерфейсы вместо классов в сигнатурах функций. Об этом мы поговорим позже, когда закончим с основными понятиями.

Было:

<?php

function doSomething()
{
    $logger = new Logger();
    // some code
}

Стало:

<?php

function doSomething($logger)
{
    // some code
}

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

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

Почти всегда, когда речь идёт про инверсию зависимостей, рядом появляется термин "инъекция зависимостей". В то время как DIP говорит о модульности, инъекция зависимостей говорит о конкретных способах её достижения. О том каким образом можно передать зависимости в код использующий их. Всего есть три способа инъектировать зависимости:

• Передать их как аргументы функций или методов. Именно этот способ мы использовали до сих пор.

  <?php
  
  $app->get('/', new Logger());
  

• Через конструктор в тех ситуациях, где используются объекты.

  <?php
  
  $app = new Application(new Logger());
  

• Через сеттеры. По возможности лучше этот способ не использовать. Он связан с изменением объектов и нарушением целостности (подробнее было в курсе по объектно-ориентированному дизайну).

  <?php
  
  $obj->setLogger(new Logger());
  

Как видите, за громким термином скрывается очень простая штука – передача параметров. С другой стороны, термины позволяют понять больше смысла без необходимости знать дополнительный контекст. Главное не увлекаться, а то можно превратиться в архитектурных астронавтов.

Дополнительные материалы

1. Dependency Injection

---

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты