S.O.L.I.D na prática: Interface Segregation Principle (ISP)
Neste post veremos o Interface Segregation Principle (OSP) – Princípio de Segregação de Interfaces, que corresponde a letra I (quarta letra) do acrônimo SOLID.
Chegamos ao quarto princípio e ao quinto post da série SOLID na prática. Então bora para mais um! (já estamos na reta final da série \o/)
O que é o Interface Segregation Principle (ISP)?
O Princípio de Segregação de Interface, diz que:
“Um cliente não deve ser forçado a implementar uma interface que não irá usar”
Também podemos entender que os clientes (módulos, classes…) não devem ser forçados a depender de métodos ou propriedades que não utilizarão.
O príncipio também reforça que é melhor termos interfaces mais específicas do que uma interface mais genérica, a qual normalmente define mais métodos do que deveria definir em sua especificação (no arquivo de interface).
Vale lembrar que, nesses casos, qualquer mudança nas definições (assinaturas) dos métodos e/ou nas propriedades dessa interface implicarão também em mudanças em todas as classes que implementam essa interface, mesmo que tal implementação não faça sentido para essas classes. Daí vem a expressão “forçar a implementação”.
A imagem a seguir, mostra um exemplo simples no qual as 2 classes “UserOperation” estruturalmente implementam a interface “Operations“. Sendo assim, cada classe é obrigada a ter todos os métodos da interface, neste caso representados pelos métodos Operation1, Operation2 e Operation3.
Suponha então, que a classe UserOperation2 não precise, de fato, utilizar as operações 2 e 3 (em vermelho).
(Obs.: No diagrama usei uma representação de generalização/especialização e inclui alguns comentários apenas para fins didáticos)
Muitas pessoas podem se deparar com essa situação no cotidiano e achar que se trata apenas de mais um caso inofensivo de método a ser desconsiderado, mas o que acaba acontecendo na prática é que seu código acaba ficando mais sujo e menos seguro.
- Mais “sujo” no sentido de ter mais coisas do que deveria ter, forçando dependência de implementações totalmente desnecessárias e;
- Menos seguro, na construção e na execução do código, porque pode levar a erros de codificação e até a execuções desnecessárias ou inconsistentes.
Consegue imaginar o quanto isso pode atrapalhar a criação ou manutenção do código e do sistema!? :S
Para entender melhor sobre o conceito na prática e ver como podemos resolver situações como essa, veja o vídeo a seguir, no qual mostro um exemplo de violação e de adequação ao ISP.
Clique aqui caso queira acessar o primeiro post da série sobre SOLID
