1단계: 콘솔 주문 관리 (초급 기술)
6. 다음 단계로
1단계 코드는 동작한다. 그러나 다음 여섯 곳이 아프다. 각각이 2단계에서 어떤 기술로 해결되는지 미리 적어 둔다.
| # | 아픈 지점 | 증상 | 2단계의 해법 |
|---|---|---|---|
| 1 | 배열 크기 고정 | 4번째 회원, 4번째 주문이 거부된다. MAX_*를 늘려도 근본 해결이 아니다 |
ArrayList — 크기가 자동으로 늘어난다 |
| 2 | 선형 탐색 | findMember/findProduct가 O(n). 주문 하나 출력에 탐색 5회 |
HashMap<Long, T> — ID 조회가 O(1) |
| 3 | null 반환 | 조회 결과를 쓸 때마다 if (x == null). 빼먹으면 NPE |
사용자 정의 예외(NotFoundException) — 호출자가 검사를 잊어도 조용히 지나가지 않는다 |
| 4 | 실패 처리가 산만 | createOrder 에 if … println … return 이 5번. 호출자가 실패 종류를 모름 |
예외 계층 ShopException ← OutOfStockException 등. 종류별·부모로 잡기 |
| 5 | 계산 중복 | 합계를 두 곳에서 계산. 병렬 배열 동기화를 손으로 유지 | OrderLine.lineTotal(), Order.total(). 데이터와 계산이 한 곳에 |
| 6 | 금액이 그냥 int | 음수를 못 막고 format 을 매번 호출. 21억 오버플로 위험 |
불변 Money 클래스: 음수 금지, plus/times, equals |
그리고 한 가지가 더 있다. 1단계에는 결제가 없다. 주문을 만들면 포인트가 적립될 뿐, 돈이 어디서 나갔는지 모른다. 2단계는 카드·계좌·포인트 세 가지 결제 수단을 추가하는데, 이 셋을 if (type == CARD) ... else if (type == BANK) ...로 짜면 결제 수단이 하나 늘 때마다 pay 메서드를 열어야 한다. 인터페이스 PaymentMethod와 다형성이 여기서 등장한다.
다음 레슨: 2단계 — 객체지향으로 뼈대 세우기. 위 표의 여섯 가지를 하나씩 고치면서 1단계와 나란히 비교한다.