계약에 의한 설계(Design by Contract; DBC)

 계약에 의한 설계(Design By Contract, 이하 DBC)는 아이펠(Eiffel)이라는 언어를 만든 버트란드 마이어가 개념을 개발하였다. 이것은 프로그램 모듈들의 책임을 문서화하는데 초점을 맞춘다. 각각의 모듈이 가져야 하는 기능만큼만 동작하도록 한다. 이러한 개념을 문서화하고 검증하는 것이 바로 DBC의 핵심이다.

 모듈이 동작할 때, 어떠한 인자를 넣어주어야 하는지, 어떤 결과를 원하는지 등이 있는데, DBC에서는 모듈을 호출하기 위해 참이어야 하는 것을 선행조건(Precondition), 모듈이 자기가 할 것이라고 보장하는 것을 후행조건(Postcondition)이라고 한다. 또, 불변식(Invariant)이라는 것이 있는데, 호출자의 입장에서 이 조건이 언제나 참이라고 보장하는 것을 말한다. 모듈이 내부 처리 중에는 불변식이 참이 아닐 수도 있지만, 모듈이 종료하고 호출자로 제어권이 반환되는 때에는 참이 되는 것이다.

 여기서의 계약은 호출자와 피호출자에 해당하는 계약이다. 계약 조건은 아래와 같이 명시되어 있다.

 만약 호출자가 모듈(루틴)의 모든 선행조건을 충족한다면, 해당 모듈은 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해야 한다.

 예를 들어, Person이라는 클래스의 이름을 설정하는 setName 이라는 메소드가 있다고 치자, setName 메소드는 아래와 같은 형태일 것이다.

class Person{ private String name; pulbic void setName(final String name){ this.name = name; } public String getName(){ return this.name; } }

 그렇다면 setName 메소드가 가져야 할 선행조건과 후행조건이 무엇인가. 선행조건은 인자로 받아오는 name이 null 값이 되어서는 안된다는 것이다. 후행조건은 모듈이 실행되고 나서 Person 클래스의 name이 제대로 변경되는 것이다. 그렇게 선행조건과 후행조건이 만족한다면 계약이 이행되는 것이다.

 setName 메소드에 대한 DBC를 아래와 같이 구현할 수 있다.

... /** *  @pre    name != null *  @post   getName() == name */ pulbic void setName(final String name){ this.name = name; } ...

 앞에서도 말했듯이, 아이펠은 DBC를 지원한다. 또한 C/C++에서도 Nana를 통해 지원한다. Java에서는 iContract, Contract4J, c4j 등을 통해 DBC를 구현할 수 있다.

 DBC는 어디에 유리할까? 아마도 문제가 발생한 경우, 문제를 찾고 원인을 밝히는데 사용하면 좋을 것이다. 또한 문제의 책임을 규명하는 데도 효과적일 것이다. 어떠한 모듈이 어떠한 호출에 의해 문제가 발생하였는지, 어떤 모듈의 책임인지 쉽게 알 수 있을 것이다.

 그런데 이렇게 효과적인 DBC는 왜 널리 쓰이지 않을까?

[참고 : 실용주의 프로그래머]