본문으로 건너뛰기
객체지향 설계 · 디자인 패턴LESSON 24

최종 실습: 확장 가능한 작업·알림 시스템

난이도중급 → 심화
예상 시간65분
선수지식이전 강의

24강. 최종 실습: 확장 가능한 작업·알림 시스템

1. 이번 강의에서 해결할 문제​

작업 상태, 파일 저장, 알림, UI가 한 Manager에 섞인 구조를 동작을 보존하며 일반 생산성 시스템으로 바꿉니다.

2. 학습 목표​

3. 핵심 개념​

요구사항은 작업 생성·시작·완료·취소, 파일 저장, 교체 가능한 알림, 완료 구독입니다. 초기 TaskManager는 문자열 상태, 파일, 알림 switch와 출력을 함께 처리합니다.

타입책임
Task·TaskState불변식과 허용 전이
TaskService유스케이스 순서와 사건 발행
TaskRepository저장 역할 계약
FileTaskRepository파일 I/O Adapter
Notifier알림 Strategy
EventBus·Subscription완료 Observer 수명
ApplicationFactory구체 구현 조립

4. 구현​

파일 구조
domain/Task.h, TaskState.h, Notification.h
application/TaskService.h, TaskRepository.h, Notifier.h, EventBus.h
infrastructure/FileTaskRepository.cpp, ConsoleNotifier.cpp
ui/ConsoleController.cpp
app/ApplicationFactory.cpp, main.cpp
tests/TaskTests.cpp, TaskServiceTests.cpp
TaskService.cpp
void TaskService::complete(TaskId id) {
    auto loaded = repository_.find(id);
    if (!loaded) throw TaskNotFound{id};
    Task task = std::move(*loaded);
    task.complete(clock_.now());
    repository_.save(task);
    events_.publish(TaskCompleted{id});
}

리팩터링은 현재 동작 테스트→Task 전이 추출→Repository 포트→Notifier Adapter→완료 Observer→Factory 조립 순서로 수행합니다. 패턴마다 새 타입 수와 다음 변경의 수정 파일 수를 비교해 가치 없는 래퍼는 제거합니다.

5. 코드가 동작하는 이유​

도메인은 상태 규칙, Service는 순서, 외곽은 파일·출력을 담당합니다. 저장 성공 뒤 사건을 발행해 알림이 영속 상태보다 앞서지 않습니다. 생성자 주입으로 테스트는 Fake와 Spy를 사용합니다.

6. 자주 하는 실수와 해결법​

7. 직접 실습​

8. 이해 점검 질문 3개​

9. 핵심 요약​

MINI QUIZ

최종 실습: 확장 가능한 작업·알림 시스템 미니 퀴즈

선택 즉시 정답과 해설을 확인할 수 있습니다. 결과는 이 브라우저에만 저장됩니다.

0 / 2
  1. 문제 1“최종 실습: 확장 가능한 작업·알림 시스템”의 코드·명령이 의도대로 동작하는지 판단할 기준은 무엇인가요?
  2. 문제 2“최종 실습: 확장 가능한 작업·알림 시스템”의 코드·설정이 동작하는 이유로 본문과 일치하는 것은 무엇인가요?

답을 선택하면 진행 결과가 자동으로 저장됩니다.

LESSON STATUS

학습을 마쳤나요?

직접 실습과 점검 질문까지 확인한 뒤 완료로 표시하세요.

24강. 최종 실습: 확장 가능한 작업·알림 시스템 미완료 상태