Sumário
Veja o índice completo do tópico “S.O.L.I.D”
Olá pessoas …
Continuando a nossa saga de artigos, vamos agora ver a letra I do acróstico que define a sigla ISP Interface Segregation Principle (Princípio de Segregação de Interface).
Definição
Este princípio é o mais simples de entender, ele quer dizer que:
A segregação de interfaces assume que suas interfaces devem ser coesas, quando uma interface não é coesa, ele contêm métodos que não dizem respeito ao grupo de comportamento que as definem.
Coesão está diretamente ligada ao Princípio da Responsabilidade Única (SRP).
![]() |
Certo ou errado?Vamos agora aos nossos exemplos entre certo e errado. |
Ferindo o princípio
![]() |
Isto está errado.Perceba que a interface “ISaldo” define o método “Atualizar()” e o método “BaixarEstoque()“. A primeira vista está certo, pois podemos assumir que é uma interface para cálculo de saldo de estoques. /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ namespace Solid.Errado.Contract { public interface ISaldo { #region Public Methods void Atualizar(); void BaixarEstoque(); #endregion Public Methods } } A classe abaixo, de forma errada e ferindo o princípio da SRP, implementa a interface “ISaldo“, perceba que a classe de saldo é obrigada a atualizar os saldos e realizar a baixa em estoque de um produto qualquer. /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.Contract; using System; namespace Solid.Errado { public class AtualizarSaldoDiario: ISaldo { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo DIARIO foi atualizado."); } public void BaixarEstoque() { Console.WriteLine("O estoque foi baixado em 10 itens"); Atualizar(); } #endregion Public Methods } } Classe para cálculo de saldo financeiro. /* * Classe apenas para fins de exemplo e aprendizado não considera nenhum tipo de validação ou regra ou se utiliza de algum framework. */ using Solid.Errado.Contract; using System; namespace Solid.Errado { public class SaldoFinanceiro: ISaldo { #region Public Methods public void Atualizar() { Console.WriteLine("O saldo financeiro foi atualizado."); } public void BaixarEstoque() { throw new Exception("OPS! Eu não sei o que fazer aqui. Não sou uma classe de saldo de estoques"); } #endregion Public Methods } } |
Como podemos perceber, à primeira vista nossas definições de interfaces parecem corretas, pois se estamos falando de saldos, podemos baixar o estoque para calcular os saldos. Neste momento já podemos perceber que ferimos o princípio do SRP e do ISP. Apesar de eu estar falando de saldos, eu posso estar calculando saldos financeiros, que nada têm haver com saldos de estoque, e se por alguma razão eu implementar esta definição de saldos, serei obrigado a baixar estoque em uma movimentação financeira.
Então, vamos corrigir o princípio…
Corrigindo o princípio
Como podemos perceber, ao extrair as interfaces, abstrações e definindo as classes concretas, utilizamos os 4 princípios que aprendemos até agora:
- Cada uma tem sua responsabilidade, (SRP);
- As classes de saldo, só atualizam saldos. Removemos o a baixa de estoque da interface mais genérica.
- Podem sofrer heranças e ter seus comportamentos modificados, (OCP);
- Eu posso herdar a classe de saldos de base e modificar o comportamento do método “Atualizar()“.
- Podem ser convertidas entre suas generalizações e especializações (LSP);
- Eu posso passar, como parâmetro por exemplo, qualquer classe de saldo e chamar um método que realiza os cálculos de saldos da aplicação.
- E por fim, interfaces e abstrações (Este princípio – ISP);
- Abstraímos todas as interfaces e abstrações das classes que necessitamos para que nossas classes de cálculo de saldos façam apenas cálculos de saldos.
O fonte utilizado aqui pode ser baixado pelo GITHub em https://github.com/desenvolvedores-net/ArtigoSOLID
É isso ai pessoal 🙂
Até o próximo
♦ Marcelo