3강. 캡슐화와 불변 조건

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

모든 필드에 getter/setter를 만들면 private 표시는 있어도 누구나 잘못된 조합을 만들 수 있습니다. private은 보안 기능이 아니라 사용 규칙과 불변식을 보호하는 경계입니다.

✓2. 학습 목표

✓이 강의를 마치면

• 객체 불변식을 문장과 테스트로 정의합니다.
• 데이터 setter 대신 의도가 있는 행위를 공개합니다.
• 실패한 전이 뒤 상태가 유지됨을 검증합니다.

◇3. 핵심 개념

Task의 완료 시각은 완료 상태일 때만 존재한다는 불변식이 있습니다. setStatus와 setCompletedAt을 따로 노출하면 중간 불일치가 생깁니다. complete(now) 한 연산이 둘을 함께 바꿉니다.

용어 정리

• 캡슐화: 필드를 숨기는 데서 끝나지 않고, 객체가 허용하는 상태 변화만 공개하는 설계입니다.
• 불변 조건(invariant): 객체가 외부에 정상 상태로 보이는 모든 순간에 반드시 참이어야 하는 규칙입니다.
• 상태 전이: 진행 중 → 완료처럼 한 유효 상태에서 다른 유효 상태로 이동하는 일입니다.
• 원자적 변경: 관련된 값이 중간의 깨진 상태를 노출하지 않고 하나의 의미 있는 연산으로 함께 바뀌는 것입니다.

이 강의의 불변 조건은 다음 문장으로 먼저 고정합니다.

진행 중 작업은 완료 시각이 없고, 완료된 작업은 반드시 완료 시각이 있다.

setStatus(Status::completed)와 setCompletedAt(now)를 따로 호출하게 하면 두 호출 사이에 “완료인데 완료 시각 없음”이라는 잘못된 상태가 생깁니다. 호출자가 두 함수의 순서를 기억해야 하므로 책임도 밖으로 새어 나갑니다.

§4. 가장 작은 구현으로 시작하기

complete를 호출하기 전 status_는 inProgress입니다. 함수는 먼저 전이가 허용되는지 검사하고, 모든 검사를 통과한 뒤 관련 필드 두 개를 바꿉니다.

Task.cpp

void Task::complete(TimePoint now) {
    if (status_ != Status::inProgress) {
        throw InvalidTransition{"task is not in progress"};
    }
    status_ = Status::completed;
    completedAt_ = now;
}

생성자도 빈 제목과 잘못된 초기 상태를 거부합니다. 조회는 필요한 값만 const 함수로 제공합니다.

코드 한 줄씩 이해하기

1. status_ != Status::inProgress는 현재 작업이 완료 가능한 출발 상태인지 확인합니다.
2. 조건이 참이면 InvalidTransition을 던지고, 아래 대입은 한 줄도 실행하지 않습니다.
3. status_ = Status::completed로 상태를 완료로 전이합니다.
4. completedAt_ = now로 같은 전이에 필요한 완료 시각을 저장합니다.

호출 전 상태	호출 결과	호출 뒤 상태
진행 중, 완료 시각 없음	성공	완료, 전달한 완료 시각 있음
이미 완료, 완료 시각 있음	예외	기존 완료 상태와 시각 유지
취소됨, 완료 시각 없음	예외	기존 취소 상태 유지

검증보다 대입을 먼저 하면 첫 필드만 바뀐 뒤 예외가 발생할 수 있습니다. 따라서 실패 가능한 조건을 먼저 검사한 다음 상태를 한꺼번에 확정합니다.

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

호출자는 내부 필드 변경 순서를 알 필요가 없고 실패 시 아무 상태도 바뀌지 않습니다. 불변식 검증이 한곳에 모입니다.

이 설계에서 호출자는 task.complete(now)라는 의도만 표현합니다. 완료 시각을 언제 저장해야 하는지, 어떤 상태에서 거부할지는 Task가 결정합니다. 향후 완료 규칙이 바뀌어도 모든 호출자를 수정하지 않고 이 경계와 테스트를 중심으로 변경할 수 있습니다.

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

