Liskov 대체 원칙은 인터페이스를 구현하는 클래스에도 적용됩니까?

LSP는 클래스가 기본 클래스를 대체 할 수 있어야하는데 파생 클래스와 기본 클래스는 의미 적으로 동일해야합니다.

그러나 LSP는 인터페이스를 구현하는 클래스에도 적용됩니까? 다시 말해서, 클래스에 의해 구현 된 인터페이스 메소드 가 사용자가 예상 한 것과 의미 적으로 다른 경우, 이것이 LSP의 위반으로 간주됩니까?

design-patterns design-principles liskov-substitution

— 사용자 1483278
소스

예. 인터페이스, 추상 클래스, 전체 클래스 인 경우 LSP를 위반하는 것과 정확히 동일한 이유와 결과는 중요하지 않습니다. LSP는 소비자가 귀하의 유형을 일반적인 방식으로 취급 할 수 있도록 기대치를 설정하고 충족시키는 것입니다.

— Jimmy Hoffa

전반적으로 (차이를 알고 있지만 여기서 일반화하고 있습니다) 인터페이스는 순수한 추상 클래스 (C ++ 용어)와 다소 유사하므로 Liskov는 인터페이스와 인터페이스를 구현하는 클래스에 적용해야합니다.

— Jesse C. Slicer

NB LSP의 공식 나는 파생 클래스와 기본 클래스가 아닌 하위 유형에 대해 잘 알고 있습니다. 이유는 상속과 관련된 것이 아니며 다른 유형의 하위 유형에도 적용되기 때문입니다.

만약 클래스에 의해 구현 된 인터페이스 메소드 가 사용자가 기대하는 것과 의미 적으로 다른 경우, 이것이 LSP의 위반으로 간주됩니까?

구현이 인터페이스의 변형 및 메소드의 사전 및 사후 조건을 통해 문서화 된 동작과 의미 적으로 다른 경우, 대답은 "예"이며 LSP를 위반하는 것입니다. 이 원칙은 추상화 측면이 클래스 형태로 존재하지 않아도 추상화 및 구현에 대한 규칙을 설정합니다.

그러나 사용자가 기대 하는 것에 대해 이야기 하면 대답은 "반드시"는 아닙니다. 사용자에게는 잘못된 기대가있을 수 있습니다.

— Dasblinkenlight
소스

"구현이 인터페이스의 변형을 통해 문서화 된 동작과 의미 적으로 다른 경우" "인터페이스의 변형"이 의미하는 바를 자세히 설명 할 수 있습니까?

— user1483278

@ user1483278 다음은 유형 불변에 대한 기사 입니다. 이 기사에서는이를 "클래스 불변량"이라고 부르지 만 설명은 인터페이스에도 적용됩니다. 불변은 건설시 설정되고 인스턴스 수명 동안 유지되는 조건입니다. 인터페이스는 속성을 갖는 경우, 예를 들어, Name로 설정할 수 없습니다 null다음 obj.Name != null것으로 알려져 불변 하는 인터페이스.

— dasblinkenlight

일반적으로 불변이 논의되면 불변이 객체의 전체 수명 동안 유지되는지 확인하기 위해 코드를 작성할 수 있습니다. 그러나 불변 인을 일반 영어로 구두로 묘사하는 것이 일반적으로 더 간단합니다.

— rwong