성능 변화가 Liskov 대체 원칙을 위반합니까?

내가 가지고 있다고 말하십시오 :

interface Thing
{
    GetThing();
}

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

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

이것이 Liskov 대체 원칙을 위반합니까?

정말 달려 있습니다. 예를 들어 일부 인터페이스에는 복잡성 제약 조건이 있습니다 (프로그래밍 방식으로 적용 할 수 없음). 가장 기본적인 경우는 "GetThing ()이int . 즉, 정지합니다"입니다.이 경우 대답은 "아니오"입니다. 두 버전의 GetThing ()이 정지되고 int가 반환됩니다.

그러나 많은 인터페이스가 복잡하거나 일정한 시간에 성능 보증을 암시하거나 명시 적으로 언급했습니다. 예를 들어, C ++ 표준에서 표준이 명시 적으로 허용하는 경우를 제외하고 차단 호출로 라이브러리를 구현하는 것은 불법입니다.

TL; DR : 아니요

에 따르면 "불변 및 제약 조건을 사용하여 행동 하위 유형" (원리의 형식화) 그것은 주로이 유형을 객체의 "안전"속성과 관련됩니다. 유형 정보의 맥락 내에서만 대체 가능성을 관리하는 속성. 객체 유형은 성능과 직교합니다. 따라서 성능 차이는 Liskov 대체 원칙을 위반하지 않습니다.

인터페이스는 어떤 보증을합니까? GetThing보증을하지 않기 때문에 하위 유형은이를 준수 할 필요가 없습니다.

인터페이스가 같은 것을 있었다면 GetThingInLinearTime경우 또는 기본 유형은 가상이며, 기본 구현은 더 나쁜 알고리즘의 복잡성이 것을 만드는 하나의 복잡성 것 LSP를 위반.

소프트웨어의 성능은 Liskov 대체 원칙과 아무 관련이 없습니다.

원칙은 하위 유형의 대체 및 OOP 용어로만 해당 개체를 대체 할 때의 행동 영향과 관련이 있습니다.

입력과 출력은 getThing()두 경우 모두 동일하게 유지되며 느리고 빠른 경우 모두 객체를 동일한 상태로 만들 수 있습니다.

Liskov 대체 원칙 자체가 구체적으로 말하는 것이 중요합니까? 하위 유형이 상위 유형 소비자의 기대를 위반하면 LSP가 더 제한적인지 여부에 관계없이 나쁜 것으로 보입니다.

내 생각에, 추상화 소비자에 대한 모든 합리적인 기대가 하위 유형에 의해 충족되는지 여부는 LSP의 좋은 일반화 인 것 같습니다.

그러나 게시 한 예제와 일반적으로 Java 인터페이스를 사용하는 경우 Thing인터페이스 소비자 가 빠르거나 느려 야하는지에 대한 합리적인 기대가 있는지 명확하지 않습니다 . 인터페이스의 javadocs에 어떤 오퍼레이션이 빠른지에 관한 언어가 포함되어 있다면, 성능상의 문제에 대한 논거가있을 수 있습니다. 그러나 Java 규칙 은 다양한 구현에서 다른 성능 특성을 갖는 것이 확실합니다.

Bob 아저씨는 LSP 위반에 3 명이 필요하다는 매우 비슷한 질문에 답변했습니다.

T를 사용하지만 S의 인스턴스가 제공되는 유형 T, 하위 유형 S 및 프로그램 P

이 질문는 언급하지 않는다는 점에서 그는에 응답 한 것과 유사한 구조를 가지고 내가 추측 벤처 것입니다 P 사용하고 T를 어떤 거동 P의 예상하는합니다.

그의 대답은 여기에서 찾을 수 있습니다 . (아래로 스크롤하여 Robert Martin이라는 사용자의 답변을 찾아야합니다.)