SOLID — От нуля до картошки 5

Сегодня я продолжу объяснять принцип инверсии зависимостей (DIP) в этой статье. Мы будем знакомы с другими принципами в SOLID , потому что, даже если мы не знаем о принципе SOLID , мы можем узнать из кода нашего старшего, различных средних статей и руководств, но вы очень редко услышите, что такое инверсия зависимостей , как мы должны ее использовать и почему мы должны ее использовать.

Кстати, если вы уже работаете Android-разработчиком, не путайте с внедрением зависимостей. Вы уже знакомы с популярными библиотеками Dagger, Hilt и Koin. Эти двое очень разные, поэтому будьте осторожны, когда вы объясняете, особенно в интервью.

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

Принцип инверсии зависимостей (DIP): модули высокого уровня не должны зависеть от модулей низкого уровня; оба должны зависеть от абстракций.

Позвольте мне объяснить вам простую реализацию кода, после чего вы лучше поймете, что такое DIP. Как обычно, давайте начнем с Studentкласса, который зависит от Teacherкласса для выполнения некоторых функций:

class Student(private val teacher: Teacher) {
    fun askQuestion(question: String) {
        teacher.answerQuestion(question)
    }
}

поэтому пусть рефакторинг придерживается DIP , мы можем ввести абстракцию между классами Studentи Teacher:

interface QuestionAnswerer {
    fun answerQuestion(question: String)
}

class Teacher : QuestionAnswerer {
    override fun answerQuestion(question: String) {
        // answer the specified question
    }
}

class Student(private val questionAnswerer: QuestionAnswerer) {
    fun askQuestion(question: String) {
        questionAnswerer.answerQuestion(question)
    }
}

Это соответствует DIP, поскольку Studentкласс теперь зависит от абстракции ( QuestionAnswerer), а не от конкретной реализации ( Teacher). Это обеспечивает большую гибкость и расширяемость, поскольку любой класс, реализующий QuestionAnswererинтерфейс, может использоваться как зависимость для Studentкласса, а не только Teacherкласс.

Увидев версию с рефакторингом, я надеюсь, вы поймете, почему мы также должны использовать инверсию зависимостей , DIP помогает отделить компоненты в вашем приложении и может сделать ваш код более гибким, удобным в сопровождении и более простым для тестирования.

Спасибо, что нашли время прочитать эту статью. Я надеюсь, что мое письмо было информативным и наводящим на размышления. Удачного кодирования для всех вас, чем раньше.

Предыдущая статья о SOLID:

Принцип единой ответственности (SRP) :https://medium.com/arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Открытый/закрытый принцип (OCP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

Принцип замены Лисков (LSP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe

Принцип разделения интерфейсов (ISP):https://medium.com/arpalar-tech/solid-from-zero-to-potato-4-d1d9b42c3a78