I — Interface Segregation Principle (Princípio da Segregação da Interface)
Alô Tio Bob, perdeu as energias no caminho do SOLID? Guri, temos que seguir, este não é o final! Risos. Quem passa pelo capítulo do ISP tem esta sensação, afinal, a conversa é curta neste instante.
O resumo da ópera é muito lindo e pode ser resumido em uma pequenina frase bombástica que soa como uma bomba atômica, embora, o seu entendimento possa divergir um tanto do que imaginamos, ora,
“… evitem depender de coisas que não usam”.
Literalmente é um conselho importante, afinal, todo programa deve ser enxuto o suficiente para ter apenas o que se usa, correto? No entanto, embora o conceito seja simples como deve ser, sua abstração é inversamente proporcional, ou seja, por si só não vamos conseguir entender direito o que isto quer dizer.
Ah! Mas e a conversa de que devemos depender de interfaces? Vamos tentar explicar isto de uma maneira simples para elucidar os fatos. Boa né!
O exemplo utilizado pelo Tio Bob em seu livro Arquitetura Limpa sugere que nós evitemos a dependência de uma classe que possui várias operações de classe que podem ser utilizados por diferentes atores, ou seja, devemos separar as operações de classes em interfaces especialistas para que cada ator possa usufruir de apenas o que precisa. Tecnicamente isto refletirá exatamente a frase:
É prejudicial depender de módulos que contenham mais elementos do que você precisa. (…) Aprenda esta lição: depender de algo que contém itens desnecessários pode causar problemas inesperados.
Procurando elementos para entender melhor os desdobramentos desse princípio encontrei a máxima do Duck Typing que nos dá uma luz extraordinária para nossa melhoria na segregação de interfaces. Basicamente ela aponta para métodos e operações que algum objeto/classe pode fazer, porém, não pergunta diretamente ao objeto se ele tem ou faz alguma ação. Vejamos:
Quando eu vejo um pássaro que caminha como um pato, nada como um pato e grasna como um pato, eu chamo aquele pássaro de pato. (James Riley)
Este estilo de programação do Duck Typing é muito interessante pois nos mostra que podemos melhorar nossa interação entre classes com vistas nos métodos/operações que queremos fazer. Isto facilita criar uma estratégia mais adequada para garantir a coesão entre classes sem precisar depender de alto acoplamento, ou seja, sempre que temos interfaces especialistas suas interfaces nos livram de um pepino tremendo que é a quebra de código por alto acoplamento ou mesmo pela presença inadvertida de métodos dos quais não necessitamos.
Meus caros, parece uma coisa simples, porém, aqui precisamos ter uma estratégia de desenho de software caprichada para podermos evoluir sem algum prejuízo. Claro que no início de nossos programas volta e meia tomamos decisões rápidas para favorecer as entregas. Então sigam pelo menos o conselho do Tio Bob de organizar os contratos com métodos adequados para a finalidade que se busca no momento. Haverá refatoração?
Sim! Inevitavelmente o futuro é aberto e indeterminado, ou seja, o nosso melhor hoje pode mudar radicalmente amanhã, então, busque sempre um meio termo para levar seu software a uma vida longa. O fato de você pensar neste princípio já é um indicativo de que a qualidade de software será garantida e o fato de pensar que podemos evoluir será o divisor de águas para termos uma vida próspera.
Bons estudos!
Alexandre.
Vamos falar mais sobre o assunto?
https://www.linkedin.com/in/alexandre-klock-ernzen-5484319/
Artigos sobre SOLID:
Introdução > https://medium.com/@bracinho2/solid-introdu%C3%A7%C3%A3o-6b4dbdacdb87
S > https://medium.com/@bracinho2/srp-single-responsability-principle-8d9a68bbae76
O > https://medium.com/@bracinho2/ocp-open-closed-principle-cc21cb168707
