O que pode dar errado se o princípio da substituição de Liskov for violado?

Eu estava seguindo esta questão altamente votada sobre possível violação do princípio da substituição de Liskov. Sei qual é o princípio da Substituição de Liskov, mas o que ainda não está claro em minha mente é o que pode dar errado se eu, como desenvolvedor, não pensar sobre o princípio ao escrever código orientado a objetos.

Eu acho que está muito bem afirmado nessa questão, que é uma das razões pelas quais foi votado com tanta ênfase.

Agora, ao chamar Close () em uma tarefa, há uma chance de a chamada falhar se for uma ProjectTask com o status iniciado, quando não ocorreria se fosse uma tarefa base.

Imagine se você quiser:

public void ProcessTaskAndClose(Task taskToProcess)
{
    taskToProcess.Execute();
    taskToProcess.DateProcessed = DateTime.Now;
    taskToProcess.Close();
}

Nesse método, ocasionalmente a chamada .Close () é acionada. Portanto, agora, com base na implementação concreta de um tipo derivado, é necessário alterar a maneira como esse método se comporta da maneira como esse método seria escrito se a Tarefa não tivesse subtipos que pudessem ser entregue a esse método.

Devido a violações de substituição liskov, o código que usa seu tipo precisará ter conhecimento explícito do funcionamento interno dos tipos derivados para tratá-los de maneira diferente. Isso une fortemente o código e geralmente dificulta o uso consistente da implementação.

Se você não cumprir o contrato que foi definido na classe base, as coisas podem falhar silenciosamente quando você obtém resultados que estão fora.

LSP nos estados da wikipedia

• As pré-condições não podem ser reforçadas em um subtipo.
• As pós-condições não podem ser enfraquecidas em um subtipo.
• Invariantes do supertipo devem ser preservados em um subtipo.

Se alguma dessas opções não for válida, o chamador poderá obter um resultado que não espera.

Considere um caso clássico dos anais das perguntas da entrevista: você derivou o Circle da Ellipse. Por quê? Porque um círculo é uma elipse, é claro!

Exceto ... ellipse tem duas funções:

Ellipse.set_alpha_radius(d)
Ellipse.set_beta_radius(d)

Claramente, eles devem ser redefinidos para o Círculo, porque um Círculo tem um raio uniforme. Você tem duas possibilidades:

1. Depois de chamar set_alpha_radius ou set_beta_radius, ambos são configurados para a mesma quantidade.
2. Depois de chamar set_alpha_radius ou set_beta_radius, o objeto não é mais um círculo.

A maioria dos idiomas OO não suporta o segundo, e por uma boa razão: seria surpreendente descobrir que seu círculo não é mais um círculo. Portanto, a primeira opção é a melhor. Mas considere a seguinte função:

some_function(Ellipse byref e)

Imagine que alguma função_ chame e.set_alpha_radius. Mas como e era realmente um círculo, surpreendentemente também possui seu raio beta.

E aqui reside o princípio da substituição: uma subclasse deve ser substituída por uma superclasse. Caso contrário, coisas surpreendentes acontecem.

Nas palavras dos leigos:

Seu código terá muitas cláusulas CASE / switch por todo o lado.

Cada uma dessas cláusulas CASE / switch precisará de novos casos adicionados de tempos em tempos, o que significa que a base de código não é tão escalável e sustentável quanto deveria.

O LSP permite que o código funcione mais como hardware:

Você não precisa modificar o seu iPod porque comprou um novo par de alto-falantes externos, já que os antigos e os novos externos respeitam a mesma interface, eles são intercambiáveis ​​sem que o iPod perca a funcionalidade desejada.

para dar um exemplo da vida real com o UndoManager do java

herda de AbstractUndoableEditcujo contrato especifica que possui 2 estados (desfeitos e refeitos) e pode alternar entre eles com chamadas únicas para undo()eredo()

no entanto, o UndoManager possui mais estados e atua como um buffer de desfazer (cada chamada undodesfaz algumas, mas não todas as edições, enfraquecendo a pós-condição)

isso leva à situação hipotética em que você adiciona um UndoManager a um CompoundEdit antes de chamar e end()depois desfazer o CompoundEdit fará com que ele chame undo()cada edição depois de deixar suas edições parcialmente desfeitas

