주차요금계산
서론
요즘 눈길이 가는 키워드는 OOP이다. 객체지향 어쩌고 하는데 결론은, 현실의
Role이나시스템을 코드로 옮겨 각각의객체들을 역할 및 책임 분리를 통해 코드의 재활용성을 높이고, 구조를 범용적이고 확장성 있게 설계하는거 같다.
설계
AI 평가
OOP 구현
- 역할 분리:차량 단위 상태/누적은 Parking_car, 기록 처리·정산·요금 계산은 Parking_system으로 분리. 단일 책임에 근접.
- 캡슐화 시도: in_time, out_time, parked를 내부에서만 다루고 외부엔 check_parking으로 노출.
- 파싱 분리: 문자열 파싱을 시스템에서 처리하고, 차량 객체엔 도메인 값(시·분, 상태)만 전달.
- 정산 흐름: 미출차 23:59 처리(정산 단계) → 요금 계산(정책 적용)으로 단계화.
개선 키워드
- 생성자 불변식: Parking_car(string id)로 id를 생성 시 강제, 이후 변경 금지.
- 접근 제어: accum_time, id도 private로 두고 getter만 제공. 외부 직접 변경 차단.
- 도메인 메서드 명확화: process_car 대신 in_at(minutes), out_at(minutes)로 의도 드러내기.
- 상태 강타입: state를 string 대신 enum class State { In, Out }로.
- 시간 일관성: h,m 대신 “분 단위 정수”로만 전달해 변환 중복 제거.
- 에러 가드: 잘못된 전이(IN 연속, OUT 연속, 음수 구간) 방지 로직 내부화.
- 의존성 분리: 요금 계산을 FeePolicy로 분리하면 테스트/교체 용이.
- 데이터 구조: 출력 순서 요구 시 map/정렬 명시, 요구 없으면 현재 그대로 유지.
- 인스턴스 독립: p_cars는 인스턴스 멤버 유지(멀티 시스템 동시 운용 대비).
자체 평가
무엇보다 데이터의 일관성, 정의부분 개선이 시급할 것 같다.
특히, 시간부분을 관리할 때, 분단위든 초단위든 역할이 다른 객체들간 교집합되는 데이터에 대해 명확한 정의 및 통일화된 데이터 가공이 필요할 것.
갈무리
위와 같은 정보로 설계하였는데 생각보다 역할을 분리하며 설계하는게 많은 시간과 노력이 필요했다.
그리고 최대한 중복되는 부분이 없이 효율적인 구조로 만든다는게 많이 어렵더라.
시간을 두고 OOP스럽게 코드를 작성하는 습관을 들이려는 연습을 하자.
일단함