invariants

invariants 대해 이해 해보도록 하는 포스팅을 작성하려고 합니다.

invariants : 불변속성란 뜻으로 받은 스스로에 대한 상태를 검증하는것을 뜻합니다.

https://velog.io/@pood/precondition-postcondition 에 이어서 계약에 의한 설계를 포스팅 해 보겠습니다.

아래는 그때 만들었던 precondition과 postcondition을 적용하여 작성된 코드 입니다.

사전 조건과 사후 조건만으로 안정성이 완벽히 확보 되었을까요? 보시면 현재 자신의 상태값이 money의 값이 처음부터 음수 였다면? 또는 null이 였다면 역시나 동일하게 에러를 발생하게 된 코드가 됩니다.
그래서 추가로 자기 자신이 과연 이 로직을 실행시킬 상태인가를 체크하는 로직이 필요합니다.

그래서 위와 같이 자기 자신의 money 의 값을 체크하여 현재 스스로에 대한 상태값을 검증하는 로직을 필요합니다.
Calculator의 PlusCalculator의 경우 precondition만 적용해주면 될것 같습니다.

그럼 생각해보면 모든 클레스와 메소드에 precondition와 postcondition 와 invariants을 적용하여 코딩을 해야 될까요?
맞습니다. 안정성을 확보하기 위해서 위의 3가지의 상태를 확인해줘야 합니다.

---

협력에 의한 책임 분할

위의 소스를 다시 보시면 Calculator의 PlusCalculator의 a와 b값은 이미 myWalletUpdate에서 검증을 하고 있습니다. 하지만 myWalletUpdate에서 검증하고 있다고 해서 PlusCalculator에서 검증이 불 필요한것은 아닙니다. myWalletUpdate에서 호출하지 않는다고 한다면 오류를 품은 코드가 되기 때문입니다.

그럼 반대로 생각해보면 PlusCalculator에서 calFee를 myWalletUpdate에서만 호출되게 만든다면
즉 화이트 리스트를 보장해준다면 PlusCalculator의 precondition을 삭제 할수가 있다는 뜻입니다.

그렇기 때문에 우리는 package를 이용하여 협약을 맺을수 있습니다. Wallet이란 패키지를 만들고 해당 클레스를 넣어줍니다.

그후 인터페이스인 Calculator를 추상 클레스로 변경하고 추상 메소드로 변경해 줍니다.

그 후 calFee를 default로 선언을 해주면 Wallet에 있는 myWalletUpdate에서만 해당 메소드를 호출할수 있습니다. 즉 myWalletUpdate에서 값을 검증하고 있고 myWalletUpdate에서 밖에 호출하지 못하기 때문에 calFee의 precondition은 삭제할수 있는 코드가 된 것입니다.

이로써 계약에 의한 설계에 대해 마무리를 하게 되었습니다.

감사합니다.