호출자와 호출되는 루틴중에 선행조건을 확인해야 하는 것은 누

snowtree의 이미지

제목 그대로
호출자와 호출되는 루틴중에 선행조건을 확인해야 하는 것은
누구의 책임이라고 생각하시는 지요 ?

평소 호출되는 루틴에서 하는 게 맞을 꺼 같다고 생각해 왔는데,
오늘 책(Pragmatic Programmer)을 보니 호출자에서 선행조건을 확인하는 것이 좋다는 내용이 있더군요.

kane의 이미지

선행조건은 당연히 호출되는 루틴에서 확인하는거라고 생각해왔던지라 어느 쪽이 좋은가 생각해보려니 머리가 안돌아가네요.

호출하는 쪽에서 확인하면,
불필요한 확인을 줄일 수도 있고,
조건이 맞지 않으면 루틴을 호출하지 않을 수 있는 이점이 있을 것 같네요.
하지만 전체 코드를 신경써서 코딩해야할 것 같고,
확인이 필요할 때마다 매번 확인하는 루틴을 넣어줘야 할 것 같네요.
제가 보기엔 얻는 이득에 비해 손해가 큰 것 같은데요.
책에는 뭐라고 써있나요?

lacovnk의 이미지

호출하는 쪽에서 신경을 써야 하지 않을까요?

선행조건 안맞추고 넘기는 호출자는 무책임해요~

호출되는 녀석은 주어진 기능만 해야 하는 게 아닐까요?, 선행조건은 말 그대로 "선행"하는 것을 가정하고 있어야 할 거 같습니다.

필요하다면 한번 더 wrap해서, 에러처리까지 묶어서 새로운 프로시저를 만드는게 맞을 것 같습니다. (앗, 이렇게 계속 무한 반복?)

hey의 이미지

하나의 함수를 여러 호출자가 부르면 여러 번의 선행조건을 검사해야 하지않습니까? 그 여러번 중에 한 번이라도 실수하면 프로그램이 죽을 수도 있구요.


----------------------------
May the F/OSS be with you..


SoftOn의 이미지

선행 조건을 모르고 사용할 수 있으므로 호출 되는 쪽에서 해야되듯하네요.

그런데 호출하는 쪽에서도 선행조건을 검사하면 두번검사하는 것이 되는데;;;

lovian의 이미지

호출쪽에서 하는게 더 좋지않을까요?

적어도 쓸때없는 분기는 없을테니까요.

그러나 유지보수? 차원에서는 호출되는쪽에서 하는 것이 나을테고.

으으.. 그럼 뭐란말인가.. :?

저는 대부분 호출되는쪽에서 검사하게 하는군요.

-----------------
한글을 사랑합니다.

lacovnk의 이미지

SoftOn wrote:
선행 조건을 모르고 사용할 수 있으므로 호출 되는 쪽에서 해야되듯하네요.

그런데 호출하는 쪽에서도 선행조건을 검사하면 두번검사하는 것이 되는데;;;

음. 선행조건을 알지 못하고 함수를 사용하는 것 자체가 잘못라고 생각하기 때문입니다.

예를 들어, array에서 주어진 index를 리턴하는 함수가 있다고 할때, index>=0 인것을 알고 사용하는 것은 사용자의 책임 아닌가요?

어느정도 에러 처리를 해주는 것은 편의상 가능하겠지만.. 기본은 이렇다고 생각합니다.

vacancy의 이미지

어떤 조건이냐에 따라 다르지 않을까요 ?
예를 들어 어떤 함수가 있어서

void func(int a[], int index);

