Fala ai Radizeiros e Radizeiras, tudo bem com vocês?
Neste post estarei falando sobre um dos princípios do SOLID, o ISP – Interface Segregation Principle, ou Princípio da segregação de interfaces.
Ele é um dos princípios mais simples, mas existem diversos programadores que violam esse princípio, achando que estão fazendo algo de bom e de forma correta, mas sem perceber acabam violando o Princípio da segregação de interfaces.
Então vamos ver na prática o que é isso?
Iremos criar um projeto simples, e nesse projeto, iremos modelar um time de futebol.
iFutebol = interface
['{5245BC83-349D-446F-AB21-3F0F28F51590}']
procedure TreinarTime;
procedure OrganizarTatica;
procedure Jogam;
end;
TComissaoTecnica = class(TInterfacedObject, iFutebol)
procedure TreinarTime;
procedure OrganizarTatica;
procedure Jogam;
end;
TTreinador = class(TInterfacedObject, iFutebol)
procedure TreinarTime;
procedure OrganizarTatica;
procedure Jogam;
end;
TJogadores = class(TInterfacedObject, iFutebol)
procedure TreinarTime;
procedure OrganizarTatica;
procedure Jogam;
end;
Observe que criamos uma interface chamada iFutebol e nela temos 3 procedures que implementam o time de futebol.
Logo em seguida foi criada 3 classe que implementam essa interface e seus métodos, aqui já estamos violando o princípio ISP – Interface Segregation Principle.
O que isso quer dizer?
Estamos atribuindo por causa de uma interface genérica, estamos imputando em classes que derivam de um mesmo propósito, funções que não são pertinentes a elas.
Por exemplo, o jogador treina um time? Não. O jogador organiza taticamente o time? Não; Mas ele joga, porém essas duas primeiras estão implícitas em um time de futebol mas elas não são de responsabilidade do jogador.
Mas eu posso deixar elas nessa classe?
Pode, não irá dar problema nenhum, a princípio, mas lá na frente elas iram me causar um tremendo problema, uma tremenda quantidade de lixo no código sem a necessidade.
Outro problema que isso pode trazer para nós, vamos dizer que no método TreinarTime e eu tenha que passar por parâmetro a tática.
... iFutebol ... procedure TreinarTime(Tatica : String); ...
Informando qual seria a tática a ser usada para esse meu time.
Teoricamente que treina o time é a comissão técnica, aqui em nosso exemplo, então eu teria que ir somente na classe de comissão técnica e fazer a alteração.
Porém como eu não respeitei o princípio da segregação de interfaces, eu terei que fazer essa alteração também nas demais classes que não tem essa responsabilidade, o que não é legal e certamente irá atrasar muito o meu projeto, a manutenção do meu software, irá me causar um problema em raiz.
Então qual é o ideal?
O ideal é você ter interfaces menores que compõe o time de futebol.
Então ficaria desta forma.
...
iJogador = interface
['{146677F0-8EBC-45B5-AD16-523DC67FD562}']
procedure Jogar;
end;
iComissaoTecnica = interface
['{737A09AE-6A8F-423A-B047-3EABC11511FF}']
procedure TreinarTime(Tatica : String);
end;
iTreinador = interface
['{AFAE0284-39D6-4B9E-91BC-4F44925C645D}']
procedure OrganizarTatica;
end;
...
Desta forma eu componho o time de futebol através de interfaces menores, e cada um definido as suas responsabilidades.
Então se você criou uma super interface, cheia de métodos que não está sendo usado para todas as classes, é hora de você refatorar isso, segregar e criar interfaces menores para resolver esses problemas específicos.
Esse post faz parte de um dos meus treinamentos a CERTIFICAÇÃO ESPECIALISTA EM CLEAN CODE E BOAS PRÁTICAS DE PROGRAMAÇÃO.
A Certificação Especialista em Clean Code e Boas Práticas de Programação dará a você a oportunidade de melhorar seu software, otimizar o seu tempo e te dar a possibilidade de atender melhor os seus clientes. Conhecer a fundo essas técnicas e utilizar todos os seus benefícios irá facilitar muito a sua vida quando houver necessidade por parte de um cliente de um update rápido ou resolver um problema.
CLIQUE AQUI PARA SABER MAIS SOBRE A CERTIFICAÇÃO ESPECIALISTA EM CLEAN CODE E BOAS PRÁTICAS DE PROGRAMAÇÃO
