Все дело в слабой связи. Давайте сделаем небольшой перерыв на кофе, и я все объясню.
Примеры написаны на Kotlin, но не используют его специальные синтаксические возможности, чтобы каждый программист мог их понять.
Что, если бы нашей кофемашины не было на кофейной станции? Что, если бы вместо этого было пустое место, и каждый раз, когда мы хотели пить кофе, нам приходилось бы конструировать машину с нуля.
В программном обеспечении все работает в миллион раз быстрее, чем на самом деле, поэтому вполне законно писать такой код:
Проблема, однако, в том, что на самом деле ни одна кофемашина не может быть построена с пустым конструктором. Хотя характеристики конструкции могут и не иметь значения, сложность конструкции, возникающая при использовании кофемашины, безусловно, будет:
Можете ли вы сказать по этому коду, что делает программист в перерыве?
Должен ли программист return работать без кофе только потому, что ему не удалось построить кофеварку? И как вообще можно было бы поговорить со всеми этими providers, прежде чем пить кофе?
Все это теперь заботы бедных programmer, которые только хотели пить ее кофе.
Но вы можете переместить все это в другой класс, который отвечает за создание кофемашины, верно?
Отличная идея. В этом и заключается суть фабричного паттерна проектирования.
Он очищает код, но рано или поздно его снова придется менять. Это потому, что мы, программисты, избалованы: нам нравится пробовать кофе из разных машин, которые не обязательно сконструированы на одной фабрике.
Итак, как видите, Фабрика откладывает сложность строительства, но не заставляет ее исчезнуть.
Ok. Итак, что вы предлагаете?
В реальной жизни изготовление инструмента и его использование - это два разных процесса, отделенных друг от друга. Человечество всегда этим пользовалось. Думаю об этом. Сконструировал ли доисторический человек свое копье незадолго до того, как собирался ударить мамонта?
Нашему программисту не нужно заниматься изготовлением кофемашины во время перерыва. Ей, конечно, не нужно привозить с завода новую машину. Кофемашина - это просто инструмент, используемый программистом для быстрого приготовления кофе, чтобы он мог вернуться к настоящей работе: написанию кода!
Хорошая теория. При чем тут внедрение зависимостей?
Внедрение зависимостей - это архитектурный подход, в котором код построения классов и их использование систематически разделяются. Как? Существует несколько техник, но один из них - инверсия зависимостей конструкции. Это означает, что конструкция CoffeeMachine не должна быть тесно связанной тому Programmer, кто им пользуется. Вместо этого: конструкция Programmer, как ни странно, должна зависеть от CoffeeMachine:
Но разве это не просто переносит конструкцию кофемашины в класс, в котором находится Программист?
Не обязательно. Возьмем, к примеру, SoftwareCompanyX, который хочет иметь aProgrammer: снова следуя принципу инверсии зависимостей, мы просто сделаем конструкцию SoftwareCompanyX зависимой от Programmer вместо того, чтобы тесно связывать конструкцию Programmer с SoftwareCompanyX:
Это здорово, потому что Programmer может легко переместиться на другой SoftwareCompany и делать там перерывы на кофе. Все, что ей нужно, - это кто-то, кто даст ей ссылку на CoffeeMachine, и она снова в деле!
Ты шутишь, что ли? В конце концов, кому-то придется все построить
Точно! Этот кто-то будет единственным, кому нужно обрабатывать детали построения для одного конкретного кластера классов. Это также будет его единственной обязанностью. Этот корень композиции известен в большинстве фреймворков внедрения зависимостей как Module.
Итак, SoftwareCompanyModule заботится о подключении всего и предоставляет внешне только SoftwareCompany.
Интересно. Так зачем мне фреймворк внедрения зависимостей?
Есть еще несколько вопросов, на которые нужно ответить:
- Кто должен создавать экземпляр модуля?
- Что, если модуль зависит от других модулей?
- Как разделить один и тот же экземпляр объекта в нескольких местах?
- А как насчет модульного тестирования?
Фреймворки внедрения зависимостей помогают справиться с этими проблемами, поэтому вы можете сосредоточиться на проблемах своей собственной предметной области, а не изобретать колесо.
Перерыв на кофе окончен. Спасибо за внимание, надеюсь, вы узнали что-то новое. Я хотел бы услышать ваши мысли и ответить на вопросы по этой теме, которые могут у вас возникнуть.
Уровень кодирования
Спасибо, что стали частью нашего сообщества! Подпишитесь на наш канал YouTube или присоединитесь к Интервью по программированию Skilled.dev.
