Pelo que entendi, deve-se tomar cuidado quando for realizar uma mudança de metodos da classe erdada para não prejudicar a funcionalidade que deveria funcionar.
Pelo que entendi, deve-se tomar cuidado quando for realizar uma mudança de metodos da classe erdada para não prejudicar a funcionalidade que deveria funcionar.
Oi, Tiago.
Sua interpretação está no caminho certo. Como Desenvolvedor de Software, você percebeu que o Princípio de Substituição de Liskov (LSP) atua como uma garantia de que as extensões de um código não destruam o que já foi construído. Em termos práticos, se temos uma classe pai, qualquer classe filha deve poder ocupar o lugar dela sem que o programa comece a dar erros ou comportamentos inesperados.
Para elevar ainda mais sua percepção técnica, vale notar que muitas vezes quebramos o LSP por tentar forçar uma herança onde ela não cabe. Um exemplo clássico é a relação entre Quadrado e Retângulo: embora na geometria um quadrado seja um tipo de retângulo, na programação, mudar a largura de um quadrado altera também sua altura, o que quebraria a lógica de uma função que espera o comportamento de um retângulo comum. Nesses casos, a composição costuma ser uma escolha mais segura do que a herança.
Conseguiu perceber como esse cuidado que você mencionou ajuda a evitar aqueles "bugs fantasmas" que aparecem quando alteramos algo em uma parte do sistema e ele quebra em outra totalmente diferente?
Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!