Utilidade da propriedade de substituição do Princípio de Substituição de Liskov

O princípio de substituição de Liskov afirma que um pedaço de código deve permanecer correto se uma superclasse for substituída por sua subclasse

Se essa fosse a única coisa que o princípio declarava, dificilmente faria sentido perguntar por que nos importamos com isso. Considere o que o oposto desse princípio significaria: Que um pedaço de código não deveria permanecer correto se uma superclasse fosse substituída por sua subclasse?

Quem iria querer que seu software estivesse incorreto?

O que o Princípio de Substituição de Liskov (LSP) realmente diz é que uma subclasse pode ampliar pré-condições e restringir pós-condições, mas não o contrário.

Isso faz muito sentido, se você pensar a respeito. Considere um método simples que recebe um inteiro como entrada.

void Foo(int i)

Se a superclasse declara que todo inteiro ié válido, então o que aconteceria se uma subclasse apertasse a pré-condição? Você pode, por exemplo, implementar uma subclasse que divide algum número por i. Se você fizer isso, no entanto, o valor de entrada 0agora causaria um erro de divisão por zero na subclasse, e esse erro não aconteceria na superclasse.

O código do cliente depende do contrato publicado pela superclasse, pois não sabe com qual subclasse pode estar interagindo.

Como exemplo oposto, imagine que a superclasse tem uma pré-condição que diz que inão deve ser 0. Isso significa que nenhum cliente bem-comportado vai chamar o Foométodo com um 0argumento. Se você então implementar uma subclasse que pode manipular 0, nenhum dano é causado. Assim, você pode ampliar a pré-condição, mas não restringi-la.

Considerações semelhantes se aplicam a pós-condições, apenas na direção oposta. Aqui, uma subclasse pode apertar uma pós-condição, mas não alargá-la.

Você pode ver alguns exemplos realistas de C# no meu artigo O Princípio de Substituição de Liskov como um profunctor .

A violação do princípio de substituição de Liskov leva à execução incorreta do programa.

Aqui está um exemplo de tal violação:

class Rectangle {
    private int width;
    private int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int area() {
        return width * height;
    }
}

class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(int height) {
        super.setWidth(height);
        super.setHeight(height);
    }
}

// This code will not work correctly for instance of Square
void test(Rectangle rectangle) {
    rectangle.setWidth(5);
    rectangle.setHeight(10);

    assertEquals(50, rectangle.area());
}