• 

  Rafael Camarda

• 2 de julho de 2018

O Interface Segregation Principle – Entendendo SOLID – parte 4

Estamos quase lá! Estamos no nosso 4° e penúltimo post! e hoje falaremos sobre o Interface Segregation Principle. Lembrando que se você não viu os primeiros posts, você pode acompanhá-los aqui.

Nosso quarto princípio foi definido por Robert C. Martin e diz que “Clients should not be forced to depend upon interfaces that they don’t use”. Em uma tradução livre, o que o princípio diz é que clientes não deveriam ser forçados a depender de interfaces que eles não usam.

Não ficou claro ainda? Vamos ao exemplo:

Perceba que na imagem acima foi definida uma interface ITrabalhavel que define que todo trabalhador come e trabalha. Porém em pleno 2018, um robô também pode trabalhar certo? Ou seja, ele também pode fazer uso da interface ITrabalhavel para definir seus métodos.

Porém, um robô não come. Bem, ao menos eu acho que não. Assim, esse código fere o ISP já que obriga o robô a implementar o método comer, mesmo sendo um método que robô não deveria ter. Portanto, o ideal seria dividir as interfaces de nosso sistema em interfaces menores, não forçando o cliente a implementar interfaces gigantes, mas sim escolher as interfaces que deseja implementar como uma espécie de “subconjunto de métodos”.

O Interface Segregation Principle

Vejamos agora como esse exemplo poderia ser feito sem ferir o ISP:

Agora, com pequenas interfaces, o cliente pode escolher quando deseja implementar a interface ITrabalhavel e IAlimentavel, permitindo mais flexibilidade em nossa implementação. Veja que o que o princípio quer demonstrar é que, sempre que possível, divida as responsabilidades das suas classes. Defina melhor seu escopo e não generalize tanto em seus métodos. Pelo contrário, seja mais específico, restritivo e exato ao defini-los. 

Espero que tenha ficado claro o que é o Interface Segregation Principle. Espero te ver aqui na semana que vem para o último post da nossa série!

Adendo:

Todos nossos exemplos até aqui foram feitos em Ruby. Mas por que nesse post trouxemos o exemplo em Java? Simples: Ruby não possui interfaces! Mas o que tiramos de lição do princípio é que separar nossas classes com pequenas responsabilidades bem definidas nos permite manter nosso código com baixo acoplamento. Dessa forma, mantendo nossa code base mais saudável, permitindo sua evolução e manutenção de forma facilitada.

Algumas fontes utlizadas nesse post:

• https://thoughtbot.com/upcase/videos/interface-segregation-principle
• http://marioaquino.blogspot.com/2013/07/interface-segregation-principle-in-ruby.html
• http://rubyblog.pro/2017/07/solid-interface-segregation-principle
• https://www.netguru.co/codestories/solid-4-isp