Примечание. Этот пост является частью серии постов о принципах SOLID для разработки программного обеспечения (в частности, на JavaScript). Все их можно найти по следующим ссылкам:
1. Единая ответственность
2. Открыто-закрыто
3. Подмена лисков
4. Разделение интерфейса »
5. Инверсия зависимостей
Принцип внедрения зависимостей гласит, что высокоуровневый код никогда не должен зависеть от низкоуровневых интерфейсов, а вместо этого должен использовать абстракции. Все дело в развязывании кода.
Не следишь? Я не виню вас, но это удивительно просто.
Допустим, у нас есть часть программного обеспечения, которое запускает интернет-магазин, и в этом программном обеспечении один из классов (PurchaseHandler
) обрабатывает окончательную покупку. Этот класс может взимать плату с кредитной карты пользователя и делает это с помощью PayPal API:
Проблема здесь в том, что если мы перейдем с PayPal на Square (другой платежный процессор) через 6 месяцев, этот код сломается. Нам нужно вернуться и заменить вызовы API PayPal на вызовы Square API. Но кроме того, что, если Square API хочет разные типы данных? Или, возможно, он хочет, чтобы мы сначала «подготовили» платеж, а затем обработали его после завершения подготовки?
Это плохо, и поэтому вместо этого нам нужно абстрагировать функциональность.
Вместо того, чтобы напрямую вызывать PayPal API с нашей платежной страницы, мы создадим еще один класс с именем PaymentHandler
. Интерфейс для этого класса останется неизменным независимо от того, какую базовую платежную систему мы используем, даже если эти две системы совершенно разные. Нам все равно нужно будет внести изменения в интерфейс PaymentHandler
, если мы изменим платежную систему, но наш интерфейс более высокого уровня останется без изменений.
Теперь вы можете смотреть на это и думать: «Но подождите, это гораздо больше кода», и вы будете правы. Как и многие принципы SOLID (да и принципы объектно-ориентированного программирования в целом), цель заключается не столько в том, чтобы писать меньше кода или писать его быстрее, сколько в том, чтобы писать лучше код. Вышеупомянутое изменение сэкономит вам дни или, может быть, даже недели в будущем, в обмен на то, что вы потратите на это несколько часов сейчас.