Please enable JavaScript.
Coggle requires JavaScript to display documents.
Princípio da Substituição de Liskov, Essas perguntas são respondidas pelo…
Princípio da Substituição de Liskov
Os principais mecanismos do Princípio do Aberto/Fechado são a
abstração
e o
polimorfismo
, que são suportados pela
herança
em linguagens estaticamente tipadas.
Quais regras governam o uso da herança?
Quais são as armadilhas que nos farão criar hierarquias que não obedecem ao OCP?
Quais são as características das melhores hierarquias de classe?
Os
subtipos
devem ser substituíveis pelos seus
tipos de base
.
Suponha que tenhamos uma função
f
que recebe como argumento uma referência para uma
classe base B
. Suponha também que, quando passado para
f
disfarçada de
B
, alguma
classe derivada D
faz
f
se comportar incorretamente. Então,
D viola o LSP
.
Quando a
criação de uma classe derivada
nos obriga a fazer
mudanças na classe base
, isso frequentemente significa que o projeto é imperfeito.
Violar o LSP frequentemente resulta no uso de
verificação de tipo
em tempo de execução de uma maneira que viola inteiramente o OCP. Muitas vezes, uma instrução
if
ou um encadeamento
if/else
é usado para
determinar o tipo de um objeto
, para que o comportamento correto possa ser selecionado.
Uma violação do LSP é uma
violação latente do OCP
.
Um modelo
visto isoladamente
não pode ser validado de forma significativa. A validade de um modelo só pode ser expressa
em termos de seus clientes
.
Como você sabe o que os seus clientes realmente esperarão? Existe uma técnica para tornar essas suposições razoáveis explícitas e, com isso, forçar o LSP. Tal técnica é denominada
projeto por contrato
(
DBC - Design By Contract
).
O contrato informa ao autor de qualquer código cliente sobre os
comportamentos
com os quais pode contar.
O contrato é especificado pela declaração de
pré-condições
e
pós-condições
para cada método. As
pré-condições
devem ser
verdadeiras para que o método execute
. Ao ser concluído, o método garante que as
pós-condições
são verdadeiras.
Os contratos também podem ser especificados escrevendo-se
testes de unidade
. Testando completamente o comportamento de uma classe, os testes de unidade tornam claro o comportamento da classe.
A nova declaração de uma rotina em uma classe derivada só pode substituir a
pré-condição
original por outra
igual ou mais fraca
, e a
pós-condição
original, por uma
igual ou mais forte
.
É melhor
adiar todas as violações
do LSP (menos as mais evidentes) até que se tenha sentido o
mau cheiro da fragilidade relacionada
.
Existem raras ocasiões em que é melhor aceitar uma falha sutil em um comportamento polimórfico do que tentar manipular o projeto para obter completa compatibilidade com o LSP. Aceitar o compromisso, em vez de buscar a perfeição, é uma decisão de engenharia.
Podemos afirmar que, se todas as classes em um conjunto de classes aceitam uma responsabilidade comum, elas devem herdar essa responsabilidade de uma superclasse comum.
Se ainda não existe uma superclasse comum, crie uma e mova as responsabilidades comuns para ela. Afinal, tal classe é comprovadamente útil.
Essas perguntas são respondidas pelo
Princípio da Substituição de Liskov
Criado por Barbara Liskov em 1988
Fatoração
por Rebecca Wirfs-Brock, Brian Wilkerson e Lauren Wiener