SOLID: Um assunto necessário | Parte 2 — Princípio do Aberto/Fechado

Depois que definidos o que significa o tal do S no SOLID nesta primeira parte deste artigo, vamos partir para os demais princípios?

A letra "O" desse acrônimo refere-se ao "Open/Closed Principle" e, na teoria, diz que:

Um objeto deve ser aberto para extensão, porém fechado para modificação.

Mas quando paramos para analisar a frase acima, esse conceito nos soa um tanto quanto abstrato, dificultando a implementação do mesmo em nosso dia a dia. Então vamos tentar desconstruir um pouco esse conceito e trazer para nossa realidade esse conceito.

O princípio de aberto e fechado colabora muito com o nosso nível de abstração das classes. Como o próprio princípio diz, as classes “base” devem ser sempre abertas para extensão, porém, fechadas para modificações.

Um dos exemplos mais comuns que posso citar é uma classe chamada “Login” em que possui um método chamado “doLogin()”.

Imagina agora se para todos os tipos de funcionários (gerente, desenvolvedor, product manager, etc), existisse um fluxo específico para realizar o login. O que muitas pessoas fariam, provavelmente, é um grande IF dentro de doLogin() para saber o tipo do funcionário e realizar o fluxo correto:

class Login {

    fun doLogin(user: User) {
        if(user is Manager) {
            // Make a flow
        } else {
            // Make another flow
        }
    }
}

Porém, fazendo dessa forma, você está violando este princípio de ”aberto/fechado”.

É inviável fazer isso da forma que está sendo apresentada aqui, pois amanhã se tivermos mais 10 novos tipos de usuários, este método ficará cheio de lógica que deveria ser abstrata para ele.

Então, aplicando o princípio de aberto/fechado, uma das formas de resolver este encapsulamento, seria extrair a classe Login para uma interface:

interface Login {
    fun doLogin()
}

E fazer com que cada tipo de usuário implemente as suas próprias regras de login:

class UserLogin : Login {

    override fun doLogin() {
        // Flow to login User
    }
}

class ManagerLogin : Login {

    override fun doLogin() {
        // Implements another Flow
    }
}

Vimos que “fechamos” a classe Login (ou seja, mesmo que entrem 10 novos tipos de usuários, não a modificaremos), e a abrimos para extensão. Se amanhã entrar um novo usuário do tipo “Desenvolvedor” que terá um fluxo de login diferente, ele poderá simplesmente estender e sobrescrever o método de login.

Lembrando que esta é uma série de 5 artigos onde abordaremos cada um dos princípios de SOLID de forma prática para melhor entendimento.

Perdeu a primeira parte? Veja aqui.

Code Like a Girl 👧