인터페이스만으로는 객체의 행동에 관한 다양한 관점을 전달하기 어렵다. 그러기에 계약에 의한 설계를 이용하여 협력에 필요한 다양한 제약과 부수효과를 명시적으로 정의하고 문서화 할 수 있다.

계약

• 각 계약 당사자는 계약으로부터 이익을 기대하고 이익을 얻기 위해 의무를 이행한다.
• 각 계약 당사자의 이익과 의무는 계약서에 문서화 한다.

계약에 의한 설계

우리는 메서드의 이름과 매개변수의 이름을 통해 오퍼레이션이 클라이언트에게 어떤 것을 제공하려고 하는지를 충분히 설명할 수 있다. 의도를 드러내는 인터페이스를 만들면 오퍼레이션의 시그니처만으로도 어느 정도까지는 클라이언트와 서버가 협력을 위해 수행해야 하는 제약조건을 명시 할 수 있다.

계약에 의한 설계를 구성하는 세 가지 요소

1. 사전조건
   1. 메서드가 호출되기 위해 만족돼야 하는 조건. 이것은 메서드의 요구사항을 명시한다. 사전조건이 만족되지 않을 경우 메서드가 실행되서는 안 된다. 사전조건을 만족시키는 것은 메서드를 실행하는 클라이언트의 의무다.
2. 사후조건
   1. 메서드가 실행된 후에 클라이언트에게 보장해야 하는 조건. 클라이언트가 사전조건을 만족시켰다면 메서드는 사후조건에 명시된 조건을 만족시켜야 한다. 만약 클라이언트가 사전조건을 만족시켰는데도 사후조건을 만족시키지 못한 경우에는 클라이언트에게 예외를 던져야 한다. 사후조건을 만족시키는 것은 서버의 의무다.
3. 불변식
   1. 항상 참이라고 보장되는 서버의 조건. 메서드가 실행되는 도중에는 불변식을 만족시키지 못할 수도 있지만 메서드를 실행하기 전이나 종료된 후에 불변식은 항상 참이어야 한다.

계약에 의한 설계와 서브타이핑

리스코프 치환은 서브타입의 인스턴스가 슈퍼타입을 대체하더라도 협력에 지장이 없어야 한다는 것을 의미

리스코프 치환 원칙의 두가지 규칙

1. 협력에 참여하는 객체에 대한 기대를 표현하는 계약 규칙
2. 교체 가능한 타입과 관련된 가변성 규칙

계약 규칙은 슈퍼타입과 서브타입 사이의 사전조건, 사후조건, 불변식에 대해 서술할 수 있는 제약에 관한 규칙이다.

• 서브타입에 더 강력한 사전조건을 정의할 수 없다. 약화된 사전조건은 가능
• 서브타입에 더 완화된 사후조건을 정의할 수 없다. 강화된 사후조건은 가능
• 슈퍼타입의 불변식은 서브타입에서도 반드시 유지돼야 한다.