Примечание. Этот пост является частью серии постов о принципах SOLID для разработки программного обеспечения (в частности, на JavaScript). Все их можно найти по следующим ссылкам:
1. Единая ответственность
2. Открыто-закрыто
3. Подмена лисков
4. Разделение интерфейса »
5. Инверсия зависимостей

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

Не следишь? Я не виню вас, но это удивительно просто.

Допустим, у нас есть часть программного обеспечения, которое запускает интернет-магазин, и в этом программном обеспечении один из классов (PurchaseHandler) обрабатывает окончательную покупку. Этот класс может взимать плату с кредитной карты пользователя и делает это с помощью PayPal API:

Проблема здесь в том, что если мы перейдем с PayPal на Square (другой платежный процессор) через 6 месяцев, этот код сломается. Нам нужно вернуться и заменить вызовы API PayPal на вызовы Square API. Но кроме того, что, если Square API хочет разные типы данных? Или, возможно, он хочет, чтобы мы сначала «подготовили» платеж, а затем обработали его после завершения подготовки?

Это плохо, и поэтому вместо этого нам нужно абстрагировать функциональность.

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

Теперь вы можете смотреть на это и думать: «Но подождите, это гораздо больше кода», и вы будете правы. Как и многие принципы SOLID (да и принципы объектно-ориентированного программирования в целом), цель заключается не столько в том, чтобы писать меньше кода или писать его быстрее, сколько в том, чтобы писать лучше код. Вышеупомянутое изменение сэкономит вам дни или, может быть, даже недели в будущем, в обмен на то, что вы потратите на это несколько часов сейчас.