부록A 계약에 의한 설계

해당 내용은 오브젝트 책의 마지막에 있는 부록입니다. 그리고 부록의 사전적인 의미는 다음과 같습니다. "본문 뒤에 참고 자료로 덧붙이는 내용." 그러나 저는 인터페이스를 이용해서 설계를 하는 방법 나아가 "계약에 의한 설계를 하는 방법"이 궁금하였기에 부록에 대해 읽어보았습니다. 해당 내용을 올바르게 이해하지는 못하였는듯 하나 제가 감명깊게 읽은 내용들을 정리하고자 하였습니다.

---

우리에게 필요한 것은 명령의 부수효과를 쉽고 명확하게 표현할 수 있는 커뮤니케이션 수단이다. 이 시점이 되면 계약에 의한 설계가 주는 혜택으로 눈을 돌릴 때가 된 것이다.
...
계약에 의한 설계는 클래스의 부수효과를 명시적으로 문서화하고 명확하게 커뮤니케이션할 수 있을뿐만 아니라 실행 가능한 검증 도구로써 사용할 수 있다.

계약에 의한 설계가 어떠한 것인지 간략하게 이야기를 하고 있습니다.

 

02 계약에 의한 설계

계약은 협력에 참여하는 두 객체 사이의 의무와 이익을 문서화한 것이다.
- 협력에 참여하는 각 객체는 계약으로부터 이익을 기대하고 이익을 얻기위해 의무를 이행한다.
- 협력에 참여하는 각 객체의 이익과 의무는 객체의 인터페이스 상에 문서화된다.
...
협력하는 클라이언트는 정상적인 상태를 가진 객체와 협력해야 한다.

계약에 의한 설계의 정의에 대해 나타내고 있습니다. 이번 부록을 전부 읽은 저로서는 클라이언트와 서버사이의 "이익"과 "의무"가 중요하다 느껴집니다.

 

사전조건

사전조건이란 메서드가 정상적으로 실행되기 위해 만족해야 하는 조건이다.
...
클라이언트가 사전조건을 만족시키지 못할 경우 Reserve 메서드(서버의 메서드)는 최대한 빨리 실패해서 클라이언트에게 문제가 있다는 사실을 알린다.

사전 조건은 일종의 파라미터값에 대한 검증이라 생각을 해도 될 듯합니다. 그리고 검증에 실패시 클라이언트에게 무엇때문에 실패했는지 알려줍니다.

 

사후조건

사후조건은 메서드의 실행 결과가 올바른지를 검사하고 실행 후에 객체가 유요한 상태로 남아 있는지를 검증한다.
- 인스턴스 변수의 상태가 올바른지를 서술하기 위해
- 메서드에 전달된 파라미터의 값이 올바르게 변경됐는지를 서술하기 위해
- 반환값이 올바른지를 서술하기 위해

사후 조건은 올바르게 로직이 수행되었는지를 검증하는 것이라 생각이 듭니다. 그리고 사후 조건을 사용하는 예시를 책에서는 3가지 예시를 들었습니다. 그리고 "인스턴스 변수의 상태가 올바른지 서술하기 위해"는 무슨 말인지 정확히 이해하기 어려워 찾아본 결과 이는 CQS패턴으로 예를 들어 설명하면 명령(Command)성격을 지닌 메서드가  호출되고 올바르게 수행되었는지 확인하는 로직이라 생각을 하면 될 듯 합니다.

 

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

계약규칙

서브타입이 슈퍼타입에 정의된 사전조건을 강화하면 기존에 체결된 계약을 위반하게 된다.
...
사후조건을 완화한다는 것은 서버가 클라이언트에게 제공하겠다고 보장한 계약을 충족시켜주지 못한다는 것을 의미한다.

사전조건과 사후조건의 강화와 약화에 대해 이야기하고 있습니다. 만약 자식클래스(서브타입)에서 사전조건을 강화시킨다면 부모클래스에서는 올바르게 동작하는 값들이라도(올바르게 동작하는 계약들이라도) 자식클래스(서브타입)에서는 올바르게 동작하지 않을수 있기에 주의해야 합니다.

 

가변성 규칙

서브타입은 슈퍼타입이 발생시키는 예외와 다른 타입의 예외를 발생시켜서는 안 된다.
...
두 가지 예에는 예외를 던지느냐, 아무것도 하지 않느냐의 차이는 있지만 클라이언트의 관점에서 자식 클래스가 부모 클래스가 하는 일보다 더 적은 일을 수행한다는 공통점이 있다.

이 대목에서 저는 가장 많이 얻어갔습니다. 그 동안 저는 코드를 작성하면서 예외가 발생할 때 발생하는 상황에 맞게 예외를 생성해서 던졌습니다. 그러나 책에서는 그러지 말고 부모 클래스에서 정의한 예외만을 던지라는 이야기를 하였습니다. 그리고 이는 저에게 너무 세부적인 예외를 발생시키지 말라는 이야기로 들렸습니다. 또한 오버라이드를 통해 빈 메소드 역시 생성하지 말라는 이야기 역시 좋았습니다.