Eu rolei o meu próprio UndoManagerpara evitar isso (eu provavelmente deveria renomeá-lo para UndoBufferembora)

Exemplo: você está trabalhando com uma estrutura de interface do usuário e cria seu próprio controle de interface do usuário personalizado subclassificando a Controlclasse base. A Controlclasse base define um método getSubControls()que deve retornar uma coleção de controles aninhados (se houver). Mas você substitui o método para realmente retornar uma lista de datas de nascimento dos presidentes dos Estados Unidos.

Então, o que pode dar errado com isso? É óbvio que a renderização do controle falhará, pois você não retorna uma lista de controles conforme o esperado. Provavelmente a interface do usuário falhará. Você está violando o contrato ao qual as subclasses de Controle devem aderir.

Você também pode vê-lo do ponto de vista da modelagem. Quando você diz que uma instância da classe Atambém é uma instância da classe, Bimplica que "o comportamento observável de uma instância da classe Atambém pode ser classificado como comportamento observável de uma instância da classe B" (Isso só é possível se a classe Bfor menos específica do que classe A.)

Portanto, violar o LSP significa que há alguma contradição no seu design: você está definindo algumas categorias para seus objetos e depois não as respeita em sua implementação, algo deve estar errado.

Como fazer uma caixa com uma etiqueta: "Esta caixa contém apenas bolas azuis" e depois jogar uma bola vermelha nela. Qual é o uso de uma etiqueta desse tipo se ela mostra informações incorretas?

Herdei recentemente uma base de código que contém alguns dos principais violadores de Liskov. Em aulas importantes. Isso me causou enormes quantidades de dor. Deixe-me explicar o porquê.

Eu tenho Class A, que deriva Class B. Class Ae Class Bcompartilhe várias propriedades que Class Asubstituem sua própria implementação. Definir ou obter uma Class Apropriedade tem um efeito diferente de definir ou obter exatamente a mesma propriedade Class B.

public Class A
{
    public virtual string Name
    {
        get; set;
    }
}

Class B : A
{
    public override string Name
    {
        get
        {
            return TranslateName(base.Name);
        }
        set
        {
            base.Name = value;
            FunctionWithSideEffects();
        }
    }
}

Deixando de lado o fato de que essa é uma maneira absolutamente terrível de fazer a tradução no .NET, existem vários outros problemas com esse código.

Nesse caso, Nameé usado como um índice e uma variável de controle de fluxo em vários locais. As classes acima estão espalhadas por toda a base de código, tanto na forma bruta quanto na derivada. Violar o princípio de substituição de Liskov neste caso significa que eu preciso conhecer o contexto de cada chamada para cada uma das funções que levam a classe base.

O código usa objetos de ambos Class Ae Class B, portanto, não posso simplesmente tornar Class Aabstrato para forçar as pessoas a usar Class B.

Existem algumas funções utilitárias muito úteis que operam Class Ae outras funções utilitárias muito úteis que operam Class B. Idealmente, eu gostaria de ser capaz de usar qualquer função de utilitário que pode operar em Class Aon Class B. Muitas das funções que aceitam um Class Bpoderiam facilmente aceitar um, Class Ase não fosse pela violação do LSP.

O pior de tudo é que esse caso em particular é realmente difícil de refatorar, pois todo o aplicativo depende dessas duas classes, opera nas duas classes o tempo todo e quebraria de centenas de maneiras se eu mudar isso (o que vou fazer) de qualquer forma).

O que terei que fazer para corrigir isso é criar uma NameTranslatedpropriedade, que será a Class Bversão da Namepropriedade e muito, muito cuidadosamente, alterar todas as referências à Namepropriedade derivada para usar minha nova NameTranslatedpropriedade. No entanto, ao errar uma dessas referências, o aplicativo inteiro pode explodir.

Dado que a base de código não possui testes de unidade, é quase o cenário mais perigoso que um desenvolvedor pode enfrentar. Se eu não alterar a violação, tenho que gastar uma quantidade enorme de energia mental acompanhando que tipo de objeto está sendo operado em cada método e, se eu corrigir a violação, poderia fazer o produto inteiro explodir em um momento inoportuno.

Se você quiser sentir o problema de violar o LSP, pense no que acontece se você tiver apenas .dll / .jar da classe base (sem código fonte) e precisar criar uma nova classe derivada. Você nunca pode concluir esta tarefa.