
단순히 기능을 만드는 게 아니라, "사용자가 실수할 것"을 미리 가정하고 코드를 짜는 습관이 핵심입니다.
유연한 파라미터 처리: 등록?이름=홍길동&고향=남원처럼 데이터가 많아져도 HashMap과 Stream을 통해 효율적으로 처리하는 로직을 구축했습니다.
예외 처리 (Default Value): 사용자가 값을 입력하지 않거나(?page=), 숫자가 아닌 문자열을 입력하는(?page=2번) 상황에서도 프로그램이 뻗지 않고 기본값을 반환하게 하여 안정성을 확보했습니다.
AssertJ 도입: assertThat(value).isEqualTo(expected)와 같은 가독성 좋은 테스트 코드는 나중에 코드를 수정할 때 가장 든든한 보험이 됩니다.
가장 중요한 구조적 변화입니다. 하나의 클래스가 모든 일을 하던 방식에서, 역할에 따라 계층을 나누는 방식으로 진화했습니다.
Controller (점원): 사용자의 입력(명령어)을 받고, 결과를 화면에 보여주는 '입구' 역할만 합니다.
Service (요리사): 실제 핵심 로직(비즈니스 규칙)을 담당합니다. "이 데이터를 저장해도 되는가?" 같은 판단을 여기서 합니다.
Repository (창고지기): 데이터의 저장소(DB나 파일 등)와 직접 소통하며 데이터를 넣고 빼는 역할만 수행합니다.
효과: 이렇게 나누면 나중에 데이터 저장 방식을 '파일'에서 'DB'로 바꿔도 리포지터리만 수정하면 될 뿐, 점원(컨트롤러)은 아무런 영향을 받지 않습니다.
많은 분이 "MVC를 쓰면 레이어드 아키텍처는 안 쓰는 건가요?"라고 묻곤 합니다. 결론부터 말하자면, MVC는 레이어드 아키텍처의 한 종류이자, 서로 보완하는 관계입니다.
소프트웨어 전체를 층층이 나누는 더 크고 일반적인 개념입니다.MVC (Model-View-Controller): 사용자 인터페이스(UI)를 가진 앱을 만들 때 사용하는 디자인 패턴입니다.
| 계층 | MVC 구성 요소 | 역할 |
|---|---|---|
| Presentation Layer | View + Controller | 사용자의 명령어를 입력받고, 처리 결과를 콘솔에 출력한다. |
| Business Layer | Model (Service) | 명언 등록, 수정, 삭제, 조회 등 핵심 비즈니스 로직을 담당한다. |
| Data Access Layer | Model (Repository) | 데이터를 리스트나 파일에 저장하고, 필요할 때 다시 불러온다. |
단순한 텍스트 저장에서 '객체 지향적인 데이터 관리'로 넘어왔습니다.
메타데이터의 중요성: createDate, modifyDate 같은 날짜 데이터를 추가함으로써 데이터의 생성/수정 흐름을 파악할 수 있게 되었습니다.
save 메서드 통합: isNew() 로직을 통해 "새로 만들 것인가(Insert)" 아니면 "기존 것을 고칠 것인가(Update)"를 한 메서드에서 판단하게 하여 코드를 단순화했습니다.
프로그램 전체에서 공통으로 사용되는 '도구'들을 어떻게 관리할지에 대한 해답입니다.
싱글톤(Singleton) 개념 맛보기: 프로그램 실행 내내 딱 하나만 있어도 되는 객체(Scanner, Repository 등)들을 AppContext에 모아두고 어디서든 static하게 접근하도록 설계했습니다.
static 블록: 클래스가 실행되자마자 복잡한 의존성(예: 서비스를 만들 때 리포지터리를 넣어주는 작업)을 미리 해결해두는 안전장치를 마련했습니다.