Este é o quarto artigo da série Princípios SOLID – Boas práticas de programação com C#. Nele falaremos da quarta letra do acrônimo do SOLID: ISP: Interface Segregation Principle. Você pode ler o artigo anterior clicando aqui.

Princípio da Segregação de Interface: Classes não devem ser forçadas a depender de métodos que não usam.

Para evidenciar melhor o cenário, suponhamos que exista o domínio de produtos e clientes e que é necessário implementar o cadastro de ambos, e pensando em “simplificar” poderíamos ter a seguinte abstração:

public interface ICadastro
    {
        void ValidarDados();
        void SalvarBanco();
        void EnviarEmail();
    }

E as respectivas classes implementando-as:

public class CadastroCliente : ICadastro
    {
        public void ValidarDados()
        {
            // Validar CPF, Email
        }

        public void SalvarBanco()
        {
            // Insert na tabela Cliente
        }

        public void EnviarEmail()
        {
            // Enviar e-mail para o cliente
        }
    }

public class CadastroProduto : ICadastro
    {
        public void ValidarDados()
        {
            // Validar valor
        }

        public void SalvarBanco()
        {
            // Insert tabela Produto
        }

        public void EnviarEmail()
        {
            // Produto não tem e-mail, o que eu faço agora???
            throw new NotImplementedException("Esse metodo não serve pra nada");
        }
    }

Qual o problema aqui? O domínio de produto não sabe nada sobre envio de email, portanto, temos um erro de abstração.

Avaliando melhor o cenário percebe-se a necessidade em desacoplar os dois cadastros, já que são regras diferentes.

Como solução poderíamos ter uma interface para cada contexto separado:

public interface ICadastro
    {
        void SalvarBanco();
    }

public interface ICadastroCliente : ICadastro
    {
        void ValidarDados();
        void EnviarEmail();
    }

public interface ICadastroProduto : ICadastro
    {
        void ValidarDados();
    }

Assim, cada implementação teria apenas a parte que realmente lhe cabe:

public class CadastroCliente : ICadastroCliente
    {
        public void ValidarDados()
        {
            // Validar CPF, Email
        }

        public void SalvarBanco()
        {
            // Insert na tabela Cliente
        }

        public void EnviarEmail()
        {
            // Enviar e-mail para o cliente
        }
    }

public class CadastroProduto : ICadastroProduto
    {
        public void ValidarDados()
        {
            // Validar valor
        }

        public void SalvarBanco()
        {
            // Insert tabela Produto
        }
    }

A dica aqui é:

• Trabalhe orientado à interfaces. Os contratos pré definidos permitirão que as classes dependentes tenham a implementação somente dos métodos que fazem sentido no contexto.

No próximo artigo vamos falar sobre o Princípio da Inversão de Dependência (DIP) e entender melhor porque inverter o controle e depender de abstrações ao invés de implementação, deixa o código mais desacoplado.

Referências

C# – Princípio Da Segregação da Interface(ISP)

PIRES, E. SOLID: Teoria e Prática.

ANICHE, M. Orientação a Objetos e SOLID para ninjas. São Paulo – Casa do Código

Samyla Dutra

Mineira, atuo na área de desenvolvimento desde 2017 e sou graduada em Engenharia de Computação pelo CEFET-MG. Gosto de entender a profundidade do backend e como melhorar a escrita de código. E isso se torna melhor em equipe! Amo estar em contato com a natureza, trilhar montanhas, ler livros e cozinhar.