책 오브젝트 13장를 기반으로 하는 코드스피츠 강의 오브젝트2 - 2회차 (2) 를 정리한 내용입니다.
계약의 전파
Precondition 을 검증해야 한다는 로직이 있을 때 메시지 체인마다 Precondition 검증을 해야하는지?
중복코드가 발생하고 Dry 원칙을 위반하게 된다.
메시지 체인에 계약을 유지시킬수 있는 방법이 없는가?
생성자에 Null 이 들어올수 있기 때문에 Invariant 검증을 하지 않는다.
Invariant, Precondition, Postcondition 모두 검증을 하지 않고 있다.
Plan 은 1개 이상의 calls 와 초기값 Money.Zero 의 Precondition 을 검증한 후
값을 전달하고 있기 때문에 Plan = Calculator 사이에는 좋은 계약이 성립되었다고 말할수 있다.
Plan 아닌 객체 = Calculator 계약 사이도 calls 인자가 유효하다는 것은 확신할 수 있을까?
Calculator public final Money calcCallFee
PricePerTime public Money clac
public 이기 때문에 누구든지 메서드를 호출할 수 있다.
호출할 때도 calls 인자가 유효하다는 것은 확신할 수 있을까?
이걸 보장하기 위해선 Plan 만 Calculator.calcCallFee 만 호출할 수 있어야 한다.
가시성을 통한 계약보증
오직 Plan 만이 Calculator::calcCallFee 를 사용할 수 있도록 가시성 구성하여야 한다.
Calculator::calcCallFee 는 plan 패키지 안에 포함되어 있는 "Plan" 만 calcCallFee 를 호출할 수 있다.
Java 는 가시성 누수라는 문제가 있어서 Public 으로 구현을 해야한다.
Tex 는 외부에서 접근할 수 있지만
Calc 는 외부에서 접근할 수 없다.
이걸 상속 레이어에 대한 통제라고 한다.
public Money calc(Set<Call> calls, Money result)
final Money calc(Set<Call> calls, Money result)
public 의 대한 가시성을 제한했음으로 calc 는 package 내부에서만 호출할 수 있게 된다.
internal, protected 로 외부로부터 접근이 제한된다.
Postcondition
'객체지향설계' 카테고리의 다른 글
코드스피츠 2강 오브젝트 - 3회차 (0) | 2019.10.30 |
---|---|
코드스피츠 2강 오브젝트 - 4회차 (0) | 2019.10.30 |
코드스피츠 2강 오브젝트 - 1회차 (0) | 2019.10.28 |
코드스피츠 2강 오브젝트 - 2회차(1) (0) | 2019.10.28 |
코드스피츠 1강 오브젝트 6회차 (1) | 2019.10.26 |