36, 37일차 - 계약에 의한 설계

2023.09.18 MON

460p ~ 482p

 

35일차 내용 ⬇️

2023.09.15 - [개발 서적 기록/오브젝트_조영호] - 35일차 - 상속의 목적 : 서브클래싱 & 서브타이핑 그리고 ISP & LSP

35일차 - 상속의 목적 : 서브클래싱 & 서브타이핑 그리고 ISP & LSP

---

계약에 의한 설계 Design By Contract

클라이언트와 서버 간 협력을, 의무 obligation과 이익 benefit으로 구성된 계약의 관점에서 표현한 것이다.

 

사전 조건 precondition, 사후 조건 postcondition, 클래스 불변식 class invariant 세가지 요소로 구성된다.

• 사전 조건 : 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야하는 조건
• 사후 조건 : 메서드가 실행된 후에 서버가 클라이언트에게 보장해야하는 조건
• 클래스 불변식 : 메서드 실행 전과, 실행 후에, 인스턴스가 만족시켜야하는 조건

LSP와 계약에 의한 설계

LSP에 대해서, 서브타입이 LSP를 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 계약을 준수해야한다. 슈퍼타입은 이 계약을 준수할 때만 정상적으로 협력할 수 있다.

 

LSP는 서브타입이 슈퍼타입을 대체할 수 있어야하고, 클라이언트는 대체되더라도 그 차이를 알 수 없이 협력해야한다.

 

이때, 자식 클래스가 부모 클래스를 대체할 수 있을 때만 서브 타입이라고 할 수 있다. 단순 코드 재사용을 위해서 상속을 사용했다면 서브 타입이 아닌 서브 클래스가 된다.

이런 조건을 충족시키도록해 자식 클래스를 서브 타입으로 만들고 싶다면, 아래의 사전/사후 조건에 대한 제약을 지켜야한다.

• 서브타입에 더 강력한 사전조건을 정의할 수 없다.
• 서브타입에 슈퍼타입과 같거나, 더 약한 사전조건을 정의할 수 있다.
  • 클라이언트는 이미 자신의 의무를 충실히 이행하고 있는 것으로 판단하므로 기존 협력에 영향을 미치지 않기 때문이다.
• 서브타입에 슈퍼타입과 같거나, 더 강한 사후조건을 정의할 수 있다.
  • 클라이언트가 슈퍼 타입과 체결한 계약을 위반하지 않기 때문이다.
• 서브타입에 더 약한 사후 조건을 정의할 수 없다.
  • 클라이언트에게 반환된 결과가 더 약한 조건 하에 생성되었기에, 기존에 알던 계약이 깨지기 때문이다.

일관성 있는 협력

유사한 기능을 구현하기 위해서 유사한 협력 패턴을 사용하라.

객체들의 협력이 전체적으로 일관성 있는 유사한 패턴을 따른다면, 시스템을 이해하고 확장하기 위해서 요구되는 부담을 크게 줄일 수 있다.

코드가 유사하게 느껴지면, 새로운 코드라도 직관적으로 읽을 수 있다.

---

클래스 불변식

인스턴스 생명주기 전반에 걸쳐 지켜져야 하는 규칙을 명세한다.

 

클래스의 모든 인스턴스가 생성된 후에, 클래스 불변식을 만족해야한다.

즉, 클래스에 정의된 모든 생성자는 불변식을 준수해야 한다.

 

클라이언트에 의해 호출 가능한 모든 메서드에 의해, 클래스 불변식을 따라야한다.

메서드가 실행되는 중에는 객체의 상태가 불안정한 상태로 빠질 수 있다. 따라서 메서드 실행 중에는 불변식을 만족하지 않아도 된다.

하지만, 메서드 실행 전과 메서드 종료 후에는 항상 불변식을 만족하는 상태가 유지되어야한다.

 

예제 - Contract.Invariant 메서드를 이용해 불변식을 정의

public class Screening
{
    private Movie movie;
    private int sequence;
    private DateTime whenScreened;
    
    [ContractInvariantMethod]
    private void Invariant() {
        Contract.Invariant(movie != null);
        Contract.Invariant(sequence >= 1);
        Contract.Invariant(whenScreened > DateTime.Now);
    }
}