함수를 만들다보면 함수의 인자값에는 선행조건이 항상 붙습니다.
예를 들면
int func(char* a);
위와 같은 포인터형태는 보통 a != null 이라는 선행조건이 붙는데..
이때 과연 해당 함수를 호출하는 호출자가 해당조건을 검사해야하는지
아니면 함수내에서 조건을 검사해야하는지
항상 함수를 만들때마다 고민을 하면서 쉽게 결정하지 못할때가 많았습니다.
그러던 어느날 "실용주의 프로그래머" 라는 책의 본문에 제가 고민하던 문제에 대한 도움이 될만한 내용보게 되었습니다.
누구의 책임인가? ( 실용주의 프로그래머 - p.193)
호출자와 호출되는 루틴 중에 선행조건을 확인하는 것은 누구의 책임인가? 언어의 일부로 구현되어 있는 경우, 대답은 어느 쪽도 아니다 이다. 선행조건은 호출자가 루틴을 부른 뒤, 그러나 루틴 자체로 들어가기 전에 무대 뒤에서 테스트된다. 따라서 명시적으로 체크해야 할 매개 변수가 하나라도 있으면, 이것은 호출자가 테스트를 수행해야한다. 루틴 스스로는 선행조건을 위배하는 매개 변수를 결코 보지 못할 것이기 때문이다. (내장 지원을 하지 않는 언어에선 호출되는 루틴을 이런 단정문을 확인하는 부분으로써 앞뒤를 감싸줘야 할 것이다.)
명령줄에서 숫자 하나를 읽어서(sqrt를 호출함으로써) 제곱근을 계산하고, 결과를 출력하는 프로그램을 생각해 보자. sqrt 함수는 선행조건이 있다. 인자가 음수가 되면 안된다. 콘솔에서 사용자가 음수를 입력하면, 그 값이 sqrt로 절대 전달되지 않게 하는 것은 호출하는 코드에 달려있다. 이 호출하는 코드에는 많은 옵션이 있다.
종료할 수도 있고, 경고문을 보이고 다른 숫자를 입력받을 수도 있고, 혹은 숫자를 양수로 바꾼 다음 sqrt의 결과값에 'i'를 덧붙일 수도 있다. 뭘 선택하든지 그건 절대 sqrt의 문제가 아니다.
제곱근 함수의 도메인을 sqrt루틴의 선행조건에 표현함으로써, 올바른지 아닌지 확인하는 짐을 (마땅하게도) 호출자에게 넘기게 된다. 그러면 여러분은 입력값이 범위 내에 있을 것이라는 전제 하에, sqrt 루틴을 안전하게 설계할 수 있게 된다.
책이 제 수준에서는 어려워서 아직 확실히 이해를 하지 못한 부분이 있어서 그런지 아직까지는 어느 한쪽의
방법만 써서는 안될것 같다는 생각이 있기는 하지만..
앞으로 함수를 만들때 위의 내용을 상기하면서 구현하는것이 좋을것 같습니다.