SOLID — Interface Segregation Principle (ISP)
Hoje vamos dar sequência a nossa série de artigos sobre os princípios SOLID. Ao contrário do artigo anterior, o tema de hoje é bem simples e tenho certeza que muitas pessoas vão se identificar, pois já infringiram o Princípio da Segregação de Interfaces ou Interface Segregation Principle.
Este princípio diz que, uma classe não deve ser forçada a implementar interfaces e métodos que não irá utilizar.
Exemplo prático
Elaborando um cenário fictício para a construção de um sistema de controle de criação de aves de um determinado zoológico, criaremos uma interface IAves para abstrair o comportamento desses animais. Logo em seguida faremos com que nossas classes TPinguim e TArara implementem esta interface, veja:
Percebam que ao criar a interface IAves, atribuímos comportamentos genéricos e isso acabou forçando a classe TPinguim a implementar o método Voardo qual ela não deveria ter, pois pinguins não voam! Dessa forma, estamos violando o Interface Segregation Principle (e o LSP também!). Para resolver este problema, devemos criar uma interface mais específica, veja:
No exemplo acima, retiramos o método Voar da interface IAves e adicionamos em uma nova interface IAvesQueVoam. Isso nos permitiu isolar os comportamentos das aves de maneira correta dentro do nosso sistema, respeitando o princípio da segregação das interfaces.
Conclusão
Em resumo o ISP propõe que, ao definirmos uma interface, ela tenha poucos métodos e que sejam específicos dos escopos que estamos trabalhando. Ao criar pequenas interfaces, conseguimos reaproveitar parte do código e utilizar só o que é realmente necessário em cada caso. Isso torna nossas classes mais coesas e limpas, pois temos comportamentos e responsabilidades bem definidas.
