[additional] 계약에 의한 설계(Design By Contract)

[emiling]

질문

이전에 오브젝트 책도 그렇고 본 책에서도 계약에 의한 설계(Design By Contract)라는 말이 종종 언급됩니다. 해당 용어의 개념과 맥락에 대해 한 번 정리하고 가는 것이 좋을 것 같아 이슈를 생성했습니다.

세부 내용

• 내부를 조사하지 않고도 설계 요소의 의미와 연산의 실행 결과를 이해할 수 있는 방법이 필요하다 (p.272)
  • 의도를 드러내는 인터페이스를 통해 부분적인 효과를 얻을 수 있지만 충분하지 않음
  • "계약에 의한 설계" 학파에서는 이를 위해 클래스와 메서드에 대해 개발자가 사실임을 보장하는 "단언"을 사용

연관 챕터

https://github.com/caffeine-library/Domain-Driven-Design/issues/47

[leejaeseung]

프로그래머가 계약된 대로만 프로그래밍할 수 있으니 견고한 프로그램을 만들 수 있겠지만, 계약이 변경되는 경우도 항상 고려하면 더 좋을 것 같네요. 기존의 정책이 들쑥날쑥하게 바뀌는게 현업이다 보니.. 어떤 계약에 대해 확신을 갖고 프로그래밍하는게 쉽진 않더라구요.(그땐 맞는 정책이었겠지만)

한 가지 예시로 저희 기존 코드에선 어떤 변수가 빈 리스트일 수 없다는 정책으로 NonEmptySeq 라는 불변식이 적용된 리스트를 사용하고 있었는데 최근에 빈 리스트가 될 수 있도록 정책이 바뀌면서 이를 적용하기가 까다로웠습니다. 오히려 견고한 프로그램이다보니 그 견고함을 깰 수가 없었죠.(모든 로직이 NonEmptySeq 로 짜여있어 영향범위가 엄청나겠더라구요)

모든 걸 고려할 순 없지만, 무언가의 패턴이나 방식을 적용할 때 항상 단점도 고려하며 개발해야겠다는 생각이 드네요.(결국 정답은 없다..)

[emiling]

배경

• 의도를 나타내도록 인터페이스를 명료하게 정의해도 그 "부수효과" 까지 명확하게 표현하는데는 한계가 분명 존재한다
  • 특히 대부분의 코드에 있는 부수효과는 대부분 암시적이고
  • 코드의 구현이 복잡해질수록 이러한 암시적 부수효과는 실행 결과를 예측하기 어렵게 만듦
  • 복잡한 로직을 파해치게 되면서 결국 캡슐화의 가치는 사라지게 됨
• 이러한 "부수효과"를 쉽고 명확하게 파악할 수 있는 방법으로 제안된 것이 계약에 의한 설계

계약

• 소프트웨어가 제공해야하는 기능을 비즈니스 계약의 조건과 의무에 대한 비유에 따라 "계약"이라고 차용
• 결국 계약은 무엇을 기대하고, 보장하고, 유지해야하는가

계약에 의한 설계

• 오퍼레이션의 시그니처들을 구성하는 다양한 요소들을 이용해 협력에 참여하는 객체들이 지켜야 하는 제약 조건을 명시할 수 있다
  • 가시성(public/private), 반환 타입, 메서드 이름, 파라미터 타입, 파라미터 이름
  • 여기까지는 인터페이스가 의도를 잘 드러내도록 하면 어느 정도 지켜짐
• 여기에서 더 나아가 "정상적인 조건"인지를 확인할 수 있도록 세 가지를 추가로 기술하는 것 (실행절차가 아닌 상태 변화만 기술)
  • 사전조건 : 클라이언트는 서버가 처리할 수 있는 범위의 값들을 전달한다 : 인자의 정합성 → 이는 호출 클라이언트의 책임
  • 사후조건 : 서버는 클라이언트가 원하는 값을 반환한다 :
  • 불변식 : 클라이언트는 메세지 전송 전과 후의 서버 상태가 정상일 것으로 기대한다
• 계약과 일반 로직을 분리하여 서술하기 때문에 계약 부분을 명료하게 표현 가능

이를 위해 클래스와 메서드에 대해 개발자가 사실임을 보장하는 "단언"을 사용

C# 등에는 DBC를 지원하는 Code Contracts 같은 라이브러리가 있지만 이는 JAVA assertion 같은 것으로 충분히 대체 가능하는 점에서 "단언" 을 사용한다고 한 것으로 보임