Инверсия зависимостей

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

Да, это имеет смысл. Если у меня есть класс высокого уровня, он не должен быть в зависимости от конкретного класса более низкого уровня для какого-то типа работы. Скорее, более низкоуровневые должны быть закодированы, чтобы полагаться на абстракции (такие как базовые классы, интерфейсы и т. д.).

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

Почему?

Мы уже видели отличный пример этого в предыдущей части этой статьи. Если вы использовали сервис генерации PDF-файлов и ваш код был завален new ABCService() классом, то день, когда бизнес решил использовать какой-то другой сервис, запомнится навсегда! Скорее, мы должны использовать общую форму этой зависимости (создать интерфейс для PDF-сервисов, то есть), и позволить чему-то другому обрабатывать ее экземпляр и передавать его нам (в Laravel мы видели, как сервис-контейнер помог нам это сделать).

Если вы ищете практический пример, вернитесь к той части этой статьи, где мы обсудим, как спасти наш код от необходимости зависеть исключительно от MilkyWay класса PDF.

Автор: Анкуш Тхакур 9 ноября 2020 года