SOLID , Shazam da orientação a objetos? — Parte 4

Thiago Chagas
Aug 28, 2019 · 4 min read

E aí pessoal , tudo bem com vocês? Voltamos para a quarta parte da série SOLID,”O Shazam da Orientação a objeto” para que tenhamos boas práticas de programação na construção dos nossos códigos.Não conseguiu acompanhar a série?Vem tranquilo que aqui estão os links das partes anteriores: parte 1, parte 2 , parte 3.

E hoje vamos falar sobre a Segregação por Interfaces ou ISP
(Interface Segregation Principle).Mas o que diz este princípio??

Ninguém deve ser forçado a depender das coisas que não usam.

Eu não tenho que ficar criando uma interface para cada coisa, porque eu vou ficar com quantidade muito grande de interfaces”(Programador resistente).

Com essas duas frases acho que já podemos ter noção do que se trata não é mesmo?

O princípio da Segregação por interfaces nos diz que não se deve ter interfaces ou classe base com métodos desnecessários para responsabilidade da subclasse que vai estender seu comportamento.

Não existem problemas na criação de muitas interfaces e sim em ter uma única que faça muita coisa, por isso muitas interfaces específicas são melhores que uma interface única.

Vamos exemplificar isso com a imagem abaixo.

Na imagem acima vemos que existem vários usuários que usam as operações da classe OPS. A nível de exemplo, vamos supor que o User1 usa somente a op1, User2 a op2 e User3 a op3. Esta classe sendo escrita em uma linguagem tipada, faz com que mesmo o User1 não usando as op2 e op3,tem que implementá-las e isso corrompe o código e gera o code smell.
O Problema pode ser resolvido usando a Segregação de Interfaces onde cada User irá implementar uma interface contendo somente os contratos que serão usados por eles conforme a imagem:

E aí entendeu?? Não??

Vamos exemplificar com algo mais cotidiano.

No nosso programa de exemplo,existem duas classes ImpressoraHP e ImpressoraSamsung e ambas implementam a interface IFuncoesImpressora. Esta interface contém três métodos: Imprimir, Escanear e EnviarFax. As impressoras são diferentes e tem algumas peculiaridades. A ImpressoraHP não envia Fax e a ImpressoraSamsung não tem scanner.
Implementando a interface, temos que seguir o contrato, ou seja , as classes tem que implementar os métodos mesmo que não usem e isso pode causar um desastre , olhe na imagem

Criamos uma instância de ImpressoraHP e tentamos usar o método EnviarFax que não é uma característica da impressora.
O programa gera uma exceção pois o grande problema aqui é que não temos como saber se a ImpressoraHP tem uma implementação ou não para o método EnviarFax.

E como resolvemos??

Segregamos os comportamentos das impressoras em interfaces de acordo com a necessidade de cada uma.Criamos duas interfaces IFuncoesHp e IFuncoesSamsung. Cada uma conterá apenas o que pode ser usado
nas classes de acordo com a regra proposta. Na antiga interface IFuncoesImpressora, deixamos apenas o método Imprimir pois ele é comum em todas as impressoras e fazemos com que as interfaces criadas implementem o comportamento padrão de IFuncoesImpressora.

Agora cada classe implementa a sua interface segregada e de quebra ainda tem o comportamento padrão Imprimir.

Agora no programa vemos os método disponíveis na classe e podemos usá-los sem problema nenhum.

Chegamos ao final de mais uma fase da nossa jornada, no próximo artigo falaremos sobre o Princípio da Inversão de Dependência.

Até lá.

May the force be with you!

    Thiago Chagas

    Written by

    Microsoft Technology Associate (MTA), .Net Developer at Radix

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade