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

Task 엔터티 목록과 ProjectTask하위 유형 이 있다고 가정 해보십시오 . ProjectTasks상태가 시작됨 인 경우 닫을 수없는 경우 를 제외하고 작업은 언제든지 닫을 수 있습니다 . UI는 시작을 닫는 옵션을 ProjectTask사용할 수 없도록해야 하지만 도메인에는 다음과 같은 보호 조치가 있습니다.

public class Task
{
     public Status Status { get; set; }

     public virtual void Close()
     {
         Status = Status.Closed;
     }
}

public class ProjectTask : Task
{
     public override void Close()
     {
          if (Status == Status.Started) 
              throw new Exception("Cannot close a started Project Task");

          base.Close();
     }
}

이제 Close()작업을 호출 할 ProjectTask때 시작 상태에 있고 기본 작업이 아닌 경우 호출이 실패 할 가능성이 있습니다. 그러나 이것은 비즈니스 요구 사항입니다. 실패해야합니다. 이것이 Liskov 대체 원칙을 위반 한 것으로 간주 될 수 있습니까 ?

예, LSP를 위반 한 것입니다. 리스 코프 치환 원칙은 필요 있음

• 하위 유형에서는 전제 조건을 강화할 수 없습니다.
• 하위 유형에서는 사후 조건을 약화시킬 수 없습니다.
• 상위 유형의 변형은 하위 유형으로 유지되어야합니다.
• 히스토리 제한 사항 ( "히스토리 규칙"). 객체는 그 방법 (캡슐화)을 통해서만 수정 가능한 것으로 간주됩니다. 서브 타입은 수퍼 타입에 존재하지 않는 메소드를 도입 할 수 있기 때문에, 이러한 메소드의 도입은 수퍼 타입에 허용되지 않는 서브 타입의 상태 변경을 허용 할 수 있습니다. 히스토리 제한은이를 금지합니다.

예제에서는 Close()메소드 호출을위한 전제 조건을 강화하여 첫 번째 요구 사항을 위반합니다 .

강화 된 전제 조건을 상속 계층의 최상위 수준으로 가져 와서 고칠 수 있습니다.

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

의 호출이 있음을 명기하여 Close()경우에만 상태에서 유효 CanClose()수익률은 true당신이 사전 조건이 적용 할 Task받는 사람뿐만 아니라 ProjectTaskLSP를 위반 고정 :

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

예. 이것은 LSP를 위반합니다.

내 제안은 CanClose기본 작업 에 방법 / 속성 을 추가 하는 것이므로 모든 작업은이 상태의 작업을 닫을 수 있는지 알 수 있습니다. 이유를 제시 할 수도 있습니다. 그리고에서 가상을 제거하십시오 Close.

내 의견을 바탕으로 :

public class Task {
    public Status Status { get; private set; }

    public virtual bool CanClose(out String reason) {
        reason = null;
        return true;
    }
    public void Close() {
        String reason;
        if (!CanClose(out reason))
            throw new Exception(reason);

        Status = Status.Closed;
    }
}

public ProjectTask : Task {
    public override bool CanClose(out String reason) {
        if (Status != Status.Started)
        {
            reason = "Cannot close a started Project Task";
            return false;
        }
        return base.CanClose(out reason);
    }
}

Liskov 대체 원칙에 따르면 기본 클래스는 프로그램의 바람직한 속성을 변경하지 않고 하위 클래스로 대체 할 수 있어야합니다. ProjectTask닫힐 때만 예외가 발생 하므로 이를 대체하기 위해 프로그램을 그에 맞게 변경해야 ProjectTask합니다 Task. 위반입니다.

그러나 Task서명을 닫을 때 예외가 발생할 수 있다고 서명을 수정 하면 원칙을 위반하지 않을 것입니다.

LSP 위반에는 3 명이 필요합니다. T를 사용하지만 S의 인스턴스가 제공되는 Type T, Subtype S 및 프로그램 P

귀하의 질문에 T (작업) 및 S (프로젝트 작업)가 제공되었지만 P는 제공되지 않았으므로 귀하의 질문은 불완전하고 답변은 자격이 있습니다. 예외를 기대하지 않는 P가 있으면 해당 P에 대해 LSP 위반. 모든 P가 예외를 예상하면 LSP 위반이 없습니다.

그러나, 당신은 할 가 SRP 위반. 작업 상태가 변경 될 수 있다는 사실과 특정 상태의 특정 작업 이 다른 상태로 변경 되어서는 안된다는 정책 은 매우 다른 책임입니다.

• 책임 1 : 작업을 나타냅니다.
• 책임 2 : 작업 상태를 변경하는 정책을 구현하십시오.

이 두 가지 책임은 다른 이유로 바뀌므로 별도의 수업에 있어야합니다. 작업은 작업의 사실과 작업과 관련된 데이터를 처리해야합니다. TaskStatePolicy는 주어진 응용 프로그램에서 작업이 상태에서 상태로 전환되는 방식을 처리해야합니다.

이것은 LSP를 위반 하거나 위반 하지 않을 수 있습니다.

진심으로. 내 말 들어

LSP를 따르는 경우 유형의 ProjectTask객체 Task가 작동 할 것으로 예상되는 유형의 객체가 작동해야 합니다.

코드의 문제점은 유형의 객체가 어떻게 Task동작 할 것인지 문서화하지 않았다는 것 입니다. 코드를 작성했지만 계약은 없습니다. 에 대한 계약을 추가하겠습니다 Task.Close. 내가 추가 한 계약에 따라 ProjectTask.CloseLSP를 따르거나 따르지 않는 코드가 있습니다.

Task.Close에 대한 다음 계약을 감안할 때의 코드 는 LSP를 따르지 ProjectTask.Close 않습니다 .

     // Behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Task.Close에 대한 코드에 대해 다음과 계약을 감안할 ProjectTask.Close 않습니다 LSP를을 따르십시오 :

     // Behaviour: Moves the task to the closed status if possible.
     // If this is not possible, this method throws an Exception
     // and leaves the status unchanged.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

재정의 될 수있는 메소드는 다음 두 가지 방법으로 문서화해야합니다.

• "Behaviour"는 수신자 객체가 Task임을 알고 있지만 어떤 클래스가 직접적인 인스턴스인지 는 모르는 클라이언트가 신뢰할 수있는 것을 문서화합니다 . 또한 서브 클래스의 디자이너에게 어떤 재정의가 합리적이고 합리적이지 않은지를 알려줍니다.

• "기본 동작"은 수신자 객체가 직접 인스턴스라는 것을 알고있는 클라이언트가 신뢰할 수있는 것을 문서화합니다 Task(즉, 사용하는 경우 얻는 것) new Task(). 메소드를 대체하십시오.

이제 다음 관계가 유지되어야합니다.

• S가 T의 하위 유형 인 경우 S의 문서화 된 동작은 T의 문서화 된 동작을 세분화해야합니다.
• S가 T의 하위 유형 인 경우 S의 코드 동작은 문서화 된 T 동작을 세분화해야합니다.
• S가 T의 하위 유형 (또는 같음) 인 경우 S의 기본 동작은 문서화 된 T의 동작을 세분화해야합니다.
• 클래스 코드의 실제 동작은 문서화 된 기본 동작을 개선해야합니다.

Liskov 대체 원칙을 위반하지 않습니다.

Liskov 대체 원칙은 다음과 같이 말합니다.

하자 Q (x)는 객체에 대한 증명 속성 수 X 타입의 T . S 를 T 의 하위 유형 이라고합시다 . q (y) 를 입증 할 수 없도록 S 유형 의 객체 y 가 존재 하는 경우 유형 S 는 Liskov 대체 원칙을 위반합니다 .

하위 유형의 구현이 Liskov 대체 원칙을 위반하지 않는 이유는 매우 간단합니다. Task::Close()실제로 수행하는 작업 에 대해 입증 할 수있는 것은 없습니다 . 물론, ProjectTask::Close()경우에 예외를 throw Status == Status.Started하지만 그렇게 수도 Status = Status.Closed에서와 Task::Close().

예, 위반입니다.

나는 당신에게 당신의 계층 구조가 거꾸로 있다고 제안합니다. 모든 Task것이 가까울 수 없다면에 close()속하지 않습니다 Task. 아마도 당신 CloseableTask은 모두 ProjectTasks구현할 수 없는 인터페이스를 원할 것입니다.

LSP 문제 외에도 예외를 사용하여 프로그램 흐름을 제어하는 ​​것처럼 보입니다 (이 사소한 예외를 잡아서 앱을 중단시키지 않고 사용자 정의 흐름을 수행한다고 가정해야합니다).

TaskState에 대한 State 패턴을 구현하고 상태 객체가 유효한 전환을 관리 할 수있는 좋은 장소 인 것 같습니다.

LSP 및 계약에 의한 디자인과 관련된 중요한 사항이 누락되었습니다. 전제 조건에서 전제 조건을 충족시키는 책임은 호출자입니다. DbC 이론에서 호출 된 코드는 전제 조건을 검증하지 않아야합니다. 계약은 작업을 닫을 수있는시기 (예 : CanClose가 True를 반환)를 지정한 다음 호출 코드는 Close ()를 호출하기 전에 사전 조건이 충족되는지 확인해야합니다.

예, LSP를 명백히 위반하는 것입니다.

어떤 사람들은 기본 클래스에서 서브 클래스가 예외를 던질 수 있다고 명시 적으로 만드는 것이 이것을 받아 들일 수 있다고 주장하지만, 나는 그것이 사실이라고 생각하지 않습니다. 기본 클래스에서 무엇을 문서화하거나 코드를 어떤 추상화 수준으로 이동하든 "시작된 프로젝트 작업을 닫을 수 없습니다"부분을 추가하기 때문에 하위 클래스에서 사전 조건이 여전히 강화됩니다. 이것은 해결 방법으로 해결할 수있는 것이 아니며 LSP를 위반하지 않는 다른 모델이 필요합니다 (또는 "전제 조건을 강화할 수 없음"제약 조건에서 완화해야 함).

이 경우 LSP 위반을 피하려면 데코레이터 패턴을 사용해보십시오. 잘 모르겠습니다.