パフォーマンスの変化は、リスコフの代替原則に違反しますか？

私が持っていると言う：

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場合、または基本タイプが仮想であり、デフォルトの実装が1つの複雑さである場合、そのアルゴリズムの複雑さを悪化させるとLSPに違反します。

ソフトウェアのパフォーマンスは、リスコフの代替原理とは関係ありません。

原則は、サブタイプの置換、およびオブジェクトをOOP用語でのみ置換することの動作への影響に関係しています。

の入力と出力はgetThing()両方のケースで同じままであり、低速と高速の両方がオブジェクトを同じ状態にする可能性があります。

Liskov Substitution Principle自体が具体的に言っていることは重要ですか？サブタイプがスーパータイプの消費者の期待に違反する場合、LSPがより制限的であるかどうかに関係なく、それは悪いことのように思われます。

したがって、私の見解では、抽象化の消費者に対するすべての合理的な期待がサブタイプによって満たされるかどうかは、LSPの優れた一般化のようです。

ただし、投稿した例と一般的なJavaインターフェースでは、Thingインターフェースのコンシューマーが高速か低速かの合理的な期待を持っているかどうかは明らかではありません。インターフェースのjavadocsに、どの操作が高速であると約束されているかについての言語が含まれている場合、パフォーマンス上の問題の議論があるかもしれません。しかし、Javaの規則は、さまざまな実装が異なるパフォーマンス特性を持つことを確かにしています。

ボブおじさんは、LSP違反には3者が必要であると述べている非常に似た質問に答えました。

タイプT、サブタイプS、およびTを使用しているがSのインスタンスが与えられているプログラムP

それは言及していないという点で、私は、この質問は、彼は答えた1と同様の構造を有していることを推測するベンチャー企業ですP使っているTを、どのような行動Pのを期待します。

彼の答えはここにあります。（いくつか下にスクロールして、Robert Martinという名前のユーザーからの回答を探す必要があります）