- PVSM.RU - https://www.pvsm.ru -
В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.
Давайте сначала изучим пример. У нас есть ClassA
, ClassB
и ClassC
, как показано ниже:
class ClassA {
var classB: ClassB
}
class ClassB {
var classC: ClassC
}
class ClassC {
}
Вы можете увидеть, что класс ClassA
содержит экземпляр класса ClassB
, поэтому мы можем сказать, что класс ClassA
зависит от класса ClassB
. Почему? Потому что классу ClassA
нужен класс ClassB
для корректной работы. Мы также можем сказать, что класс ClassB
является зависимостью класса ClassA
.
Прежде чем продолжить, я хочу уточнить, что такая взаимосвязь — это хорошо, ведь нам не нужно, чтобы один класс выполнял всю работу в приложении. Нам необходимо разделять логику на разные классы, каждый из которых будет отвечать за определенную функцию. И в таком случае классы смогут эффективно взаимодействовать.
Давайте рассмотрим три способа, которые используются для выполнения задач по внедрению зависимостей:
Проще говоря, мы можем создавать объекты всякий раз, когда они нам нужны. Посмотрите на следующий пример:
class ClassA {
var classB: ClassB
fun someMethodOrConstructor() {
classB = ClassB()
classB.doSomthing()
}
}
Это очень просто! Мы создаем класс, когда нам это необходимо.
Преимущества
ClassA
в нашем случае) полностью контролирует, как и когда создавать зависимости.Недостатки
ClassA
и ClassB
тесно связаны друг с другом. Поэтому всякий раз, когда нам нужно использовать ClassA
, мы будем вынуждены использовать и ClassB
, и заменить ClassB
чем-то другим будет невозможно.ClassB
потребуется корректировать код и внутри класса ClassA
(и всех остальных зависимых от ClassB
классов). Это усложняет процесс изменения зависимости. ClassA
невозможно протестировать. Если вам необходимо протестировать класс, а ведь это один из важнейших аспектов разработки ПО, то вам придётся проводить модульное тестирование каждого класса в отдельности. Это означает, что если вы захотите проверить корректность работы исключительно класса ClassA
и создадите для его проверки несколько модульных тестов, то, как это было показано в примере, вы в любом случае создадите и экземпляр класса ClassB
, даже когда он вас не интересует. Если во время тестирования возникает ошибка, то вы не сможете понять, где она находится — в ClassA
или ClassB
. Ведь есть вероятность, что часть кода в ClassB
привела к ошибке, в то время как ClassA
работает правильно. Другими словами, модульное тестирование невозможно, потому что модули (классы) не могут быть отделены друг от друга.ClassA
должен быть сконфигурирован таким образом, чтобы он мог внедрять зависимости. В нашем примере он должен знать, как создать ClassC
и использовать его для создания ClassB
. Лучше бы он ничего об этом не знал. Почему? Из-за принципа единой ответственности.Каждый класс должен выполнять лишь свою работу.
Поэтому мы не хотим, чтобы классы отвечали за что-либо, кроме своих собственных задач. Внедрение зависимостей при этом является дополнительной задачей, которую мы ставим перед ними.
Итак, понимая, что внедрение зависимостей внутри зависимого класса — не самая лучшая идея, давайте изучим альтернативный способ. Здесь зависимый класс определяет все необходимые ему зависимости внутри конструктора и позволяет пользовательскому классу предоставлять их. Является ли такой способ решением нашей проблемы? Узнаем немного позже.
Посмотрите на пример кода ниже:
class ClassA {
var classB: ClassB
constructor(classB: ClassB){
this.classB = classB
}
}
class ClassB {
var classC: ClassC
constructor(classC: ClassC){
this.classC = classC
}
}
class ClassC {
constructor(){
}
}
class UserClass(){
fun doSomething(){
val classC = ClassC();
val classB = ClassB(classC);
val classA = ClassA(classB);
classA.someMethod();
}
}
view rawDI Example In Medium -
Теперь ClassA
получает все зависимости внутри конструктора и может просто вызывать методы класса ClassB
, ничего не инициализируя.
Преимущества
ClassA
и ClassB
теперь слабо связаны, и мы можем заменить ClassB
, не нарушая код внутри ClassA
. Например, вместо передачи ClassB
мы сможем передать AssumeClassB
, который является подклассом ClassB
, и наша программа будет исправно работать.ClassA
теперь можно протестировать. При написании модульного теста, мы можем создать нашу собственную версию ClassB
(тестовый объект) и передать её в ClassA
. Если возникает ошибка во время прохождения теста, то теперь мы точно знаем, что это определенно ошибка в ClassA
.ClassB
освобожден от работы с зависимостями и может сосредоточиться на выполнении своих задач.Недостатки
ClassA
должен знать всё об инициализации ClassB
, что в свою очередь требует знаний и об инициализации ClassC
и т.д. Итак, вы видите, что любое изменение в конструкторе любого из этих классов может привести к изменению вызывающего класса, не говоря уже о том, что ClassA
может иметь больше одного пользователя, поэтому логика создания объектов будет повторяться.Второй способ очевидно работает лучше первого, но у него всё ещё есть свои недостатки. Возможно ли найти более подходящее решение? Прежде чем рассмотреть третий способ, давайте сначала поговорим о самом понятии внедрения зависимостей.
Внедрение зависимостей — это способ обработки зависимостей вне зависимого класса, когда зависимому классу не нужно ничего делать.
Исходя из этого определения, наше первое решение явно не использует идею внедрения зависимостей, а второй способ заключается в том, что зависимый класс ничего не делает для предоставления зависимостей. Но мы все ещё считаем второе решение плохим. ПОЧЕМУ?!
Поскольку определение внедрения зависимости [1] ничего не говорит о том, где должна происходить работа с зависимостями (кроме как вне зависимого класса), разработчик должен выбрать подходящее место для внедрения зависимостей. Как видно из второго примера, пользовательский класс является не совсем правильным местом.
Как же сделать лучше? Давайте рассмотрим третий способ обработки зависимостей.
Согласно первому подходу зависимые классы отвечают за получение своих собственных зависимостей, а во втором подходе мы переместили обработку зависимостей из зависимого класса в пользовательский класс. Давайте представим, что существует кто-то другой, кто мог бы обрабатывать зависимости, вследствие чего ни зависимый, ни пользовательский классы не выполняли бы эту работу. Этот способ позволяет работать с зависимостями в приложении напрямую.
«Чистая» реализация внедрения зависимостей (по моему личному мнению)
Ответственность за обработку зависимостей возлагается на третью сторону, поэтому ни одна часть приложения не будет с ними взаимодействовать.
Внедрение зависимостей — это не технология, фреймворк, библиотека или что-то подобное. Это просто идея. Идея работать с зависимостями вне зависимого класса (желательно в специально выделенной части). Вы можете применять данную идею, не используя какие-либо библиотеки или фреймворки. Тем не менее, мы обычно обращаемся к фреймворкам для внедрения зависимостей, потому что это упрощает работу и позволяет избежать написания шаблонного кода.
Любой фреймворк внедрения зависимостей имеет две неотъемлемые характеристики. Вам могут бы доступны и другие дополнительные функции, но эти две функции будут присутствовать всегда:
Во-первых, данные фреймворки предлагают способ определения полей (объектов), которые должны быть внедрены. Некоторые фреймворки осуществляют это посредством аннотирования поля или конструктора с помощью аннотации @Inject
, но существуют и другие методы. Например, Koin [2] использует встроенные языковые особенности Kotlin для определения внедрения. Под Inject
подразумевается, что зависимость должна обрабатываться DI-фреймворком. Код будет выглядеть примерно так:
class ClassA {
var classB: ClassB
@Inject constructor(classB: ClassB){
this.classB = classB
}
}
class ClassB {
var classC: ClassC
@Inject constructor(classC: ClassC){
this.classC = classC
}
}
class ClassC {
@Inject constructor(){
}
}
Во-вторых, фреймворки позволяют определить, как нужно предоставить каждую зависимость, и это происходит в отдельном файле (файлах). Приблизительно это выглядит так (учитывайте, что это лишь пример, и он может отличаться от фреймворка к фреймворку):
class OurThirdPartyGuy {
fun provideClassC(){
return ClassC() //just creating an instance of the object and return it.
}
fun provideClassB(classC: ClassC){
return ClassB(classC)
}
fun provideClassA(classB: ClassB){
return ClassA(classB)
}
}
Итак, как вы видите, каждая функция отвечает за обработку одной зависимости. Поэтому если нам где-то в приложении нужно использовать ClassA
, то произойдет следующее: наш DI-фреймворк создаёт один экземпляр класса ClassC
, вызвав provideClassC
, передав его в provideClassB
и получив экземпляр ClassB
, который передаётся в provideClassA
, и в результате создаётся ClassA
. Это практически волшебство. Теперь давайте изучим преимущества и достоинства третьего способа.
Преимущества
ClassC
на AssumeClassC
, который является подклассом ClassC
. Для этого нужно лишь изменить код провайдера следующим образом, и везде, где используется ClassC
, теперь автоматически будет использоваться новая версия:fun provideClassC(){
return AssumeClassC()
}
Обратите внимание, никакой код внутри приложения не меняется, только метод провайдера. Кажется, что ничего не может быть ещё проще и гибче.
Недостатки
В этой статье я попытался объяснить основы работы с понятием внедрения зависимостей, а также перечислил причины необходимости использования этой идеи. Существует ещё множество ресурсов, которые вы можете изучить, чтобы больше узнать о применении DI в ваших собственных приложениях. Например, этой теме посвящён отдельный раздел в продвинутой части нашего курса Android-профессии [3].
Автор: devcolibri
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/android-development/304118
Ссылки в тексте:
[1] определение внедрения зависимости: https://en.wikipedia.org/wiki/Dependency_injection
[2] Koin: https://insert-koin.io/
[3] курса Android-профессии: https://devcolibri.com/course/android-profession/
[4] Источник: https://habr.com/post/434380/?utm_source=habrahabr&utm_medium=rss&utm_campaign=434380
Нажмите здесь для печати.