绩效变化是否违反了《里斯科夫换人原则》？

说我有：

interface Thing
{
    GetThing();
}

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

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

这是否违反了《里斯科夫换人原则》？

这真的取决于。例如，某些接口具有复杂性约束（显然，这些约束不能通过编程方式强制执行）。最基本的情况是“ GetThing（）给出一个int-即它停止”，在这种情况下，答案将是“否”-GetThing（）的两个版本都停止并返回一个int。

但是，无论是在复杂性还是在固定时间内，许多接口都隐含或明确声明了性能保证。例如，在C ++标准中，除非标准明确允许，否则使用阻塞调用来实现该库是非法的。

TL; DR：否

根据“使用不变式和约束的行为子类型 化” （原则的形式化），它主要涉及对象类型的“安全性”属性。仅在类型信息的上下文中控制可替换性的属性。对象类型与其性能正交。因此，性能上的差异并不违反《里斯科夫替代原则》。

接口能保证什么？以来GetThing不做任何保证，因此子类型不需要尊重它。

如果接口是类似的，GetThingInLinearTime或者基本类型是虚拟的，并且默认实现是一种复杂性，那么使算法复杂性恶化将违反LSP。

该软件的性能与Liskov替代原理无关。

该原则与子类型的替换有关，以及仅用OOP术语替换该对象的行为影响。

在getThing()这两种情况下，的输入和输出保持相同，并且慢速和快速都可能使对象处于相同状态。

里斯科夫替代原则本身具体说的话是否重要？如果子类型违反了超类型消费者的期望，那么不管LSP是否更具限制性，这似乎都是一件坏事。

因此，在我看来，子类型是否满足抽象消费者的所有合理期望似乎是LSP的一个很好的概括。

但是，在您发布的示例中，通常使用Java接口，尚不清楚Thing接口的使用者是否对它应该是快还是慢有任何合理的期望。如果接口的javadocs包含有关承诺快速进行哪些操作的语言，则可能出于性能方面的考虑而存在问题。但是Java约定无疑是使各种实现具有不同的性能特征。

Bob叔叔回答了一个非常类似的问题，他说违反LSP需要3个参与方：

类型T，子类型S和使用T但被赋予S实例的程序P。

我冒昧猜测，这个问题具有相似的结构，他回答，因为它没有提及的一个P目前正使用的牛逼，什么行为P的期望。

你可以在这里找到他的答案。（您需要向下滚动一些并寻找名为Robert Martin的用户的答案）