SOLID: Um assunto necessário | Parte 4 — Princípio da Segregação de interface

Depois de uma pausa nos meus artigos sobre SOLID, resolvi retomar para enfim, concluirmos esse conhecimento.

Agora é a vez da letra I que trata-se do "Interface Segregation Principle", ou traduzindo: princípio da segregação de interface.

Este princípio é um dos que mais faz a gente ter aquela sensação de overengineering, na minha opinião.

Veja esse exemplo: Temos uma interface de Registro no banco de dados. Essa interface tem um método para validar os dados inseridos, salvar e depois, enviar um e-mail de confirmação.

interface IRegister {
    fun validateData()
    fun save()
    fun sendEmail()
}

E eu acabei implementando essa interface em dois cenários.

No primeiro cenário, faz total sentido, já que trata-se de uma classe de usuário. O usuário tem os dados validados, salvos, e logo após, eu envio um e-mail de confirmação para ele:

class UserRegister: IRegister {
    
    override fun validateData() {
        TODO("Lógica para validar os dados")
    }

    override fun save() {
        TODO("Lógica para salvar os dados validados")
    }

    override fun sendEmail() {
        TODO("Lógica para enviar e-mail de confirmação")
    }

}

Mas no segundo cenário, trata-se de um cadastro de produtos. Também vou precisar validar os dados inseridos, salvar no banco, mas nesse caso, não preciso enviar e-mail de confirmação para ninguém:

class ProductRegister: IRegister {

    override fun validateData() {
        TODO("Lógica para validar os dados")
    }

    override fun save() {
        TODO("Lógica para salvar os dados validados")
    }

    override fun sendEmail() {
        /* NOT USED
         * Este método não precisa ser implementado
         * pois não enviaremos confirmação para ninguém
         */
    }
}

E aí que entra a questão: Muitas pessoas resolveriam isso de diversas formas: emitindo uma exception, comentando o famoso “NOT USED”, ou simplesmente deixando o método em branco.

Como trata-se da implementação de uma interface, eu não consigo excluir esse método, pois uma interface é como um contrato, e eu devo implementar todos os métodos da interface.

Qual o problema disso? Estou forçando a classe ProductRegister implementar um método que ela não precisa.

Se formos aplicar o princípio de segregação de interface, o cenário ideal seria esse: Separar em duas interfaces distintas.

• Uma para cadastro de usuários;
• Uma para cadastro de produtos;

Ou seja, teríamos o seguinte cenário: Para o cadastro de usuário, faríamos uma nova interface chamada IUserRegister:

interface IUserRegister {
    fun validateData()
    fun save()
    fun sendEmail()
}

E aí a classe UserRegister implementaria os métodos da interface acima:

class UserRegister: IUserRegister {

    override fun validateData() {
        TODO("Lógica para validar os dados")
    }

    override fun save() {
        TODO("Lógica para salvar os dados validados")
    }

    override fun sendEmail() {
        TODO("Lógica para enviar e-mail de confirmação")
    }
}

Já no caso do cadastro de Produtos, faríamos outra interface, somente com os métodos utilizados para cadastro do mesmo, ou seja, sem o método sendEmail():

interface IProductRegister {
    fun validateData()
    fun save()
}

E assim, a classe ProductRegister precisaria implementar somente as duas funções acima:

class ProductRegister: IProductRegister {

    override fun validateData() {
        TODO("Lógica para validar os dados")
    }

    override fun save() {
        TODO("Lógica para salvar os dados validados")
    }
}

Parece muito duplicação de código, né? Mas acredite: essa “duplicação” te ajudará muito! Tanto para dar manutenção para esse código, quanto na reutilização.

Como o próprio princípio diz: Prefira SEMPRE interfaces menores, mais específicas, do que interfaces generalistas, em que você tenta ter todos os métodos dentro, fazendo com que suas implementações herdem métodos que nem sequer faz sentido para o seu cenário.

Lembrando que esta é uma série de 5 postagens em que abordo os princípios de SOLID de forma mais objetiva possível. Perdeu os 2 primeiros? Veja aqui:

Parte 1: Princípio da Responsabilidade Única

Parte 2: Princípio do Aberto/Fechado

Parte 3: Princípio da Substituição de Liskov

Me siga no LinkedIn para ficar por dentro dos próximos!

Code Like a Girl 👧