SÓLIDO — De Zero a Batata 5

Hoje continuarei explicando sobre o Princípio de Inversão de Dependência (DIP) neste artigo. Estaremos familiarizados com outros princípios no SOLID porque, mesmo que não saibamos sobre o princípio SOLID , podemos aprender com o código de nosso sênior, vários artigos médios e tutoriais, mas você será muito raro ouvir o que é Inversão de Dependência e como devemos usá-la e por que devemos usá-la.

Aliás, se você já trabalha como Desenvolvedor Android não confunda com Injeção de Dependência. Você já estará familiarizado com as bibliotecas populares Dagger, Hilt e Koin. Esses dois são muito diferentes, então tenha cuidado ao explicar, especialmente em entrevistas.

A injeção de dependência é uma técnica de implementação para preencher variáveis ​​de instância de uma classe. A Inversão de Dependência é uma diretriz geral de design que recomenda que as classes só tenham relacionamentos diretos com abstrações de alto nível.

Princípio de Inversão de Dependência (DIP): Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações.

Deixe-me explicar com uma implementação de código simples, depois disso você entenderá melhor sobre o DIP. Como de costume, vamos começar com Studentuma classe que depende de uma Teacherclasse para executar algumas funcionalidades:

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

então vamos refatorar para aderir ao DIP , podemos introduzir uma abstração entre as classes Studente :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)
    }
}

Isso segue o DIP porque a Studentclasse agora depende de uma abstração ( QuestionAnswerer) em vez de uma implementação concreta ( Teacher). Isso permite maior flexibilidade e extensibilidade, pois qualquer classe que implementa a QuestionAnswererinterface pode ser usada como uma dependência da Studentclasse, não apenas da Teacherclasse.

Depois de ver a versão refatorada, espero que você entenda por que devemos usar a Inversão de Dependência também. O DIP ajuda a desacoplar os componentes em seu aplicativo e pode tornar seu código mais flexível, sustentável e mais fácil de testar.

Obrigado por tomar o tempo para ler este artigo. Espero que minha escrita tenha sido informativa e instigante. Boa codificação para todos vocês antes.

Artigo anterior sobre SOLID :

Princípio de Responsabilidade Única (SRP) :https://medium.com/arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Princípio Aberto/Fechado (OCP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

Princípio da Substituição de Liskov (LSP): https://medium.com/arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe

Princípio de Segregação de Interface (ISP):https://medium.com/arpalar-tech/solid-from-zero-to-potato-4-d1d9b42c3a78