L — Liskov Substitution Principle (Princípio da Substituição de Liskov)
Quando ouvimos o nome da querida Barbara Liskov infelizmente somos levados por nosso intelecto a uma zona obscura com a geração de um medo terrível.
Talvez este nome justamente foi o grande motivador de consultar o Tio Bob para imaginar o que seria este princípio que parece ser algo que nós, meros mortais, sejamos incapazes de entender.
Pois, bem! Vamos arriscar na tentativa de explicar isto facilmente. Lembram daquele famoso “contrato” entre as partes cujas partes ninguém sabe explicar e tão pouco sabemos o que exatamente contrata?
“…para criar software a partir de partes intercambiáveis, estas partes devem aderir a um contrato que permita que elas sejam substituídas umas pelas outras”.
Nossa amiga Barbara nos deixou um legado incrível baseado na lógica matemática tratando dos nossos objetos como subtipos uns dos outros, ou seja, se um objeto X segue nosso contrato A, este objeto X é um subtipo de A assim como um objeto Y que segue o contrato A é um subtipo de A.
Se seguirmos essa lógica poderemos ter partes intercambiáveis de acordo com nossas necessidades sem violar o princípio do LSP. No entanto, ao avançarmos em nossa leitura encontramos duas informações super importantes.
“…ao longo dos anos, o LSP se transformou em um princípio mais amplo de design de software, aplicável a interfaces e implementações. (…) o LSP é aplicável porque há usuários que dependem de interfaces bem definidas e da capacidade de substituição das implementações destas interfaces”.
Aqui temos presentes dois conselhos importantíssimos que são decorrentes inclusive do título original do famoso artigo de Barbara chamado de “Data Abstraction and Hierarchy”.
Sempre que vamos trabalhar com o design de nossos softwares é importantíssimo que nós façamos a abstração adequada para criarmos nossos contratos. Um contrato (ou uma interface) bem definida significa que não deve estar contaminada com qualquer tipo de implementação de baixo nível.
A hierarquia necessária para a substituição de implementações somente será possível se nossas interfaces sejam abstrações de alto nível generalistas. E devemos nos policiar para criarmos interfaces sem métodos que possam induzir a qualquer tipo de implementação.
Lembra do famoso “contrato”? Quem contrata um “serviço” não precisa saber como ele será feito, tão pouco deverá saber qualquer detalhe de implementação. Porém, em um contrato deve estar claro qual é o resultado esperado.
Lembre-se do conselho da Senhorita Barbara que é muito importante para entendermos seu famoso princípio de Liskov. Reproduzirei parte das conclusões de seu famoso artigo para entendermos que a abstração de dados é importantíssima e em grande medida ela já é feita através do princípio do aberto-fechado, porém, o que ela nos diz é que:
A abstração, e especialmente a abstração de dados, é uma técnica importante para o desenvolvimento de programas que são razoavelmente fáceis de manter e modificar conforme os requisitos mudam. As abstrações de dados são particularmente importantes porque elas escondem coisas complicadas que provavelmente mudarão no futuro. (…)
Concluímos que, embora a abstração de dados seja mais importante, a hierarquia de tipos estende sua utilidade. Além disso, a herança às vezes é necessária para expressar a hierarquia de tipos e, portanto, é um mecanismo útil…” (Barbara Liskov)
No final das contas o que a Bárbara está dizendo é que podemos utilizar a abstração de dados com hierarquia para tornarmos nossos programas mais fáceis de manter, mais organizados e com aproveitamento de código.
Com a correta abstração de dados e com o cuidado com as heranças com a sobrescrita de métodos conscientes poderemos avançar tranquilamente em busca de software de qualidade com manutenção de baixo custo humano, rapidez e eficiência.
Boa leitura!
BrAcInhO
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
