2023.09.25 MON
538p ~ 546p
42일차 내용 ⬇️
2023.09.25 - [분류 전체보기] - 42일차 - 제어 역전 원리
42일차 - 제어 역전 원리
2023.09.24 SUN 528p ~ 537p 41일차 내용 ⬇️ 2023.09.24 - [개발 서적 기록/오브젝트_조영호] - 40, 41 일차 - 일관성을 통한 장점과 디자인 패턴 40일차 - 일관성을 통한 장점과 디자인 패턴 2023.09.24 SUN 505p ~ 51
magenta-ming.tistory.com
계약에 의한 설계
인터페이스에 대해 프로그래밍할 뿐만 아니라, 협력에 참여하는 두 객체 사이의 의무와 이익을 문서화한 계약을 사용하는 것이다.
오퍼레이션의 시그니처를 구성하는 다양한 요소들을 이용해 협력에 참여하는 객체들이 지켜야하는 제약 조건을 명시할 수 있다.
이를 통해 코드를 분석하지 않고도, 인터페이스의 사용법을 이해할 수 있다.
계약에 의한 설계를 구성하는 3가지 요소
사전조건 precondition
메서드가 호출되기 위해 만족되어야하는 조건으로, 메서드의 요구사항이다.
사전조건을 만족시켜야만 메서드를 실행할 수 있다.
메서드에 전달된 인자의 정합성을 체크하는 목적으로 사용된다. 잘못된 값을 기반으로 실행하는 것을 방지할 수 있다.
사후조건 postcondition
메서드가 실행된 후에 클라이언트에게 보장해야하는 조건이다.
클라이언트는 사전 조건을 만족시켜 메서드를 호출하고, 메서드는 실행 후에 사후조건을 만족해야한다.
만약 사후조건을 만족시키지 못했다면 예외를 던져야 한다.
사후조건은 아래 3가지 목적으로 사용한다.
- 인스턴스 변수의 상태가 올바른지 확인한다.
- 메서드에 전달된 파라미터의 값이 올바르게 변경되었는지 확인한다.
- 반환값이 올바른지를 확인한다.
사후조건은 사전조건보다 정의하기 까다로울 수 있다.
한 메서드 안에서 return 문이 여러번 나온다면, 모든 return 문에 대해서 결과값에 대한 검증 로직이 필요하다.
이런 경우에는 계약에 의한 설계를 사용해서, 예를 들면 그런 설계를 지원하는 라이브러리를 사용한다던지해서, 결과값에 대한 사후조건 로직을 한번만 작성하게 할 수 있다.
실행 전과 후의 값을 비교하는 경우에도, 메서드를 실행하면서 다른 값으로 변경되었을 수 있으므로 비교가 어렵다.
이런 경우에도 계약에 의한 설계를 사용해서 실행 전의 값에 접근하여 검증할 수 있다.
불변식 invariant
항상 참이라고 보장되는 서버의 조건이다.
클래스의 모든 메서드의 사전/사후 조건에 추가되는 공통의 조건같은 개념이다.
불변식의 특성
- 불변식은 클래스의 모든 인스턴스가 생성된 후, 만족되어야한다.
- 따라서 클래스에 정의된 모든 생성자는 불변식을 준수해야한다.
- 클라이언트가 호출할 수 있는 모든 메서드는 불변식을 만족해야한다.
- 메서드 실행 전 후에는 항상 불변식을 만족하는 상태를 유지해야 한다.
- 단, 메서드 실행 중에는 객체의 상태가 불안정한 상태가 될 수 있으므로, 불변식을 만족시키지 않아도 된다.
'개발 서적 기록 > 오브젝트_조영호' 카테고리의 다른 글
45일차 - LSP와 계약에 의한 설계 : 가변성 규칙 (0) | 2023.09.26 |
---|---|
44일차 - LSP와 계약에 의한 설계 : 계약 규칙 (0) | 2023.09.26 |
42일차 - 제어 역전 원리 (0) | 2023.09.25 |
40, 41 일차 - 일관성을 통한 장점과 디자인 패턴 (0) | 2023.09.24 |
36, 37일차 - 계약에 의한 설계 (0) | 2023.09.18 |