코드스피츠 S84 #2

계약

- 전달받은 메시지의 규격 (precondition )

- 사후조건 (postcondition ) 

- 자기검증? (invariant)

 

불변식 (invariant)

- 메시지와 무관한 객체의 상태

- 일반적으로 필드값의 상태 점검

- DI에게 위임하거나 초기화 할당으로 처리 : 초기화할당은 객체를 만드는 사람의 역량? 그렇기 때문에 DI

 

코드 이야기

지난 시간에 배웠던 요금제도를 가지고서 이야기를 하기로 함

 

Plan -> Calculator, Set<Call> 가지고 있음

 

필드에 대해서는 널을 없애기 위해서 엠프티를 가짐.

Calculrator calulator = new Calculrator()

 

사전조건 (precondtion)

일반적으로 validation

메시지로 받는 값을 스스로 검증함

검증이 확정된 형으로 갈음할 수 있음 ) Ex :: Money. 원래는 Integer이지만 형이 보장되게끔 중간에 브릿지를 두기도 함.

 

프로그래밍 이론으로는 화이트리스트 이론. 위는 블랙리스트 이론, 화이트리스트를 거친 애들만 가지고서 화이트에서 전개

쉴드패턴 ( if 문으로 자름 )

 

코드 이야기

addCall(Call call) { ==> null 문제

모든 메서드의 시그니처를 무력화 할 수 있다

 

널문제의 해결

1. 언어나 컴파일러의 기능 @NonNull 이 어노테이션은 컴파일타임임....

언어에서 변수가 할당될 때 널인지 아닌지 아는 경우에는 막을 수 있음 ( 타입스크립트, 코틀린, 스위프트 등등 )

 

2. if로 슬그머니 무시 :: 하지만 자바 컬렉션에서 은근히 많이 사용되고 있다.

최소한 if 자체를 사용하는 것은 나쁘지 않지만 외부에서 확인할 수 있는 플래그를 두는게 맞다, 불린값리턴하여 했다 못했다.

이렇게 부드럽게 처리되는게 맞지 안맞는지를 명확히 해야함.

 

3. 예외처리 (throw)

불린도 런타임, 쓰로우도 런타임이다.

 

+ 추가적인 상태 검사

아무런 전략객체도 없는 경우 == calc.isEmpty() 인 경우?

 

사후조건 (post condition )

일반적으로 결과값 검증이라고 함

보내줄 값이 올바름을 검증함

검즈이 확정된 형으로갈음할 수 있음

리턴을 만드는데 성공하냐 마냐로 밀어버릴 수가 있음

 

코드이야기

calculateFee() 에 대해서 사후검증이 있어야한다. 

0원이 있어서는 안되고, - 이어서는 안된다

 

Money result = calc.calcCallFee(calls, Money.ZERO); 

if(calls.size() > 0 && (result.equals(Money.ZERO) || result.isLessthan(Money.ZERO) throw new RunTimeException("값이 어떻게 음수?"));

 

계약별 책임할당

그런 계약체크를 객체가 가지고 있는게 맞는가?

isEmpty() 를 하고서 예외를 던지는게 Plan 에서 체크하는게 맞나, Calculator 가 맞나?

isEmpty() 는 이미 간접적으로 물어보는 함수 

물어보지 말고 시켜야 한다!

isEmpty() -> check() 체크를 시켰더니 지 스스로 죽인다!

 

사후계약조건 책임할당

result를 가지고서 Plan이 검사함

Plan이 result를 검사해야할 이유가 1도 없다

유일한 의존성을 갖고 있는게 calls 임.. 하지만 파라미터로 줘버림.

Money result = calc.calcCallFee(calls, Money.ZERO); 

 

this 가 안 나왔으므로 calcCallFee 내부에 사후검증을 넣으면 됨.

계약의 준수는 어떠한 사람이 그 책임을 가져야하느냐가 섬세하게 판단되는 것

 

몰았다고 좋은 것이 아님.

진정한 계약은 이것(메서드)을 호출하는 것이다. postCondition은 위임된 메서드안에서 지 스스로 알아서 줘야함

 

받아들일때의 책임은 나한테 있다 

calc.check()를 수행하는 사람은 precondition 받는 쪽임. 

postcondition은 니가 처리해와~

 

처음에는 전부 Plan 에 두었었다.

 

회사에서 룰로 정해야 한다 프리컨디션은 받은 놈이 결정해. 포스트컨디션은 돌려주는 놈이 결정해..

이런 것때문에 코드가 장난감이 된다

프리컨디션과 포스트컨디션의 검사가 일관성이 없기 때문

 

프로그래밍의 70%는 밸리데이션이다.  (일기거리!)

 

협력을 통한 책임분할

Calculator 클래스 이야기

calls.size() > 0 이 빨간색인 이유?

calls 이 외부에서 준거인데 당연히 ?

 

외부에서 호출 할 때 플랜에서 이런식으로 호출

calcCallFee는 절대 0건인 calls를 받지 않는다. 오염되지 않았다! 

 

public final Money calculateFee(){

 calls.size() == 0 ? Money.ZERO : calc.calcCallFee(calls, Money.ZERO)

}

 

런타임에 의한 계약조건

 

Calculator 에 

if(cals.size() == 0) 이라는 check 로직이 있음. 

플랜에 들어가는 시점에 호출되어지게 되어져있음

 

setNext(Calc next){} 는 런타임에 얼마든지 추가될 수 있다는 것을 알 수 있음

 

check 와 setNext간의 시점차이가 있다.

런타임이 어려운 이유는 상태변화가 있기 때문

집어넣을 때 검사하고, 나중에 추가하게 되면..?

 

우리는 setCalculrator 가 check 가 호출되는 것이 뭔가 이상함을 알 수 있다. 얘는 pre나 post 가 아니라

Calculrator.calcCallFee(Set<Call> calls, Money result) 안에 들어가는 자기 실행적 invariant 한 기능이었음.

 

setNext(Calc calc) 안에서도 검증

 

계약의 전파

질문 :: 검증로직을 반복해서 집어넣는 것이 정상인가?

갑을병정무기경신임계에서는 어떻게 계약하나..?

삼성은 갑-병끼리도 계약해야 한다.

 

쌍방간의 계약을 성립해야하는 것인가, 아니면 똑같은 검증로직은 중복되어도 괜찮은가?

이것이 진정한 문제

 

PricePerTime이 사용하는 calc 에서는

Plan 이  calc.calcCallFee(Set<Call> calls, Money moey)을 호출.  올바른 파라미터들을 보냄. 

 

Plan -> Calculator -> Calc 가 보냄

 

public 이기 때문에 다른 메서드에서 나쁜 인자들을 호출할 수가 있다.

이 모든 것들을 계약관계로 사용하면 된다? 패키지를 통해서 이를 해결할 수 있다?

 

가시성을 통한 계약보증

이를 해결하기 위하여 패키지 보증

 

Calculator 의 가시성을

final Money calcCallFee(Set<Call> calls, Money result){ 로 변경하여서 외부에서 호출하지 말고,

plan 이라는 계약서에서 호출 할 수 있게 처리함

 

자바인터페이스는 가시성 누수때문에 public 을 사용해야함

abstract class Calc{

 abstract Money calc(Set<Call> calls, Money result);

}

 

가시성 문제

가시성문제도 계약의 일부

 

설계를 잘하면  패키지로 나눠지고, 패키지에 퍼블릭한 인터페이스가 몇개정도 있다

 

abstract class Calc{

 abstract Money calc(Set<Call> calls, Money result);

}

에서

public abstract class Calc{
	Money calc(Set<Call> calls, Money result){return calculrate(calls, result);}
	abstract protected Money calculrate(Set<Call> calls, Money result);
}

패키지 구성의 핵심은 계약관계에 달려있다