부록 A: 계약에 의한 설계

[fkdl0048]

계약에 의한 설계

6장에서 설명한 원칙대로 의도를 드러내도록 인터페이스를 다듬고 명령과 쿼리를 분리했더라도 명령으로 인해 발생하는 부수효과를 명확하게 표현하는 데는 한계가 있다. 주석으로 부수효과를 서술하는 것도 가능은 하겠지만 파급효과를 명확하게 전달하기는 어렵다.

물론 메서드의 구현이 단순하다면 내부를 살펴보는 것만으로도 부수효과를 쉽게 이해할 수 있을 것이다. 하지만 구현이 복잡하고 부수효과를 가진 다수의 메서드들을 연이어 호출하는 코드를 분석하는 경우에는 실행결과를 예측하기가 어려울 수밖에 없다.

여기서 말하고 싶은 것은 결국은 인터페이스만으로는 객체의 행동에 관한 다양한 관점을 전달하기 어렵다는 것이다. 우리에게 필요한 것은 명령의 부수효과를 쉽고 명확하게 표현할 수 있는 커뮤니케이션 수단이다. 이 시점이 오면 **계약에 의한 설계(Design by Contract, DBC)**가 주는 혜택으로 눈으 돌릴 때가 된 것이다.

계약에 의한 설계를 사용하면 협력에 필요한 다양한 제약과 부수효과를 명시적으로 정의하고 문서화할 수 있다. 클라이언트 개발자는 오퍼레이션의 구현을 살펴보지 않더라도 객체의 사용법을 쉽게 이해할 수 있다. 클라이언트 개발자는 오퍼레이션의 구현을 살펴보지 않더라도 객체의 사용방법을 쉽게 이해할 수 있다.

협력과 계약

부수효과를 명시적으로

객체지향의 핵심은 협력 안에서 객체들이 수행하는 행동이다. 안타깝게도 프로그래밍 언어로 작성된 인터페이스는 객체가 수신할 수 있는 메시지는 정의할 수 있지만 객체 사이의 의사소통 방식은 명확하게 정의할 수 없다. 메시지의 이름과 파라미터 목록은 시그니처를 통해 전달할 수 있지만 협력을 위해 필요한 약속과 제약은 인터페이스를 통해 전달할 수 없기 때문에 협력과 관련된 상당한 내용이 암시적으로 남게된다.