Início / coding / Perguntas / 79340103
Accepted
magva
Asked: 2025-01-09 00:53:50 +0800 CST

Como o Princípio de Substituição de Liskov funciona com especialização de tipos em implementações concretas de classes abstratas?

  • 772

Suponha que queremos modelar diferentes tipos de comida; pizzas e tortas. Tanto pizzas quanto tortas têm um tipo de cobertura, mas suas coberturas são diferentes.

Implementamos uma classe abstrata Baked, e duas classes concretas Pizzae Pie. Também implementamos uma classe abstrata Topping, e duas classes concretas PizzaToppinge PieTopping.

Por definição, qualquer implementação concreta de Bakeddeve ter um Topping, então Bakeddeve ter um atributo do tipo Topping. Além disso, esse atributo de cobertura específico deve ser do tipo PizzaToppingem Pizza, e PieToppingem Pie.

Se entendi corretamente a resposta anterior , o LSP é violado nessa situação, porque se deixarmos de lado o fato de que Bakedé abstrato, seria possível instanciar um Bakedcontendo a PieTopping, mas isso não é possível se substituirmos Bakedpor Pizza.

Minha pergunta é: existe uma maneira de implementar esse modelo sem violar o LSP?

oop

2 respostas

  1. Best Answer

    Abordarei primeiro a preocupação imediata, mas depois terei algo a dizer sobre as suposições gerais implícitas na pergunta.

    Usando pseudocódigo semelhante ao C#, você poderia definir Pizzaassim:

    public class Pizza : Baked
{
    private readonly PizzaTopping topping;

    public Pizza(PizzaTopping topping) : this(topping)
    {
        // Consider saving `topping` to a private or protected class field
        // so that you don't have to downcast any `topping` field from the
        // base class:
        this.topping = topping;
    }
}

    Depois faça o mesmo para a Pieturma.

    Isso pode agora levantar a questão natural: por que ter uma Toppingclasse abstrata?

    De fato, com base nas informações do OP, não temos informações suficientes para responder a essa pergunta. ToppingDefine algum comportamento polimórfico que classes derivadas podem implementar? Se sim, qual é? E alguma dessas coisas se relaciona com o Princípio de Substituição de Liskov (LSP)?

    É lamentável que universidades, bootcamps e cursos online continuem insistindo em ensinar design orientado a objetos a partir da noção de que se trata de modelar objetos concretos no mundo real. Pode ser assim que o Simula começou, mas raramente acaba sendo a melhor maneira de estruturar código em linguagens como Java ou C#.

    O LSP não é sobre estrutura, mas sobre comportamento. O entendimento moderno do LSP é realmente capturado muito bem pela entrada da Wikipedia , que discute que

    • pré-condições não podem ser reforçadas no subtipo
    • pós-condições não podem ser enfraquecidas no subtipo
    • invariantes não podem ser enfraquecidos no subtipo

    Tudo isso (pré-, pós-condições e invariantes) são, no sentido da visão de OOD de Bertrand Meyer , parte do contrato de um tipo . Apenas o designer de um tipo pode dizer qual é o contrato, e como o OP não afirma isso, não podemos realmente responder se um determinado design viola ou não o LSP.

    • 1

  2. Vamos tentar analisar cuidadosamente sua pergunta.

    Princípio de substituição de Liskov (LSP):

    Se uma classe S for uma subclasse da classe T, um objeto da classe T deve ser substituível por um objeto da classe S sem alterar as propriedades desejáveis ​​do programa.

    No seu caso, isso significa o seguinte: se você tiver algum código (por exemplo, um método f) que recebe Bakedcomo parâmetro, então se você passar instância de Pizzaou Piecomo parâmetro para ele, ele deverá funcionar corretamente.

    Segue-se dessa afirmação que não podemos falar sobre conformidade com o LSP sem entender o método f, bem como as implementações de métodos Bakedem classes Pizzae Pie. Porque essa informação afeta diretamente o entendimento da "correção do programa".

    • 1

relate perguntas