As mudanças no desempenho violam o princípio da substituição de Liskov?

Diga que tenho:

interface Thing
{
    GetThing();
}

class FastThing : Thing 
{
    public int GetThing()
    {
        return 1;
    }
}

class SlowThing : Thing
{
    public int GetThing()
    {
        return GetThingFromDatabase();
    }
}

Isso é uma violação do princípio da substituição de Liskov?

Isso realmente depende. Algumas interfaces têm, por exemplo, restrições de complexidade (elas obviamente não podem ser aplicadas programaticamente). O caso mais básico é "GetThing () fornece um int- ou seja, ele pára"; nesse caso, a resposta seria "Não" - ambas as versões do GetThing () param e retornam um int.

Mas muitas interfaces têm garantias de desempenho implícitas ou expressamente declaradas, seja em complexidade ou em tempo fixo. Por exemplo, no padrão C ++, é ilegal implementar a biblioteca com uma chamada de bloqueio, exceto onde o padrão o permitir expressamente.

TL; DR: Não

De acordo com a "Subtipagem Comportamental Usando Invariantes e Restrições" (a formalização do princípio), ela se preocupa principalmente com as propriedades de "segurança" de um tipo de objeto. Propriedades que governam a substituibilidade apenas dentro do contexto das informações de tipo. Um tipo de objeto é ortogonal ao seu desempenho. Portanto, uma diferença de desempenho não é uma violação do Princípio de Substituição de Liskov.

Que garantias a interface oferece? Como GetThingnão dá garantias, os subtipos não precisam respeitá-lo.

Se a interface era algo como GetThingInLinearTimeou se o tipo base é virtual e a implementação padrão é uma complexidade, em seguida, fazendo que a complexidade algorítmica pior seria violar LSP.

O desempenho do software não tem nada a ver com o Princípio de Substituição de Liskov.

O princípio tem a ver com a substituição de subtipos e o impacto comportamental de substituir esse objeto apenas em termos de POO.

A entrada e a saída de getThing()permanecem as mesmas nos dois casos e, lenta e rapidamente, provavelmente colocam os objetos no mesmo estado.

Importa o que o próprio Princípio de Substituição de Liskov diz especificamente? Se um subtipo viola as expectativas do consumidor do supertipo, isso parece uma coisa ruim, independentemente de o LSP ser mais restritivo.

Portanto, na minha opinião, se todas as expectativas razoáveis ​​do consumidor de uma abstração são cumpridas pelo subtipo parece ser uma boa generalização do LSP.

No entanto, no exemplo que você postou e com interfaces Java em geral, não está claro que o consumidor da Thinginterface tenha qualquer expectativa razoável de que deve ser rápida ou lenta. Se os javadocs da interface incluírem linguagem sobre quais operações prometem ser rápidas, pode haver um argumento para um problema com base no desempenho. Mas a convenção Java é certamente que várias implementações têm características de desempenho diferentes.

O tio Bob respondeu a uma pergunta muito semelhante em que afirma que uma violação do LSP exige três partes:

O tipo T, o subtipo S e o programa P que usa T, mas recebem uma instância de S.

Atrevo-me a supor que essa pergunta tenha uma estrutura semelhante à que ele respondeu, na medida em que não menciona o P que está usando o T e que comportamento o P espera.

Você pode encontrar a resposta dele aqui . (Você precisará rolar para baixo alguns e procurar a resposta do usuário chamado Robert Martin)