식으로 생겼고 내부에서 a

    를 참조하는데
    a
      값이 처리 중에 valid할 수도 있고 아닐 수도 있다고 한다면요.

      호출자에서는 index가 valid한 인덱스인지 정도 확인해주고
      내부에서는 이 값을 읽어서 valid 여부를 확인해주고 할 것 같은데요.
      ( 뭐 경우에 따라 다르겠지만요, 구체적인 예를 들기가 뭣해서. -_-a )

      그리고 한 parameter가 여러 단의 function call을 지나게 될 경우,
      일찍 확인을 할 수록 overhead가 줄어들고
      늦게 확인을 할 수록 debugging하기엔 유리하지 않을까 싶네요.
      약간의 trade-off가 있을 것 같습니다.

      상황과 조건 여하에 따라 다르지 않을까 생각을 해봅니다.

      zelon의 이미지

      안정적인 프로그램을 위해서라면 양쪽 다 해야한다고 생각합니다. ^^

      단, 성능을 위해서라면 호출되는쪽에서 assert 만으로 체크하는 코드를 넣는것이 어떨까합니다.

      -----------------------------------------------------------------------
      GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
      블로그 : http://blog.wimy.com

      atie의 이미지

      호출하는 쪽에서 해주는 것이 맞다고 봅니다. 이유는 호출하는 쪽에서 선행 조건의 참과 거짓을 판별해야 하는 책임이 있다고 보고, 호출되는 쪽에서는 선행 조건의 값을 볼 수 있는 권한이 없어야 한다고 생각을 합니다. 또한 호출되는 쪽의 코드는 필요한 기능만을 수행을 해야 한다고 보고 그래야 동일한 기능을 다른 선행 조건에서도 부를 때도 하나의 함수를 재사용할 수 있기 때문입니다. 물론, 그 함수가 수행되는데 필수적인 조건은 그 자체에 포함을 해야 하겠죠.

      ----
      I paint objects as I think them, not as I see them.
      atie's minipage

      rollin96의 이미지

      믿느냐, 못 믿느냐의 문제 아닐까요?
      호출되는 쪽에서 호출하는 사람이 넘겨주는 값을 믿을 수 있다면 추가적인 처리를 안해줘도 되는 것이고,
      못 믿겠으면 처리를 하는 것이구요.
      앞에서 말씀하신 재사용성 문제도 있고...

      비슷한 예로...프로그래머가 기획자의 기획안에 논리적 오류가 없다는 것을 믿을 수 있다면 굳이 훑어볼 수고를 덜을 수 있고, 개발중이던 코드가 쓸모없게 되는 위험도 덜겠지요. 그러나 프로그래머가 기획자의 기획안을 못 믿겠으면, 직접 훑어보는 수 밖에 없고, 프로그래밍 하면서도 찜찜한 기분때문에 스트레스를 받게 되겠지요.

      creativeidler의 이미지

      예외 처리 구문이 있는 언어냐 아니냐에 따라 다를 듯. 예외 처리가 있는 언어에서라면 선행 조건이 안 맞으면 호출되는 쪽에서 에러를 던지고 호출하는 쪽에서 에러를 처리하도록 하면 최소한의 코드로 안정성과 명료성을 다 확보할 수 있죠.

      예외 처리 구문이 없는 언어라면 결국 if else나 assert를 쓰게 될 텐데 음.. 생각하기 싫군요-_-

      moonzoo의 이미지

      결합도의 문제 같습니다.

      호출받는 쪽이,호출하는 쪽에 종속되어 있는 개념이라면

      호출하는쪽에서만 선행조건을 처리해도 되겠지만.

      호출받는 쪽이, 호출하는 쪽에 비종속적이라면(여러 호출하는 쪽이 존재한다면)

      호출받는 쪽에서 처리하는 것이 좋다고 생각됩니다.

      소리의 이미지

      어딘가에서 받아온 데이타는, 받아온 시점에서 그 데이타의 유효성 검사를 해야 한다고 생각합니다. 그것이 함수의 인수를 통해 받은 것이든, 보조기억장치에서 읽어온 것이든 말입니다.

      호출하는 루틴이 호출시 넘길 인수도 결국 직접 생성했든지 다른 곳에서 받아온 데이타일 것입니다. 즉 받아오거나 생성, 혹은 처리 후 필요한 시점에서 유효성 검사를 한 상태지요.

      이 원칙을 호출받은 함수에 적용해본다면, 함수 역시 인수를 전달받은 직후, 즉 머리 부분에서 받아온 데이타의 유효성 검사를 해야 합니다. 검사 방법은 상황에 따라 조건분기문이나 assert, 예외처리 등 여러가지가 될 수 있겠지요.

      호출을 중심으로 선행조건 검사를 논하기 보다는, 조금 일반화해서 '데이타의 유효성 검사가 이뤄져야 하는 시점이 언제인가'를 생각하는 것이 이 문제의 본질에 다가가는 게 아닐지 싶습니다.

      jachin의 이미지

      함수에 대한 정확한 사양을 알고 있다면 호출자 쪽에서 선행조건을 판단해야 할 것 같습니다.

      함수 호출에 대한 비용이 있으니, 적어도 조금이나마 문제를 일으키지 않으려면 호출자 쪽에서 선행 조건을 거치고

      적정한 값에 대해서만 호출을 하도록 하는 것이 비용면에서나 안정성 면에서 좋을 것 같습니다.

      또한 만약을 대비해서라도 피호출함수는 예외 값에 대한 예외 처리 정도는 해줘야겠지요.