!자주 하는 실수

• 모든 필드 setter 생성: 도메인 행위 이름으로 바꿉니다.
• 검증 후 일부만 변경: 모든 검증을 먼저 끝내고 상태를 commit합니다.
• private을 보안으로 설명: 같은 프로세스 공격 방어가 아니라 컴파일 경계의 사용 규칙입니다.

✎7. 직접 실습

✎직접 실습

실습 목표

작업 완료 전이를 구현하고, 성공과 실패 뒤에도 불변 조건이 지켜지는지 테스트합니다.

시작 전 상태

Task에 Status status_와 선택적 완료 시각 std::optional<TimePoint> completedAt_가 있다고 가정합니다. status()와 completedAt()은 읽기 전용 조회 함수로 제공합니다.

1단계: 따라 하기 — 정상 완료

진행 중 작업을 만들고 complete(now)를 호출합니다. 상태가 completed이고 완료 시각이 now인지 두 항목을 모두 확인합니다.

2단계: 바꿔 보기 — 잘못된 순서 재현

연습용 복사본에서 상태 대입을 검증 위로 옮긴 뒤 이미 완료된 작업을 다시 완료해 보세요. 예외 뒤 상태가 일부만 바뀔 수 있는 이유를 기록하고 원래 순서로 되돌립니다.

3단계: 직접 적용 — 취소 전이 추가

힌트만 보고 cancel(now)을 추가합니다. 완료된 작업은 취소할 수 없고, 취소 상태와 취소 시각이 함께 유지되도록 불변 조건을 문장과 코드로 정의합니다.

4단계: 스스로 확인

• 정상 완료에서 상태와 시각이 모두 바뀌나요?
• 두 번째 완료 호출은 실패하고 첫 완료 시각을 보존하나요?
• 취소된 작업의 완료 호출은 상태를 바꾸지 않나요?
• public setter 없이 의도가 있는 함수만으로 상태를 바꿀 수 있나요?

테스트 힌트 보기

성공 결과만 확인하지 말고 예외 호출 전의 status와 completedAt을 저장한 뒤, 예외 후 두 값이 같은지 비교하세요.

막혔을 때

증상	원인	확인·해결
optional을 읽을 때 예외 발생	값이 없는 상태에서 .value() 호출	has_value()로 상태와 시각 규칙을 먼저 확인합니다.
예외 뒤 상태가 달라짐	검증 전에 일부 필드를 변경함	모든 실패 조건을 대입보다 앞에 둡니다.
호출자가 상태와 시각을 따로 설정함	setter가 불변식을 우회함	complete, cancel 같은 행위 함수로 교체합니다.
테스트가 예외 발생만 확인함	실패 후 상태 보존을 놓침	호출 전후 상태와 시각을 함께 비교합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 완료 상태와 완료 시각을 setter 두 개로 각각 공개하면 어떤 중간 상태가 생길 수 있나요?
2. 이미 완료된 작업에 complete()를 다시 호출했을 때 예외만 확인하지 않고 기존 완료 시각도 비교해야 하는 이유는 무엇인가요?
3. 외부 입력을 방어하는 보안과 private이 제공하는 컴파일 수준 사용 규칙은 어떻게 다른가요?

■9. 핵심 요약

■핵심 요약

캡슐화는 데이터 은닉보다 허용된 상태 변화만 노출하는 설계입니다. 다음 강의에서는 기능 변형을 상속 대신 합성합니다.

§10. 다음 강의 연결

불변 조건을 Task 안에 보호했으므로 호출자는 상태 변경 순서를 알 필요가 없습니다. 다음 강의에서는 행동의 변형이 늘어날 때 이 안정된 핵심을 상속 계층으로 흔들지 않고, 작은 객체를 조합해 확장하는 방법을 다룹니다.