1단계: 콘솔 주문 관리 (초급 기술)
4. 실행 결과와 해설
4.1 회원 등록 — 4번째가 거부되는 이유
회원 등록: 3 박민수 (포인트 0)
[실패] 회원 저장 공간이 가득 찼습니다: 최지우MAX_MEMBERS = 3이므로 registerMember의 첫 if (memberCount >= MAX_MEMBERS)가 4번째 호출에서 참이 된다. 최지우는 프로그램 어디에도 저장되지 않는다. 실제 서비스라면 "회원 가입 불가"가 배열 크기 때문에 발생하는 셈이다. 크기를 100으로 늘리면 101번째에 같은 일이 생긴다. 문제는 숫자가 아니라 "고정"이라는 성질이다.
4.2 주문 생성 — 일곱 줄이 나온 경로
| 출력 | 어느 if에서 나왔나 |
|---|---|
주문 생성: #1 김철수 58,000원 (적립 580) |
모든 검증 통과. 25,000×2 + 8,000×1 = 58,000. 적립 580 = 58,000 / 100 |
[실패] 재고 부족: 자바 입문서 (재고 3, 요청 5) |
1차 검증 루프의 p.getStock() < quantities[i] |
[실패] 존재하지 않는 회원: 9 |
findMember(9)가 null |
주문 생성: #2 이영희 77,000원 (적립 770) |
32,000 + 15,000×3 |
[실패] 존재하지 않는 상품: 999 |
1차 검증에서 findProduct(999) == null. 101 재고는 깎이지 않음 |
주문 생성: #3 박민수 25,000원 (적립 250) |
정상 |
[실패] 주문 저장 공간이 가득 찼습니다 (회원 김철수) |
orderCount >= MAX_ORDERS |
주문 번호가 #1, #2, #3으로 빈틈없이 이어진다. nextOrderId++가 성공한 뒤에만 실행되기 때문이다. 실패한 호출에서 먼저 증가시켰다면 #1, #4, #6처럼 구멍이 났을 것이다.
5번째 호출(101, 999)에서 상품 101의 재고가 보존되는 것은 3.5절에서 설명한 "1차 검증 후 2차 차감" 덕분이다. 마지막 남은 재고: 무선 마우스=7은 10 − 2(#1) − 1(#3) = 7로, 실패한 주문의 흔적이 없다.
4.3 주문 목록 — 탐색이 몇 번 일어났나
#1 김철수 / 58,000원
- 무선 마우스 x2 = 50,000원
- USB-C 케이블 x1 = 8,000원이 세 줄을 만들기 위해 printOrders는 다음을 호출한다.
findMember(1)— 이름을 위해 (탐색 1회)orderTotal(o)→ 내부에서findProduct(101),findProduct(102)(탐색 2회)- 항목 루프에서
findProduct(101),findProduct(102)(탐색 2회, 2번과 중복)
주문 하나에 탐색 5회. 상품이 4개라 순식간이지만, 상품이 10만 개면 각 탐색이 평균 5만 번 비교한다. Order가 Product 참조를 직접 갖고 있었다면 탐색은 0회다.
4.4 집계 — 포인트 열이 말해 주는 것
회원별 매출: 김철수 58,000원 (포인트 5,580)포인트 5,580 = 초기 5,000 + 적립 580. 매출 58,000의 1%가 정확히 반영됐다. 그런데 이 값은 createOrder에서 member.addPoint(total / 100)로 주문 시점에 더한 것이고, "회원별 매출"은 printSalesByMember에서 출력 시점에 다시 계산한 것이다.
두 값의 근거가 되는 total이 서로 다른 코드(createOrder의 루프 vs orderTotal)에서 계산된다. 지금은 두 계산이 같은 공식이지만, 한쪽만 고치면(예: 할인 도입) 포인트와 매출이 어긋난다. 같은 계산이 두 곳에 있다는 것이 이 단계의 가장 조용한 위험이다.
4.5 format은 왜 마지막에 있나
String.format("%,d", amount)는 초급에서 배운 서식 문자열이다. 모든 금액 출력이 이 한 메서드를 거치게 해서, 나중에 "원" 표기를 바꾸거나 소수점을 붙일 때 한 곳만 고치면 되게 했다. 2단계에서 이 역할은 Money.toString()으로 옮겨간다.