입문 과정의 마지막 단계에서는 지금까지 배운 조각을 완성된 규칙 하나로 합칩니다. 정책은 일부러 작게 잡습니다. 개봉하지 않은 상품은 배송 뒤 14일까지 환불할 수 있습니다. 핵심 습관은 결정과 경계를 모두 눈에 보이게 만드는 것입니다.
코드보다 먼저 입력을 밝힙니다
프로시저는 두 입력을 받습니다.
days: 배송 뒤 지난 일수opened?: 상품을 개봉했으면#t, 아니면#f
이 수업에서는 호출자가 0 이상의 올바른 일수와 불리언을 전달했다고 가정합니다. 입력 검증은 별도 결정 경계이며 결정적으로 오류 처리하기에서 다룹니다.
규칙 작성하기
(define (refund-decision days opened?)
(if (and (<= days 14) (not opened?))
'(decision allow)
'(decision deny outside-refund-window)))
(refund-decision 9 #f)결과
(decision allow)검사를 왼쪽부터 읽으세요. days가 14 이하여야 하고, opened?가 거짓이어야
합니다. 첫 조건이 실패하면 and는 바로 멈춥니다. if는 선택된 인용 결정 하나만
평가합니다.
거부 이유는 일부러 보수적인 하나의 이름을 사용했습니다. 실제 정책에서는 “기간 초과”와 “개봉함”을 나눌 수 있습니다. 이는 제품 정책 선택이며 리스펙스가 숨겨 결정하는 동작이 아닙니다.
성공 사례만 말고 경계를 시험합니다
(list (refund-decision 14 #f)
(refund-decision 15 #f)
(refund-decision 9 #t))결과
((decision allow) (decision deny outside-refund-window) (decision deny outside-refund-window))| 사례 | 확인하는 것 | 결정 |
|---|---|---|
| 14일, 미개봉 | 포함되는 마지막 경계 | 허용 |
| 15일, 미개봉 | 기간 밖의 첫 값 | 거부 |
| 9일, 개봉 | 두 번째 조건의 독립 실패 | 거부 |
나중에 누군가 <=를 <로 바꾸면 첫 행의 결과가 달라집니다. 경계표를 두면 그
변화를 바로 검토할 수 있습니다.
규칙을 결정적으로 유지합니다
규칙은 인자만 읽습니다. 시계를 가져오거나 서버를 호출하거나 애플리케이션의
숨은 변경 상태를 읽지 않습니다. 호출자가 days를 계산해 명시적으로
전달합니다. 같은 문서화된 런타임 제한 아래에서 같은 두 리스펙스 값을 주면 같은
평가 경로와 같은 관측 결과를 냅니다.
이 사실이 환불 정책의 공정성, 법적 충분성, 현실 데이터의 정확성을 증명하지는 않습니다. 리스펙스는 계산을 점검 가능하게 만들고, 입력의 출처와 외부 행위는 주변 애플리케이션이 책임집니다.
연습
미개봉 상품을 30일까지 허용하도록 바꾸고, 마지막 허용값과 첫 거부값을 보여 주는 호출 두 개를 추가하세요.
답 하나 보기
(<= days 14)를 (<= days 30)으로 바꾸고 다음을 시험합니다.
(list (refund-decision 30 #f)
(refund-decision 31 #f))예상 결과는 ((decision allow) (decision deny outside-refund-window))입니다.
과정 완료
이제 호출을 읽고, 프로시저를 정의하고, 리스트를 데이터로 보존하고, 가지를 고르고, 경계를 시험할 수 있습니다. 다음 길을 고르세요.
- 언어를 더 깊게 배우려면 소스 텍스트와 리더
- 더 큰 규칙을 설계하려면 결정 규칙 작성하기
- 정확한 소스를 되돌릴 수 있는 시각 아티팩트로 만들려면 리스펙스 이미지
- 인증과 소비자 고정 현재 확인이 필요할 때는 고급 리스펙스 바우치 흐름