five lines of code

Chapter 1. Refactoring Refactoring: 리팩터링 다시 시작하기

고품질 코드는 유지보수 비용을 줄이고, 버그를 줄이며, 개발자를 행복하게 만든다. 리팩터링은 그 고품질에 도달하는 가장 일반적인 방법이다. 그러나 기존 방식—코드 냄새(code smells)와 단위 테스트—은 진입 장벽이 불필요하게 높다.

1.1 What is Refactoring?: 리팩터링이란 무엇인가

정의 (리팩터링): 코드가 하는 일을 바꾸지 않으면서, 코드를 더 읽기 쉽고 유지보수하기 좋게 변경하는 행위이다.

정의 (좋은 코드): 사람이 읽을 수 있고(human-readable), 유지보수가 쉬우며(easy to maintain), 의도한 동작을 올바르게 수행하는 코드이다.

리팩터링의 세 가지 경제적 근거

• 생산성: 코드베이스를 더 읽기 쉽게 만들면 새 기능 구현에 쓸 시간을 확보한다. 프로그래머의 시간은 비싸다.
• 안정성: 코드를 더 유지보수하기 쉽게 만들면 버그가 줄고, 발생한 버그도 더 쉽게 고칠 수 있다.
• 즐거움: 코드를 읽을 때 우리는 머릿속에 모델을 구축한다. 한 번에 유지해야 할 정보가 많을수록 더 피로해진다. 좋은 코드베이스는 그 부담을 줄인다.

1.1.1 리팩터링 예시: 지역 변수 추출

// Before: 동일한 연산(pow)을 두 번 수행하여 비효율적
return pow(base, exp / 2) * pow(base, exp / 2);

// After: 결과를 지역 변수에 캐싱하여 중복 연산 제거 및 가독성 향상
const result = pow(base, exp / 2);
return result * result;

• 코드의 동작(반환값)은 동일하게 유지된다.
• 성능 개선(중복 계산 제거)과 가독성 향상이 동시에 달성된다.

1.1.2 리팩터링의 범위

이 책에서 다루는 리팩터링은 다음 두 가지에 초점을 맞춘다.

• Human-readable: 코드를 읽는 사람이 빠르게 이해할 수 있는가
• Easy to maintain: 다음 사람이 쉽게 수정할 수 있는가

또한, 이 책의 리팩터링 기법은 객체지향 프로그래밍(OOP) 언어를 전제로 한다.

1.2 Skills: What to Refactor?: 무엇을 리팩터링할 것인가

리팩터링에서 첫 번째 진입 장벽은 “무엇을 고쳐야 하는지”를 아는 것이다.

1.2.1 기존 접근: 코드 냄새(Code Smells)

• “함수는 한 가지 일만 해야 한다”는 유명한 코드 냄새 지침이 있다.
• 강력하지만 경계가 모호하고 판단과 경험에 의존한다.
• 주니어 개발자에게는 “육감(sixth sense)“처럼 느껴져 학습하기 어렵다.

// 이 코드가 "냄새"가 나는가?
// 나누기, 지수, 곱셈 — 세 가지 일? 아니면 하나의 수를 반환하므로 한 가지 일?
const result = pow(base, exp / 2);
return result * result;
// -> 코드 냄새 기준으로는 판단이 모호하다.

1.2.2 이 책의 접근: 규칙(Rules)

• 코드 냄새 대신 쉽게 인식하고 적용할 수 있는 규칙을 제시한다.
• 규칙은 명확하고 간결하며 기억하기 쉽다.
• 규칙과 코드 냄새의 커버리지는 완전히 일치하지 않는다.
  • 규칙이 과도하게 엄격하여 불필요한 수정을 요구할 수 있다.
  • 규칙을 따르고도 냄새나는 코드가 나올 수 있다.
• 규칙은 **훈련 바퀴(training wheels)**이다. 완벽하지 않지만, 시작점을 제공한다.

flowchart LR
    A[코드 냄새\nCode Smells] --- C((겹치는\n영역))
    B[이 책의 규칙\nRules] --- C
    style A fill:#f9f,stroke:#333
    style B fill:#bbf,stroke:#333
    style C fill:#dfd,stroke:#333

1.2.3 규칙 학습의 3단계 추상화

규칙을 깊이 이해하기 위해 세 단계를 순서대로 밟는다.

1.3 Culture: When to Refactor?: 언제 리팩터링할 것인가

리팩터링은 샤워하는 것과 같다. — Kent Beck

리팩터링은 자주, 규칙적으로 할수록 비용이 적게 든다.

1.3.1 6단계 개발 워크플로우

기존의 레드-그린-리팩터(red-green-refactor) 루프는 테스트 주도 개발(TDD)에 묶여 있다. 이 책은 테스트와 분리된 다음의 범용 워크플로우를 권장한다.

flowchart TD
    A([1. 탐색 Explore]) --> B([2. 명세 Specify])
    B --> C([3. 구현 Implement])
    C --> D([4. 테스트 Test])
    D --> E([5. 리팩터 Refactor])
    E --> F([6. 배포 Deliver])
    style E fill:#ffffcc,stroke:#999

• 탐색: 요구사항이 불명확한 경우 빠르게 실험하여 방향을 확인한다.
• 명세: 무엇을 만들어야 하는지 명확히 한다. 가능하면 자동화 테스트 형태로 만든다.
• 구현: 코드를 작성한다.
• 테스트: 코드가 명세를 통과하는지 검증한다.
• 리팩터: 코드를 다음 사람(미래의 자신 포함)이 쉽게 다룰 수 있도록 정리한다.
• 배포: 풀 리퀘스트(PR) 또는 브랜치 푸시로 사용자에게 코드를 전달한다.

1.3.2 레거시 시스템에서의 리팩터링

먼저 변경을 쉽게 만들고, 그 다음 쉬운 변경을 수행하라. — Kent Beck

• 전체 코드베이스를 한 번에 리팩터링하려 하지 않는다.
• 새 코드를 추가하기 바로 직전에, 그 부분만 리팩터링하여 추가를 쉽게 만든다.
• 마치 요리 재료를 모두 손질한 뒤 요리를 시작하는 것과 같다.

1.3.3 리팩터링을 하지 말아야 할 때

다음 세 가지 유형의 코드베이스는 리팩터링이 가치 없을 가능성이 높다.

• 일회성 코드(Spike): 한 번 실행하고 바로 삭제할 코드
• 퇴역 예정 코드: 유지보수 모드에서 곧 폐기될 코드
• 극한 성능 요구 코드: 임베디드 시스템, 고성능 물리 엔진 등

1.4 Tools: How to Refactor Safely?: 어떻게 안전하게 리팩터링할 것인가

자동화 테스트는 자동차의 브레이크와 같다. 브레이크는 느리게 가려고 있는 것이 아니라, 빠르게 달려도 안전하다고 느끼기 위해 있다.

1.4.1 테스트 없이 안전을 확보하는 방법

이 책은 자동화 테스트 없이도 다음 세 가지 도구로 안전을 확보한다.

• 구조화된 리팩터링 패턴: 레시피처럼 상세하고 단계별로 구성된 절차
• 버전 관리(Git): 언제든 정상 동작하던 상태로 되돌릴 수 있는 체크포인트
• 컴파일러와 타입 시스템: 흔한 실수의 상당 부분을 컴파일 오류로 조기 감지

1.4.2 실전 안전 수칙

• 컴파일러가 오류 없이 통과하거나, 직접 앱을 열어 동작을 확인할 때마다 커밋을 한다.
• 코드가 망가졌고 즉시 고치기 어렵다면, 마지막 정상 커밋으로 즉시 되돌린다.
• 실제 운영 시스템에서 자동화 테스트 없이 리팩터링할 경우, IDE 자동 리팩터링, 수동 테스트, 아주 작은 단계로 진행 등을 통해 신뢰를 보완한다. 단, 이 경우 자동화 테스트를 적용하는 것이 비용 효율적일 수 있다.

1.5 Tools You Need to Get Started: 시작에 필요한 도구

1.5.1 프로그래밍 언어: TypeScript

• 이 책의 모든 예제는 TypeScript로 작성되어 있다.
• Java, C#, C++, JavaScript와 유사하여 해당 언어 사용자라면 쉽게 읽을 수 있다.
• 클래스가 전혀 없는 비객체지향 코드에서 완전한 객체지향 코드로 점진적으로 발전시킬 수 있다.
• 규칙과 리팩터링 패턴 자체는 언어 무관(language-agnostic)하며, 모든 객체지향 언어에 적용된다.

TypeScript 참고 사항

// Before: == 은 타입 강제 변환으로 예상치 못한 결과를 낳는다
console.log(0 == "");  // true (예상 밖의 결과)

// After: === 는 타입까지 비교하여 의도한 동작을 보장한다
console.log(0 === ""); // false (올바른 결과)

1.5.2 에디터: Visual Studio Code

• TypeScript와 뛰어난 호환성을 제공한다.
• 터미널에서 tsc -w를 백그라운드로 실행하여 파일 변경 시 자동 컴파일이 가능하다.
• Visual Studio(IDE)와는 완전히 다른 별개의 도구이다.

1.5.3 버전 관리: Git

• 필수는 아니지만 강력히 권장된다.
• 길을 잃었을 때 안전하게 되돌아갈 수 있는 체크포인트 역할을 한다.
• 특정 섹션의 참조 코드 상태로 즉시 복원 가능하다.

# 특정 섹션의 참조 솔루션 상태로 초기화 (주의: 현재 변경 사항은 모두 유실된다)
git reset --hard section-2.1

1.6 Overarching Example — A 2D Puzzle Game: 핵심 예제 소개

이 책의 Part 1 전체에 걸쳐 단 하나의 코드베이스를 중심으로 학습한다.

1.6.1 게임 개요

• 장르: 2D 블록-밀기 퍼즐 게임 (Boulder Dash 류)
• 조작: 화살표 키로 플레이어 이동
• 목표: 상자(box)를 우하단 코너로 이동시킨다

1.6.2 게임 요소

1.6.3 코드베이스의 특성

• DRY(Don’t Repeat Yourself)와 KISS(Keep It Simple, Stupid) 원칙을 이미 준수하고 있다.
• 그럼에도 불구하고 여전히 리팩터링이 필요한 현실적인(industry-realistic) 코드 스타일로 작성되어 있다.
• 수동 테스트가 직관적이다. 게임이 올바르게 동작하는지 눈으로 즉시 확인할 수 있다.

# 게임 세팅 방법
git clone https://github.com/thedrlambda/five-lines
# index.html을 브라우저에서 열고, tsc -w로 백그라운드 컴파일 실행

1.6.4 두 번째 연습 코드베이스

• 별도의 2D 액션 게임 프로젝트(bomb-guy)가 솔루션 없이 제공된다.
• 재독 시 심화 연습, 또는 강의 과제용으로 활용 가능하다.
• 동일한 스타일과 구조를 가지며, 동일한 단계로 리팩터링할 수 있다.

1.7 A Note on Real-World Software: 실제 코드에 적용할 때의 주의사항

• 이 책의 목적은 특정 규칙을 모든 상황에 맹목적으로 적용하는 것이 아니라, 리팩터링 역량 자체를 습득하는 것이다.
• 규칙의 목적은 이해를 쌓는 것이다. 자동 리팩터링 도구로 만들 수 없는 이유도 여기에 있다.
• 핵심 원칙: 규칙을 더 잘 알게 될 때까지는, 규칙을 따른다.
• 실제 운영 시스템에서는 자동화 테스트 없이 리팩터링하지 않는 것을 권장한다. 이 책이 테스트 없이 진행하는 것은 학습 환경이기 때문이다.

챕터 1 요약

Chapter 2. Looking Under the Hood of Refactoring: 리팩터링의 내부 원리

리팩터링이란 코드가 하는 일을 바꾸지 않으면서 코드를 더 좋게 만드는 것이다.

2.1 가독성(Readability)과 유지보수성(Maintainability) 향상

2.1.1 코드를 더 좋게 만든다는 것

가독성(Readability): 코드가 자신의 의도를 얼마나 잘 전달하는가를 나타내는 속성이다.

가독성을 높이는 수단들은 다음과 같다.

• 코딩 컨벤션의 수립과 준수
• 의미 있는 변수·메서드·클래스·파일 명명
• 적절한 주석 (코드를 그대로 반복하지 않는)
• 공백(whitespace)을 통한 구조 시각화

아래는 가독성을 모두 위반한 코드와 개선된 코드의 대비이다.

// Before: 가독성을 모두 위반한 코드 — 잘못된 타입 이름, 이중 부정, 오도하는 들여쓰기
function checkValue(str: boolean) {
  // Check value
  if (str !== false)
    // return
    return true;
  else; // otherwise
    return str;
}

// After: 의도를 명확히 전달하는 코드
function isTrue(bool: boolean) {
  return bool;
}

• str이라는 이름은 boolean 타입에 맞지 않는다 → bool로 변경한다.
• str !== false는 이중 부정이다 → bool로 단순화한다.
• 코드를 그대로 반복하는 주석은 노이즈다 → 제거한다.
• else;의 세미콜론은 else 블록을 즉시 종료시키는 버그다 → 제거한다.

2.1.2 유지보수성과 불변 조건(Invariant)

유지보수성(Maintainability): 코드를 변경할 때 얼마나 많은 사전 조사가 필요한가를 나타내는 속성이다.

• 조사해야 할 코드가 많을수록 시간이 오래 걸리고 실수 가능성이 높아진다.
• 유지보수성이 낮은 코드는 무관해 보이는 곳을 건드렸을 때 시스템이 깨지는 취약성(fragility)을 유발한다.
• 취약성의 근본 원인은 대부분 **전역 상태(global state)**이다.

전역 상태를 파악하는 실용적 기법: 중괄호 { ... }를 기준으로 삼는다. 중괄호 바깥에 있는 모든 것은 중괄호 안쪽 코드에게 전역 상태이다.

불변 조건(Invariant): 코드 내에서 명시적으로 검사하지는 않지만 항상 참이라고 가정하는 속성이다. (“이 숫자는 절대 음수가 되지 않는다”, “이 파일은 반드시 존재한다” 등)

비지역 불변 조건(Nonlocal Invariant)이 코드를 오염시키는 예시

// Before: daysUntilExpiry > 0 이라는 불변 조건이 코드 내에 암묵적으로만 존재
class GroceryItem {
  daysUntilExpiry: number;
  value: number;

  getUrgency(): number {
    // 불변 조건: daysUntilExpiry는 항상 양수라고 가정 (명시되지 않음)
    return this.value / this.daysUntilExpiry; // 전구 추가 시 0으로 나누기 오류 발생
  }
}

class LightBulb extends GroceryItem {
  constructor() {
    super();
    this.daysUntilExpiry = 0; // 불변 조건 위반 — 담당자가 invariant를 몰랐음
  }
}

• 2년 후 전구를 추가한 개발자는 urgency = value / daysUntilExpiry 계산식의 존재를 몰랐다.
• daysUntilExpiry = 0으로 설정하는 순간 불변 조건이 깨지고 Division by zero 오류가 발생한다.
• 이처럼 불변 조건이 멀리 떨어져 있을수록 시스템은 취약해진다.

불변 조건의 지역화(Localizing Invariants): 리팩터링은 명시적 검사를 추가해 불변 조건을 제거하는 것이 아니라(그것은 동작을 바꾼다), 함께 변하는 것들을 가까이 모아 불변 조건을 눈에 잘 띄게 만든다.

2.1.3 동작을 바꾸지 않는다는 것의 의미

리팩터링은 블랙 박스 외부에서 관찰할 수 있는 동작을 변경하지 않는다. 단, 성능은 예외이다.

• 대부분의 시스템에서 성능보다 가독성·유지보수성이 더 가치 있다.
• 성능이 중요하다면, 리팩터링과 별도의 단계에서 프로파일링 도구를 통해 다루어야 한다.
• 리팩터링 범위는 좁을수록 머지 충돌(merge conflict) 위험이 줄어든다.

리팩터링의 세 가지 기둥:

1. 의도를 전달하여 가독성 향상
2. 불변 조건을 지역화하여 유지보수성 향상
3. 위 1, 2를 범위 밖의 코드에 영향 없이 수행

2.2 속도, 유연성, 안정성 확보

대부분의 아키텍처 수준의 리팩터링 패턴과 규칙은 객체 합성(composition)을 돕기 위해 존재한다.

2.2.1 상속보다 합성(Composition over Inheritance)

Gang of Four(GoF)는 1994년 Design Patterns에서 이미 비지역 불변 조건을 우발적으로 도입하는 주범으로 **상속(inheritance)**을 지목하고, “객체 합성을 상속보다 선호하라”는 원칙을 제시했다.

// Before: 상속(Inheritance) — 새 메서드 추가 시 조용히 잘못된 동작을 상속받는다
interface Bird {
  hasBeak(): boolean;
  canFly(): boolean;
}
class CommonBird implements Bird {
  hasBeak() { return true; }
  canFly() { return true; }
}
class Penguin extends CommonBird {
  canFly() { return false; }
  // canSwim()이 CommonBird에 추가되면, Penguin은 아무 경고 없이 canSwim = false를 상속받는다
}

// After: 합성(Composition) — 새 메서드 추가 시 컴파일러가 누락을 강제로 알려준다
interface Bird {
  hasBeak(): boolean;
  canFly(): boolean;
  canSwim(): boolean;
}
class CommonBird implements Bird {
  hasBeak() { return true; }
  canFly() { return true; }
  canSwim() { return false; }
}
class Penguin implements Bird {
  private bird = new CommonBird(); // 합성
  hasBeak() { return this.bird.hasBeak(); } // 직접 위임(forwarding)
  canFly() { return false; }
  canSwim() { return true; } // 컴파일러가 구현 누락을 오류로 강제함
}

핵심 통찰: 인간의 기억은 신뢰할 수 없는 의존성이다. 상속은 “재정의해야 할 것을 기억하라”는 암묵적 계약을 만들지만, 합성은 그 계약을 컴파일러가 강제한다.

합성 기반 시스템은 레고 블록처럼 작동한다. 모든 것이 서로 맞도록 설계되어 있어 부품을 교체하거나 기존 컴포넌트를 조합하여 새로운 것을 만드는 속도가 매우 빠르다.

2.2.2 수정이 아닌 추가로 변경하기 (Change by Addition)

합성의 가장 큰 장점은 기존 코드를 건드리지 않고 기능을 추가하거나 변경할 수 있다는 것이다. 이 속성은 **개방-폐쇄 원칙(Open-Closed Principle, OCP)**이라고도 불린다.

컴포넌트는 확장(추가)에는 열려 있고, 수정에는 닫혀 있어야 한다.

추가로 변경하기가 가져오는 이점:

• 개발 속도: 기존 코드를 건드리지 않으면 사전 조사 시간이 줄어든다. 단, 사용되지 않는 코드는 즉시 삭제해야 코드베이스 팽창을 막는다.
• 안정성: 기존 코드를 보존한 채 새 코드를 추가하면 언제든 이전 동작으로 폴백(fallback)할 수 있다. 기존 기능에 새로운 오류를 도입하지 않는다.

2.3 리팩터링과 일상적 업무

“항상 네가 찾은 것보다 더 나은 상태로 두고 떠나라.” — 보이 스카우트 규칙(Boy Scout Rule)

리팩터링되지 않은 코드를 배포하는 것은 다음 개발자로부터 시간을 빌리는 것이다. 나쁜 소프트웨어 아키텍처에는 이자(interest rate)가 붙는다 — 이것이 **기술 부채(Technical Debt)**이다.

일상적 리팩터링의 두 가지 방식:

1. 레거시 시스템: 변경을 가하기 전에 먼저 리팩터링하고, 이후 일반 작업 흐름을 따른다.
2. 신규 코드: 변경 사항을 만든 후, 배포 전에 리팩터링한다.

2.3.1 학습 방법으로서의 리팩터링

• 리팩터링은 코드를 완전히 이해하지 않아도 개선할 수 있는 방법이다.
• 이해하기까지 수 시간이 걸릴 코드도 리팩터링을 통해 작은 조각씩 소화하며 결국 쉽게 이해되는 상태로 만든다.
• 리팩터링을 통해 더 좋은 코드의 이점을 직접 경험하면, 코드를 쓰고 생각하는 방식 자체가 바뀐다.
• 안정성 확보 → 배포 빈도 증가 → 더 큰 안정성의 선순환이 가능해진다.
• 유연성 확보 → 설정 관리 시스템, 피처 토글(feature-toggling) 시스템 구축이 가능해진다.

2.4 소프트웨어 맥락에서의 “도메인(Domain)”

도메인(Domain): 소프트웨어가 모델링하는 실세계의 특정 측면이다.

• 도메인에는 사용자와 전문가, 고유한 언어와 문화가 존재한다.
• 이 책 1부에서는 도메인이 2D 퍼즐 게임이며, 사용자는 플레이어, 전문가는 게임·레벨 디자이너이다.
• 프로그래밍 언어는 모호함을 허용하지 않으므로, 개발자는 도메인 전문가도 모르는 새로운 엣지 케이스를 탐구해야 한다.
• 따라서 프로그래밍은 근본적으로 학습과 소통의 행위이다.

챕터 2 요약

flowchart TD
    A[리팩터링<br/>동작 변경 없이 코드 개선] --> B[가독성 향상<br/>의도 전달]
    A --> C[유지보수성 향상<br/>불변 조건 지역화]
    C --> D[전역 상태 최소화]
    D --> E[상속보다 합성 선호]
    E --> F[추가로 변경하기<br/>Open-Closed Principle]
    F --> G[개발 속도 향상]
    F --> H[시스템 안정성 향상]
    F --> I[유연성 향상]
    A --> J[일상적 리팩터링<br/>Boy Scout Rule]
    J --> K[기술 부채 방지]

Chapter 3. Shatter Long Functions: 긴 함수 분해하기

“Don’t panic.” — Douglas Adams, The Hitchhiker’s Guide to the Galaxy

코드는 DRY와 KISS 원칙을 따르더라도 쉽게 복잡해진다. 주된 원인은 세 가지다.

• 하나의 메서드가 여러 가지 다른 일을 수행한다.
• 배열 접근, 산술 연산 등 저수준(low-level) 원시 연산을 직접 사용한다.
• 주석이나 명확한 변수/메서드 명명이 부족하다.

이 챕터는 draw와 update라는 두 함수를 예시로, 긴 함수를 분해하는 구체적이고 안전한 방법을 다룬다.

3.1 첫 번째 규칙 정립: 왜 다섯 줄인가?

3.1.1 규칙: Five Lines (다섯 줄)

[Five Lines 규칙]: 하나의 메서드(함수)는 { 와 } 를 제외하고 5줄을 초과해서는 안 된다.

줄(line) 계산 기준:

• if, for, while, 세미콜론으로 끝나는 모든 문(assignments, 메서드 호출, return 등)은 각각 1줄로 계산한다.
• 공백 줄과 중괄호({, })는 계산에서 제외한다.
• else가 붙은 if는 if 1줄로 계산한다.

예시: 5줄이 무엇인지 구체적으로 보여주는 코드

// 2D 배열을 순회하는 정확히 5줄짜리 함수들
function containsEven(arr: number[][]): boolean {
  for (let x = 0; x < arr.length; x++) {
    for (let y = 0; y < arr[x].length; y++) {
      if (arr[x][y] % 2 === 0) {
        return true;
      }
    }
  }
  return false;
}

function minimum(arr: number[][]): number {
  let result = Number.POSITIVE_INFINITY;
  for (let x = 0; x < arr.length; x++) {
    for (let y = 0; y < arr[x].length; y++) {
      result = Math.min(arr[x][y], result);
    }
  }
  return result;
}

이 규칙이 의미하는 것:

• 5줄 제한의 정확한 숫자보다 “제한을 두는 것 자체” 가 중요하다.
• 5줄은 기본 자료구조(2D 배열 등)를 한 번 순회하는 데 필요한 최소 단위에서 유도된 숫자다.
• 각 메서드의 이름이 코드의 의도를 전달하는 기회가 된다 — 사실상 5줄마다 주석을 다는 것과 같은 효과다.
• 20줄짜리 메서드가 있다면, 10줄씩 두 개의 헬퍼 메서드로 분리하고 원본은 2줄이 된다. 이 과정을 반복하면 모든 메서드를 5줄 이하로 만들 수 있다.

코드 스멜(Smell) 연결:

• 긴 메서드는 그 자체로 스멜이다. 모든 로직을 한 번에 머릿속에 담아야 하기 때문이다.
• “메서드는 한 가지 일만 해야 한다 (Methods should do one thing)” — Robert C. Martin, Clean Code

3.2 함수를 분해하는 리팩터링 패턴 도입

긴 함수를 만났을 때, 모든 줄의 세부 내용을 파악하려 하면 오히려 비생산적이다. 대신 코드의 “모양(shape)” 을 먼저 파악한다.

접근 방법:

1. 논리적으로 연관된 줄들의 그룹을 식별한다.
2. 그룹 사이에 빈 줄을 추가하고, 임시 주석을 달아 그룹의 의미를 기록한다.
3. 각 그룹을 새로운 메서드로 추출한다 (주석이 메서드 이름이 된다).

draw 함수 초기 상태와 분해 과정:

// Before: 하나의 함수가 맵 렌더링과 플레이어 렌더링을 모두 담당
function draw() {
  let canvas = document.getElementById("GameCanvas") as HTMLCanvasElement;
  let g = canvas.getContext("2d");
  g.clearRect(0, 0, canvas.width, canvas.height);

  // Draw map
  for (let y = 0; y < map.length; y++) {
    for (let x = 0; x < map[y].length; x++) {
      if (map[y][x] === Tile.FLUX) g.fillStyle = "#ccffcc";
      else if (map[y][x] === Tile.UNBREAKABLE) g.fillStyle = "#999999";
      // ... 이하 생략
      if (map[y][x] !== Tile.AIR && map[y][x] !== Tile.PLAYER)
        g.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
    }
  }

  // Draw player
  g.fillStyle = "#ff0000";
  g.fillRect(playerx * TILE_SIZE, playery * TILE_SIZE, TILE_SIZE, TILE_SIZE);
}

// After: 메서드 추출(Extract Method) 적용 — 주석이 메서드 이름으로 대체됨
function draw() {
  let canvas = document.getElementById("GameCanvas") as HTMLCanvasElement;
  let g = canvas.getContext("2d");
  g.clearRect(0, 0, canvas.width, canvas.height);
  drawMap(g);
  drawPlayer(g);
}

function drawMap(g: CanvasRenderingContext2D) {
  for (let y = 0; y < map.length; y++) {
    for (let x = 0; x < map[y].length; x++) {
      if (map[y][x] === Tile.FLUX) g.fillStyle = "#ccffcc";
      else if (map[y][x] === Tile.UNBREAKABLE) g.fillStyle = "#999999";
      // ... 이하 생략
      if (map[y][x] !== Tile.AIR && map[y][x] !== Tile.PLAYER)
        g.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
    }
  }
}

function drawPlayer(g: CanvasRenderingContext2D) {
  g.fillStyle = "#ff0000";
  g.fillRect(playerx * TILE_SIZE, playery * TILE_SIZE, TILE_SIZE, TILE_SIZE);
}

핵심 인사이트:

• 주석과 메서드 이름은 동일한 정보를 전달한다. 추출이 완료되면 주석을 삭제한다.
• g가 draw에서 선언되었으므로, 추출된 함수의 매개변수로 전달해야 한다. 컴파일러가 이를 자동으로 알려준다.

3.2.1 리팩터링 패턴: 메서드 추출 (Extract Method)

• 설명: 하나의 메서드 내 일부 줄들을 새로운 독립 메서드로 분리한다. 많은 현대 IDE(VS Code 등)가 이 패턴을 내장 기능으로 지원한다. 안전성이 매우 높다.
• 적용 절차:

• 효과: 코드 중복 제거, 함수 책임 분리, 주석 제거(이름으로 대체), 안전한 변환(컴파일러가 오류를 검증)

Pro Tip: return이 일부 분기에만 존재하면 메서드 추출이 어려워진다. 이를 예방하기 위해 메서드의 아래쪽부터 위쪽 방향으로 작업하는 것을 권장한다. 이렇게 하면 return이 자연스럽게 위로 올라가 모든 분기에서 반환하게 된다.

Extract Method 단계별 예시 (2D 배열 최솟값):

// Before: 추출 전 minimum 함수
function minimum(arr: number[][]): number {
  let result = Number.POSITIVE_INFINITY;
  for (let x = 0; x < arr.length; x++)
    for (let y = 0; y < arr[x].length; y++)

      if (result > arr[x][y])   // 이 두 줄을 추출 대상으로 표시
        result = arr[x][y];

  return result;
}

// After: Extract Method 완료 — result에 할당하므로 return/assignment 처리 포함
function minimum(arr: number[][]): number {
  let result = Number.POSITIVE_INFINITY;
  for (let x = 0; x < arr.length; x++)
    for (let y = 0; y < arr[x].length; y++)
      result = min(result, arr, x, y);
  return result;
}

function min(result: number, arr: number[][], x: number, y: number): number {
  if (result > arr[x][y])
    result = arr[x][y];
  return result;
}

안전성에 관한 핵심 철학:

완벽한 결과물을 만드는 것보다, 아무것도 깨뜨리지 않았다는 확신 이 더 가치 있다. 특히 코드가 무슨 일을 하는지 아직 파악하기 전에는 더욱 그렇다. 영리하게 처리하려다 오히려 문제가 생기는 경우가 많다. 컴파일러는 절대 잊지 않는다.

3.3 추상화 수준 균형을 위한 함수 분해

3.3.1 규칙: Either Call or Pass (호출하거나 전달하거나)

[Either Call or Pass 규칙]: 하나의 함수는 어떤 객체의 메서드를 호출(call) 하거나, 그 객체를 인수(argument)로 전달(pass) 하거나, 둘 중 하나만 해야 한다.

규칙 위반 예시와 수정:

// Before: sum(arr)이라는 고수준 추상화와 arr.length라는 저수준 접근이 혼재
function average(arr: number[]): number {
  return sum(arr) / arr.length;
}

// After: size(arr)로 추상화 수준을 통일
function average(arr: number[]): number {
  return sum(arr) / size(arr);
}

이 규칙이 의미하는 것:

• 한 함수 내에서 고수준 메서드 호출과 저수준 원시 연산을 동시에 사용하면, 읽는 사람이 두 수준을 오가며 이해해야 한다.
• 어떤 세부 사항을 추상화로 추출했다면, 같은 함수 내의 다른 세부 사항도 함께 추출해야 한다. 함수 내부의 추상화 수준은 항상 일정해야 한다.
• .(점 표기법)이 있으면 메서드 호출, 인수로 넘겨지면 전달이다. 두 가지가 동시에 나타나면 위반이다.

draw 함수에서의 위반 탐지 및 수정:

// Before: g가 인수로 전달되기도 하고(drawMap, drawPlayer), 직접 메서드 호출도 됨(g.clearRect)
function draw() {
  let canvas = document.getElementById("GameCanvas") as HTMLCanvasElement;
  let g = canvas.getContext("2d");
  g.clearRect(0, 0, canvas.width, canvas.height); // g에 메서드 호출
  drawMap(g);    // g를 인수로 전달
  drawPlayer(g); // g를 인수로 전달
}

// After: 앞 세 줄을 createGraphics()로 추출하여 추상화 수준 통일
function createGraphics(): CanvasRenderingContext2D {
  let canvas = document.getElementById("GameCanvas") as HTMLCanvasElement;
  let g = canvas.getContext("2d");
  g.clearRect(0, 0, canvas.width, canvas.height);
  return g;
}

function draw() {
  let g = createGraphics();
  drawMap(g);
  drawPlayer(g);
}

주의: g.clearRect만 따로 추출하면, canvas를 인수로 전달하면서도 canvas.getContext를 호출하게 되어 규칙을 또 위반한다. 그래서 앞 세 줄 전체를 함께 추출해야 한다.

3.3.2 규칙 적용 시 탐지 방법

• 세부 내용을 읽지 않아도 탐지 가능하다.
• 같은 변수에 .메서드() 호출과 함수(변수) 인수 전달이 동시에 존재하면 위반이다.
• 위반 발견 시 Extract Method로 수정한다.

3.4 좋은 함수 이름의 속성

이름 짓기 실전 기법:

• 주석이 없을 때: 추출할 코드에서 가장 많이 등장하는 단어를 찾는다. update로 시작한 함수에서 input이 자주 보이면 → updateInputs.
• update는 너무 포괄적이다. 맥락상 더 어울리는 handle을 쓰는 것이 낫다 → handleInputs.
• 이름은 나중에 언제든지 재검토한다. 함수가 더 작아지면 더 좋은 이름이 보인다.
• Extract Method는 매개변수(parameter) 이름을 바꿀 기회도 제공한다. 루프 내의 current는 새 함수에서 input으로 더 명확하게 표현할 수 있다.

3.5 너무 많은 일을 하는 함수 분해하기

update 함수에서 Extract Method를 적용하는 전체 흐름:

// Before: update 함수가 입력 처리와 맵 업데이트를 모두 담당
function update() {
  while (inputs.length > 0) {
    let current = inputs.pop();
    if (current === Input.LEFT) moveHorizontal(-1);
    else if (current === Input.RIGHT) moveHorizontal(1);
    else if (current === Input.UP) moveVertical(-1);
    else if (current === Input.DOWN) moveVertical(1);
  }
  // 빈 줄 — 두 그룹의 경계
  for (let y = map.length - 1; y >= 0; y--) {
    for (let x = 0; x < map[y].length; x++) {
      // ... 맵 업데이트 로직
    }
  }
}

// After: 두 그룹을 각각 handleInputs()와 updateMap()으로 추출
function update() {
  handleInputs();
  updateMap();
}

function handleInputs() {
  while (inputs.length > 0) {
    let current = inputs.pop();
    if (current === Input.LEFT) moveHorizontal(-1);
    else if (current === Input.RIGHT) moveHorizontal(1);
    else if (current === Input.UP) moveVertical(-1);
    else if (current === Input.DOWN) moveVertical(1);
  }
}

function updateMap() {
  for (let y = map.length - 1; y >= 0; y--) {
    for (let x = 0; x < map[y].length; x++) {
      // ... 맵 업데이트 로직
    }
  }
}

3.5.1 규칙: if Only at the Start (if는 함수의 시작에만)

[if Only at the Start 규칙]: if가 있다면, 그것은 함수의 첫 번째 문장(statement) 이어야 한다.

설명:

• 무언가를 확인(check) 하는 것은 그 자체로 하나의 책임이다.
• 따라서 if가 있는 함수는 그 if (및 연결된 else if, else)만 해야 한다.
• if의 본문(body)과 else는 코드 구조의 일부이므로 별도로 추출하지 않는다. 구조를 바꾸면 동작이 바뀔 수 있으므로 리팩터링 중에는 구조를 유지한다.
• else if 체인은 원자적(atomic) 단위다. 쪼갤 수 없다.

예시: 소수 출력 함수

// Before: 루프와 if 확인이 하나의 함수에 혼재 (두 가지 책임)
function reportPrimes(n: number) {
  for (let i = 2; i < n; i++)
    if (isPrime(i))
      console.log(`${i} is prime`);
}

// After: 루프(순회 책임)와 조건 확인(판별 책임)을 분리
function reportPrimes(n: number) {
  for (let i = 2; i < n; i++)
    reportIfPrime(i);
}

function reportIfPrime(n: number) {
  if (isPrime(n))
    console.log(`${n} is prime`);
}

3.5.2 규칙 적용: updateMap과 handleInputs

if가 함수 중간에 있는 updateMap 수정:

// Before: for 루프 내부에 if 블록이 중첩 — if가 함수 처음이 아님
function updateMap() {
  for (let y = map.length - 1; y >= 0; y--) {
    for (let x = 0; x < map[y].length; x++) {
      if ((map[y][x] === Tile.STONE || map[y][x] === Tile.FALLING_STONE)
          && map[y + 1][x] === Tile.AIR) {
        map[y + 1][x] = Tile.FALLING_STONE;
        map[y][x] = Tile.AIR;
      } else if ((map[y][x] === Tile.BOX || map[y][x] === Tile.FALLING_BOX)
          && map[y + 1][x] === Tile.AIR) {
        map[y + 1][x] = Tile.FALLING_BOX;
        map[y][x] = Tile.AIR;
      } else if (map[y][x] === Tile.FALLING_STONE) {
        map[y][x] = Tile.STONE;
      } else if (map[y][x] === Tile.FALLING_BOX) {
        map[y][x] = Tile.BOX;
      }
    }
  }
}

// After: if 블록 전체를 updateTile(x, y)로 추출 — updateMap은 5줄 이내로 완료
function updateMap() {
  for (let y = map.length - 1; y >= 0; y--) {
    for (let x = 0; x < map[y].length; x++) {
      updateTile(x, y);
    }
  }
}

function updateTile(x: number, y: number) {
  if ((map[y][x] === Tile.STONE || map[y][x] === Tile.FALLING_STONE)
      && map[y + 1][x] === Tile.AIR) {
    map[y + 1][x] = Tile.FALLING_STONE;
    map[y][x] = Tile.AIR;
  } else if ((map[y][x] === Tile.BOX || map[y][x] === Tile.FALLING_BOX)
      && map[y + 1][x] === Tile.AIR) {
    map[y + 1][x] = Tile.FALLING_BOX;
    map[y][x] = Tile.AIR;
  } else if (map[y][x] === Tile.FALLING_STONE) {
    map[y][x] = Tile.STONE;
  } else if (map[y][x] === Tile.FALLING_BOX) {
    map[y][x] = Tile.BOX;
  }
}

handleInputs에서의 Extract Method 및 이름 개선:

// Before: while 루프 내에 if 체인 혼재
function handleInputs() {
  while (inputs.length > 0) {
    let current = inputs.pop();
    if (current === Input.RIGHT) moveHorizontal(1);
    else if (current === Input.LEFT) moveHorizontal(-1);
    else if (current === Input.DOWN) moveVertical(1);
    else if (current === Input.UP) moveVertical(-1);
  }
}

// After: if 체인을 handleInput으로 추출 — 매개변수 이름도 current → input으로 개선됨
function handleInputs() {
  while (inputs.length > 0) {
    let current = inputs.pop();
    handleInput(current);
  }
}

function handleInput(input: Input) {
  if (input === Input.RIGHT) moveHorizontal(1);
  else if (input === Input.LEFT) moveHorizontal(-1);
  else if (input === Input.DOWN) moveVertical(1);
  else if (input === Input.UP) moveVertical(-1);
}

주목할 인사이트: handleInput은 이미 간결하여 현재 상태로는 Five Lines 규칙을 완전히 충족하기 어렵다 — else if 체인 전체가 하나의 원자 단위이기 때문이다. 이 문제는 4장에서 다루는 우아한 해법(타입 코드 처리)으로 해결한다.

전체 리팩터링 흐름 다이어그램

flowchart TD
    A[긴 함수 발견] --> B{Five Lines 위반?}
    B -- 예 --> C[코드 '모양' 파악\n세부 내용 읽지 않음]
    C --> D[논리적 그룹 식별\n빈 줄 + 임시 주석 추가]
    D --> E[Extract Method 적용\n주석 → 함수 이름]
    E --> F{Either Call or Pass 위반?}
    F -- 예 --> G[같은 수준의 세부 사항을\n함께 추출]
    G --> E
    F -- 아니오 --> H{if Only at the Start 위반?}
    H -- 예 --> I[if 블록 전체를\n별도 함수로 추출]
    I --> E
    H -- 아니오 --> J[규칙 준수 완료]
    B -- 아니오 --> J

챕터 3 요약

Chapter 4. Make Type Codes Work: 타입 코드를 클래스로 대체하기

if-else는 코드에 박혀있는 하드코딩된 결정이다. 하드코딩된 상수를 싫어하듯, 하드코딩된 결정도 싫어해야 한다.

4.1 단순 if 문 리팩터링

4.1.1 규칙: Never use if with else (else가 있는 if 사용 금지)

규칙 (Never use if with else): 우리가 제어하지 않는 데이터 타입을 검사하는 경우가 아니라면, if에 else를 함께 사용하지 않는다.

냄새(Smell): 조기 바인딩(Early Binding)

• if-else는 컴파일 시점에 결정이 고정(lock-in)된다. 이를 조기 바인딩이라 한다.
• 반대로 지연 바인딩(Late Binding) 은 코드가 실행되는 마지막 순간에 동작이 결정된다.
• 조기 바인딩은 수정에 의한 변경(change by modification)만 허용하지만, 지연 바인딩은 추가에 의한 변경(change by addition)을 가능하게 한다.

예외 조건

• 우리가 제어할 수 없는 타입(예: string, KeyboardEvent)을 검사할 때는 else if 체인이 불가피하다.
• 이런 경우는 반드시 프로그램의 경계(edge), 즉 I/O 처리 지점에만 위치해야 한다.
• 외부 데이터 타입은 즉시 우리가 제어하는 타입으로 변환(mapping)한다.

독립적인 if(guard clause)와 if-else(decision)의 구분

• 독립 if: 검사(check). 메서드 시작 부분의 유효성 검증에 허용된다.
• if-else: 결정(decision). 이것이 이 규칙이 금지하는 대상이다.

// Before: else를 사용한 결정 구조 — Early Binding 냄새
function average(ar: number[]) {
  if (size(ar) === 0) throw "Empty array not allowed";
  else return sum(ar) / size(ar);
}

// After: 독립 if(guard)로 분리하여 else 제거
function assertNotEmpty(ar: number[]) {
  if (size(ar) === 0) throw "Empty array not allowed";
}

function average(ar: number[]) {
  assertNotEmpty(ar);
  return sum(ar) / size(ar);
}

의도(Intent)

• if-else는 저수준 흐름 제어 연산자다. 객체 지향 프로그래밍에는 더 강력한 흐름 제어 수단, 즉 객체(objects) 가 있다.
• 인터페이스와 여러 구현 클래스를 사용하면, 어떤 클래스를 인스턴스화하느냐에 따라 실행할 코드가 결정된다.
• 이 규칙은 개발자가 자연스럽게 더 강력하고 유연한 도구인 객체를 탐색하도록 유도한다.

4.1.2 규칙 적용: enum을 인터페이스로 교체하는 절차

다음은 if-else 체인의 초기 상태이다.

// Before: enum 기반 else if 체인 — 새 값 추가 시 전체 체인 수정 필요
function handleInput(input: Input) {
  if (input === Input.LEFT) moveHorizontal(-1);
  else if (input === Input.RIGHT) moveHorizontal(1);
  else if (input === Input.UP) moveVertical(-1);
  else if (input === Input.DOWN) moveVertical(1);
}

절차 요약

1. 임시 이름(Input2)의 새 인터페이스를 도입하고, enum 각 값에 대한 is 메서드를 선언한다.
2. enum 각 값에 대응하는 클래스를 생성한다. 자신에 해당하는 is 메서드만 true를 반환하고 나머지는 false를 반환한다.
3. 기존 enum을 RawInput으로 이름을 변경하여 컴파일러 오류를 통해 사용처를 모두 찾아낸다.
4. 타입을 Input2로 변경하고, 동등성 검사(===)를 새 is 메서드 호출로 대체한다.
5. 나머지 enum 값 참조(Input.RIGHT 등)를 new Right() 형태로 교체한다.
6. 오류가 사라지면 Input2를 Input으로 최종 이름 변경한다.

4.1.3 리팩터링 패턴: Replace type code with classes (타입 코드를 클래스로 교체)

주의사항

• int 같은 숫자형 타입 코드는 추적이 어렵다. 반드시 먼저 enum으로 변환한 후에 이 패턴을 적용한다.
• 각 클래스에 생기는 is 메서드들은 임시적이다. 이후 패턴(Push code into classes)을 통해 대부분 제거된다.

TrafficLight 예시

// Before: enum 기반 타입 코드
enum TrafficLight { RED, YELLOW, GREEN }

function updateCarForLight(current: TrafficLight) {
  if (current === TrafficLight.RED) car.stop();
  else car.drive();
}

// After: 인터페이스 + 클래스로 교체
interface TrafficLight {
  isRed(): boolean;
  isYellow(): boolean;
  isGreen(): boolean;
  updateCar(): void;
}

class Red implements TrafficLight {
  isRed() { return true; }
  isYellow() { return false; }
  isGreen() { return false; }
  updateCar() { car.stop(); }
}

class Yellow implements TrafficLight {
  isRed() { return false; }
  isYellow() { return true; }
  isGreen() { return false; }
  updateCar() { car.drive(); }
}

class Green implements TrafficLight {
  isRed() { return false; }
  isYellow() { return false; }
  isGreen() { return true; }
  updateCar() { car.drive(); }
}

function updateCarForLight(current: TrafficLight) {
  current.updateCar(); // if 완전 제거
}

4.1.4 코드를 클래스로 밀어 넣기 (Push code into classes 적용)

is 메서드를 상수값으로 인라인(inline)하면 if (true) / if (false) 구조가 나타나고, 이를 정리하면 각 클래스에 맞는 단일 동작만 남는다.

// Before: if-else가 남아 있는 중간 단계
class Right implements Input {
  handleInput() {
    if (false) moveHorizontal(-1);
    else if (true) moveHorizontal(1); // isRight() 인라인 결과
    else if (false) moveVertical(-1);
    else if (false) moveVertical(1);
  }
}

// After: false 분기 제거 후 단 하나의 동작만 남음
class Right implements Input {
  handle() { moveHorizontal(1); }
}

전체 결과

// After: 모든 if 제거 완료
function handleInput(input: Input) {
  input.handle();
}

interface Input {
  handle(): void;
}

class Left implements Input {
  handle() { moveHorizontal(-1); }
}
class Right implements Input {
  handle() { moveHorizontal(1); }
}
class Up implements Input {
  handle() { moveVertical(-1); }
}
class Down implements Input {
  handle() { moveVertical(1); }
}

4.1.5 리팩터링 패턴: Push code into classes (코드를 클래스로 이동)

적용 절차

1. 원본 함수를 모든 클래스에 복사하여 붙여넣는다. function 키워드를 제거하고, 컨텍스트 파라미터를 this로 교체한다. 이름이 달라 컴파일 오류가 발생한다.
2. 타깃 인터페이스에 새 메서드 시그니처를 추가하되, 이름을 원본과 약간 다르게 짓는다.
3. 각 클래스의 새 메서드에서 상수를 반환하는 is 메서드를 인라인하고, if (true) / if (false) { ... } 분기를 제거하여 계산을 완료한다. 이름을 최종 이름으로 변경한다.
4. 원본 함수의 본문을 새 메서드 호출 한 줄로 교체한다.

4.1.6 불필요한 메서드 인라인하기

리팩터링 후 handleInput처럼 단 한 줄짜리 위임 메서드가 남으면, 그 메서드는 가독성에 기여하지 못하므로 제거한다.

// Before: 단순 위임만 하는 불필요 메서드 존재
function handleInputs() {
  while (inputs.length > 0) {
    let current = inputs.pop();
    handleInput(current);
  }
}
function handleInput(input: Input) {
  input.handle();
}

// After: handleInput 인라인 후 제거
function handleInputs() {
  while (inputs.length > 0) {
    let input = inputs.pop();
    input.handle();
  }
}

4.1.7 리팩터링 패턴: Inline method (메서드 인라인)

적용 절차

1. 메서드 이름을 임시 이름으로 변경하여 컴파일러 오류로 모든 호출 지점을 찾는다.
2. 메서드 본문을 복사하고 파라미터를 확인한다.
3. 오류가 발생하는 모든 호출 지점에서 호출을 본문으로 교체하고, 인수를 파라미터에 매핑한다.
4. 오류 없이 컴파일되면 원본 메서드를 삭제한다.

인라인하지 말아야 할 경우

• 추상화 수준이 다른 저수준 연산을 담당하는 메서드는 인라인하지 않는다.
• 예: 비트 연산으로 구현된 절댓값 함수는 메서드로 두어야 가독성이 높아진다.

// 인라인하면 안 되는 예 — 저수준 구현이 드러나 가독성이 떨어짐
const NUMBER_BITS = 32;
function absolute(x: number) {
  return (x ^ (x >> (NUMBER_BITS - 1))) - (x >> (NUMBER_BITS - 1));
}

4.2 복잡한 if 문 리팩터링

4.2.1 일반성 제거 (Removing Generality)

일반화된 remove 함수의 문제

• remove(tile: Tile) 함수는 임의의 타일을 제거할 수 있도록 설계되었지만, 실제 호출 코드를 분석하면 Lock1과 Lock2 두 가지만 사용된다.
• 불필요한 일반성(generality)은 책임을 흐리고 변경을 어렵게 만든다.
• 해결책: Specialize method 패턴을 적용해 removeLock1(), removeLock2() 특화 메서드를 도입한다.

// Before: 과도하게 일반화된 함수
function remove(tile: Tile) {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (map[y][x] === tile) map[y][x] = new Air();
}

// After: 실제 사용 패턴에 맞게 특화된 함수들
function removeLock1() {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (map[y][x].isLock1()) map[y][x] = new Air();
}

function removeLock2() {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (map[y][x].isLock2()) map[y][x] = new Air();
}
// 원본 remove는 더 이상 호출되지 않으므로 삭제

4.2.2 리팩터링 패턴: Specialize method (메서드 특화)

적용 절차

1. 특화할 메서드를 복제한다.
2. 복사본의 이름을 새 영구 이름으로 변경하고, 특화 기반이 되는 파라미터를 제거하거나 상수로 교체한다.
3. 오류가 없도록 메서드를 수정하고 단순화한다.
4. 기존 호출 지점을 새 특화 메서드로 전환한다.

체스 예시

// Before: 일반화된 이동 가능 여부 함수
function canMove(start: Tile, end: Tile, dx: number, dy: number) {
  return (
    dx * Math.abs(start.x - end.x) === dy * Math.abs(start.y - end.y) ||
    dy * Math.abs(start.x - end.x) === dx * Math.abs(start.y - end.y)
  );
}
// 호출: canMove(start, end, 1, 0) // 룩(Rook)

// After: 룩에 특화된 메서드 — 주석 없이도 의도가 명확
function rookCanMove(start: Tile, end: Tile) {
  return Math.abs(start.x - end.x) === 0 || Math.abs(start.y - end.y) === 0;
}
// 호출: rookCanMove(start, end)

4.2.3 유일하게 허용되는 switch

외부 데이터(파일, 데이터베이스 등)에서 읽어온 enum 인덱스를 내부 클래스 객체로 변환할 때, switch가 필요하다. 이것이 프로그램 경계(edge)에서 허용되는 유일한 switch다.

// After: 원시 타일 데이터를 객체로 변환하는 경계 함수
function assertExhausted(x: never): never {
  throw new Error("Unexpected object: " + x);
}

function transformTile(tile: RawTile): Tile {
  switch (tile) {
    case RawTile.AIR: return new Air();
    case RawTile.FLUX: return new Flux();
    case RawTile.STONE: return new Stone();
    case RawTile.FALLING_STONE: return new FallingStone();
    case RawTile.BOX: return new Box();
    case RawTile.FALLING_BOX: return new FallingBox();
    case RawTile.KEY1: return new Key1();
    case RawTile.LOCK1: return new Lock1();
    case RawTile.KEY2: return new Key2();
    case RawTile.LOCK2: return new Lock2();
    case RawTile.PLAYER: return new Player();
    case RawTile.UNBREAKABLE: return new Unbreakable();
    default: assertExhausted(tile); // 컴파일러가 모든 케이스 처리 여부를 보장
  }
}

assertExhausted는 TypeScript 특유의 기법으로, default 분기에서 never 타입을 활용해 컴파일러가 모든 enum 값의 처리 여부를 검증하게 만든다.

4.2.4 규칙: Never use switch (switch 사용 금지)

규칙 (Never use switch): default가 없고 모든 case에서 return하는 경우가 아니라면 switch를 사용하지 않는다.

switch의 두 가지 위험 요소

• default의 위험: 새 값이 추가될 때 컴파일러가 처리 누락을 알려주지 않는다. 의도된 기본 처리와 실수로 인한 누락을 구별할 수 없다.
• fall-through의 위험: break를 누락하면 의도치 않게 다음 case가 실행된다. 이 버그는 발견하기 어렵다.

해결책

• default를 두지 않는다.
• 모든 case에서 return한다. 이렇게 하면 fall-through가 불가능해지고 break가 필요 없어진다.

냄새(Smell): Martin Fowler의 책 Refactoring 에서 switch는 그 자체로 코드 냄새(smell)다. switch는 “여기서 값 X를 어떻게 처리할까”라는 컨텍스트 중심 사고를 유도한다. 반면 클래스로 코드를 밀어 넣는 것은 “이 객체(데이터)가 상황 X를 어떻게 처리하는가”라는 데이터 중심 사고를 유도한다.

4.2.5 복합 조건의 ||를 메서드로 추출

moveHorizontal처럼 ||로 연결된 복합 조건은 도메인 지식을 표현한다. 이를 보존하면서 클래스로 밀어 넣으려면 먼저 의미 있는 이름의 메서드로 추출한다.

// Before: 도메인 의미가 없는 원시 조건식
function moveHorizontal(dx: number) {
  if (map[playery][playerx + dx].isFlux() || map[playery][playerx + dx].isAir()) {
    moveToTile(playerx + dx, playery);
  } else if (
    (map[playery][playerx + dx].isStone() || map[playery][playerx + dx].isBox()) &&
    map[playery][playerx + dx + dx].isAir() &&
    !map[playery + 1][playerx + dx].isAir()
  ) {
    map[playery][playerx + dx + dx] = map[playery][playerx + dx];
    moveToTile(playerx + dx, playery);
  }
  // ...
}

// After: ||를 도메인 메서드로 추출한 후 Push code into classes 적용
function moveHorizontal(dx: number) {
  map[playery][playerx + dx].moveHorizontal(dx);
}

interface Tile {
  isEdible(): boolean;   // isFlux() || isAir()
  isPushable(): boolean; // isStone() || isBox()
  moveHorizontal(dx: number): void;
}

class Air implements Tile {
  isEdible() { return true; }
  isPushable() { return false; }
  moveHorizontal(dx: number) { moveToTile(playerx + dx, playery); }
}

class Box implements Tile {
  isEdible() { return false; }
  isPushable() { return true; }
  moveHorizontal(dx: number) {
    if (map[playery][playerx + dx + dx].isAir() && !map[playery + 1][playerx + dx].isAir()) {
      map[playery][playerx + dx + dx] = this;
      moveToTile(playerx + dx, playery);
    }
  }
}

class Key1 implements Tile {
  isEdible() { return false; }
  isPushable() { return false; }
  moveHorizontal(dx: number) {
    removeLock1();
    moveToTile(playerx + dx, playery);
  }
}

핵심 인사이트: Push code into classes는 등가 비교 체인(is 메서드 체인)뿐 아니라, 동일한 인스턴스에 대해 메서드가 반복 호출되는 모든 경우(점(.)의 왼쪽이 동일한 경우)에도 적용 가능하다.

4.3 코드 중복 처리

4.3.1 규칙: Only inherit from interfaces (인터페이스만 상속한다)

규칙 (Only inherit from interfaces): 클래스나 추상 클래스(abstract class)가 아닌, 인터페이스(interface)만 상속(구현)한다.

추상 클래스를 피해야 하는 이유

• 추상 클래스의 공유 코드는 결합도(Coupling) 를 만든다.
• 일부 서브클래스에만 필요한 메서드가 추상 클래스에 있으면, 다른 서브클래스는 빈 메서드로 오버라이드해야 한다.
• 기본 구현(default implementation)이 있으면 새 서브클래스를 추가할 때 컴파일러가 해당 메서드 처리를 강제하지 않는다.

인터페이스를 강제하는 이유

• 새 클래스를 추가할 때 인터페이스의 모든 메서드를 명시적으로 구현하도록 강제된다.
• 6개월 후 코드를 잊어도 새 타일 추가 시 어떤 메서드를 구현해야 하는지 컴파일러가 알려준다.

냄새: GoF(Gang of Four)의 디자인 패턴 책에 있는 원칙 “상속보다 객체 합성을 선호하라(Favor object composition over inheritance)“에서 도출된 규칙이다.

코드 공유가 필요한 경우: 상속 대신 다른 공유 클래스를 참조하는 방식으로 해결한다. 5장의 전략 패턴(Introduce strategy pattern)이 이를 다룬다.

4.3.2 코드 중복에 대한 올바른 이해

코드 중복이 나쁜 이유는 유지보수 시 변경이 전파되기 때문이다. 즉, 수렴해야 할 코드가 중복되어 있을 때 나쁘다.

• 각 타일의 그래픽(draw 메서드)은 타일마다 달라야 하므로 발산(diverge)이 올바른 상태다.
• 이 경우 중복처럼 보이는 코드는 실제로 독립적인 기능이므로, 공유 코드로 만들면 오히려 변경 유연성을 잃는다.

flowchart TD
    A[코드 중복 발견] --> B{미래에 함께 변경되어야 하는가?}
    B -- 예 / 수렴해야 함 --> C[공유 로직으로 통합\nStrategy Pattern 등]
    B -- 아니오 / 독립 변경 가능 --> D[중복 허용\n각 클래스에 개별 구현 유지]

4.4 복잡한 if 문 쌍 리팩터링

drawMap → drawTile 추출 후 Push code into classes 적용 전체 흐름:

flowchart TD
    A["drawMap\n(else if 체인)"] -->|"Extract method (P3.2.1)"| B["colorOfTile\n(is메서드 체인)"]
    B -->|"Replace type code with classes (P4.1.3)"| C["Tile 인터페이스 + 클래스"]
    C -->|"Push code into classes (P4.1.5)"| D["Tile.color(g)"]
    D -->|"Inline method (P4.1.7)"| E["drawMap에서 직접 호출"]
    E -->|"Extract method (P3.2.1)"| F["drawTile(g, x, y)"]
    F -->|"Push code into classes (P4.1.5)"| G["Tile.draw(g, x, y)"]
    G -->|"Inline method (P4.1.7)"| H["drawMap: map[y][x].draw(g, x, y)"]

// After: drawMap 최종 상태 — 규칙 모두 준수
function drawMap(g: CanvasRenderingContext2D) {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      map[y][x].draw(g, x, y);
}

interface Tile {
  color(g: CanvasRenderingContext2D): void;
  draw(g: CanvasRenderingContext2D, x: number, y: number): void;
}

class Air implements Tile {
  color(_g: CanvasRenderingContext2D) { /* 색상 없음 */ }
  draw(_g: CanvasRenderingContext2D, _x: number, _y: number) { /* 그리지 않음 */ }
}

class Flux implements Tile {
  color(g: CanvasRenderingContext2D) { g.fillStyle = "#ccffcc"; }
  draw(g: CanvasRenderingContext2D, x: number, y: number) {
    g.fillStyle = "#ccffcc";
    g.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
  }
}

4.5 불필요한 코드 제거

4.5.1 리팩터링 패턴: Try delete then compile (삭제 후 컴파일)

적용 절차

1. 오류 없이 컴파일되는 상태에서 시작한다.
2. 인터페이스에서 메서드 하나를 삭제한다.
3. 다시 컴파일한다.
   • 오류가 발생하면 실행 취소(undo)하고 다음 메서드로 넘어간다.
   • 오류가 없으면 각 구현 클래스에서도 같은 메서드를 삭제 시도한다.

왜 IDE 자동 분석을 믿을 수 없는가?

• IDE는 인터페이스에 선언된 메서드를 “외부에서 사용될 수 있다”고 가정하므로 unused 표시를 하지 않는다.
• 우리가 직접 도입한 인터페이스는 전체 스코프를 알기 때문에 이 패턴을 안전하게 적용할 수 있다.
• 새 기능을 구현하는 중에는 적용하지 않는다. 아직 사용되지 않는 메서드를 미리 삭제할 수 있기 때문이다.

// Before: 사용 여부가 불분명한 인터페이스 메서드 존재
interface A {
  m1(): void;
  m2(): void;
}

class B implements A {
  m1() { console.log("m1"); }
  m2() { this.m3(); }
  m3() { console.log("m3"); }
}

const a = new B();
a.m1();
// m2, m3은 실제로 사용되지 않음 — Try delete then compile으로 발견 가능

챕터 4 요약

Chapter 5. Fuse Similar Code Together: 유사한 코드 통합하기

코드의 구조는 이미 코드 안에 있다. 우리의 임무는 그것을 발견하고 표면으로 드러내는 것이다.

이 챕터는 updateTile 함수를 출발점으로 삼아, 유사한 클래스/조건/메서드를 하나로 통합하는 일련의 리팩터링 패턴을 다룬다. 중심 주제는 “중복이 숨겨둔 구조를 꺼내 명시적으로 만드는 것”이다.

5.1 유사한 클래스 통합 (Unify Similar Classes)

5.1.1 문제 상황: 상수 메서드(Constant Method)를 가진 쌍둥이 클래스

Stone과 FallingStone은 isFallingStone()의 반환값과 moveHorizontal()의 구현만 다를 뿐, 나머지 모든 메서드가 동일하다. 이처럼 상수를 반환하는 메서드만 다른 클래스들은 하나로 병합할 수 있다.

• 상수 메서드(Constant Method): 항상 고정된 리터럴을 반환하는 메서드
• 기저(Basis): 클래스들을 구별하는 상수 메서드의 집합. X개의 클래스를 통합하려면 최대 (X-1)개의 기저 메서드가 필요하다.

5.1.2 리팩터링 패턴: Unify Similar Classes (P5.1.1)

• 설명: 동일한 상수 메서드 집합(기저)에서 서로 다른 값을 반환하는 클래스들을 하나의 클래스로 병합한다.
• 적용 절차:

1. Phase 1 — 기저 외 메서드 동일화: 각 메서드 본문을 if (true) { } 로 감싼다. true를 각 클래스의 기저 메서드 조건식으로 교체한다. 서로의 메서드 본문을 else if 로 복사·붙여넣기한다.
2. Phase 2 — 클래스 병합: 기저 메서드의 반환값을 저장할 필드를 도입한다. 각 기저 메서드가 상수 대신 필드를 반환하도록 수정한다. 필드를 생성자 파라미터로 승격한다. 컴파일 오류를 따라 기존 호출부에 기본값 인수를 삽입한다. 기저 클래스 하나만 남기고 나머지를 삭제하며 모든 참조를 교체한다.

• 효과: 클래스 수 감소, 숨겨진 구조(타입 코드) 표면화

// Before: Stone과 FallingStone이 두 개의 분리된 클래스로 존재
class Stone implements Tile {
  isFallingStone() { return false; }
  moveHorizontal(dx: number) {
    if (map[playery][playerx+dx+dx].isAir()
      && !map[playery+1][playerx+dx].isAir()) {
      map[playery][playerx+dx+dx] = this;
      moveToTile(playerx+dx, playery);
    }
  }
}
class FallingStone implements Tile {
  isFallingStone() { return true; }
  moveHorizontal(dx: number) { }
}

// After: 하나의 클래스로 통합, FallingState 인터페이스로 타입 코드 제거
interface FallingState {
  isFalling(): boolean;
  moveHorizontal(tile: Tile, dx: number): void;
}
class Falling implements FallingState {
  isFalling() { return true; }
  moveHorizontal(tile: Tile, dx: number) { }
}
class Resting implements FallingState {
  isFalling() { return false; }
  moveHorizontal(tile: Tile, dx: number) {
    if (map[playery][playerx+dx+dx].isAir()
      && !map[playery+1][playerx+dx].isAir()) {
      map[playery][playerx+dx+dx] = tile;
      moveToTile(playerx+dx, playery);
    }
  }
}
class Stone implements Tile {
  constructor(private falling: FallingState) { }
  isFallingStone() { return this.falling.isFalling(); }
  moveHorizontal(dx: number) {
    this.falling.moveHorizontal(this, dx);
  }
}

핵심 통찰: 클래스를 병합하면 불리언 플래그나 열거형(enum) 형태의 숨겨진 타입 코드가 드러난다. 이를 다시 “타입 코드를 클래스로 교체(Replace Type Code with Classes, P4.1.3)” 패턴으로 처리한다.

TypeScript 생성자 단축 문법:

// Before: 명시적 필드 선언과 할당
class Stone implements Tile {
  private falling: FallingState;
  constructor(falling: FallingState) {
    this.falling = falling;
  }
}

// After: 파라미터 앞에 접근 제어자를 붙여 자동 필드 생성
class Stone implements Tile {
  constructor(private falling: FallingState) { }
}

5.1.3 TrafficLight 예시 (세 클래스 통합)

Red, Yellow, Green이라는 세 개의 신호등 클래스를 하나로 통합하는 과정이 8단계 Before/After로 상세 제시된다. 기저 메서드는 color()이며, 비기저 메서드인 check()를 동일화한 뒤 필드로 승격하여 Red(col: string) 하나로 합친다.

5.2 단순 조건 통합 (Combine Ifs)

5.2.1 문제 상황

isFallingStone()과 isFallingBox() 를 각각 검사하는 두 if 블록의 본문이 완전히 동일해졌다. 동일한 본문을 가진 연속된 if 문은 || 로 조건을 합쳐 하나로 줄일 수 있다.

5.2.2 리팩터링 패턴: Combine Ifs (P5.2.1)

• 설명: 연속된 if/else if 블록의 본문이 동일할 때, 두 조건을 || 로 연결하여 단일 if로 병합한다.
• 적용 절차:

1. 두 블록의 본문이 정말 동일한지 확인한다.
2. 두 if 사이의 } else if ( 를 삭제하고 || 를 삽입한다. 전체 조건을 괄호로 감싼다.
3. 단순한 표현식이라면 불필요한 괄호를 제거한다.

• 효과: 두 조건 사이의 관계를 || 로 명시화 → 인터페이스 메서드로 캡슐화 가능

// Before: 동일한 본문을 가진 두 if 블록
if (map[y][x].isFallingStone()) {
  map[y][x].rest();
} else if (map[y][x].isFallingBox()) {
  map[y][x].rest();
}

// After: || 로 조건 통합 후 isFalling() 메서드로 캡슐화
if (map[y][x].isFalling()) {
  map[y][x].rest();
}

핵심 통찰: 이 패턴 자체는 단순하지만, || 표현을 인터페이스 메서드로 흡수하는 후속 패턴을 가능하게 만드는 촉매 역할을 한다.

5.3 복잡한 조건 통합 (Unifying Complex Conditions)

5.3.1 조건 산술(Condition Arithmetic)

조건 표현식은 내용을 알지 못해도 수학 규칙으로 변환·단순화할 수 있다.

• || 는 덧셈(+) 처럼 동작한다.
• && 는 곱셈(×) 처럼 동작한다.
• 따라서 일반 산술의 교환법칙, 결합법칙, 분배법칙이 그대로 적용된다.
• 기억법: ||의 두 줄이 +를 이루고, & 안에 ×가 숨어 있다.

// 분배법칙 적용 예시
isStony() && isAir() || isBoxy() && isAir()
= isStony() * isAir() + isBoxy() * isAir()   // 수학 표현으로
= (isStony() + isBoxy()) * isAir()           // 분배법칙
= (isStony() || isBoxy()) && isAir()         // 코드로 역변환

이를 통해 (isStony() || isBoxy()) && isAir() 에서 || 부분을 canFall() 이라는 메서드로 클래스 안으로 밀어 넣을 수 있다.

// After: 조건 산술로 단순화 후 canFall()로 캡슐화
function updateTile(x: number, y: number) {
  if (map[y][x].canFall() && map[y+1][x].isAir()) {
    map[y][x].drop();
    map[y+1][x] = map[y][x];
    map[y][x] = new Air();
  } else if (map[y][x].isFalling()) {
    map[y][x].rest();
  }
}

5.3.2 규칙: Use Pure Conditions (R5.3.2)

[Use Pure Conditions (R5.3.2)]: 조건식(if, while, for의 조건 부분)은 항상 순수(pure)해야 한다. 순수하다는 것은 부수 효과(side effect)가 없다는 의미이다. 부수 효과란 변수 값 할당, 예외 발생, I/O 조작 등을 포함한다.

• 이유 1: 조건에 부수 효과가 있으면 위의 조건 산술 규칙을 적용할 수 없다.
• 이유 2: 조건의 부수 효과는 개발자가 예상하지 못하므로 발견 비용이 높다.
• 원칙 출처: “쿼리와 커맨드를 분리하라(Separate Queries from Commands)” — Richard Mitchell & Jim McKim

// Before: 부수 효과가 있는 조건 (readLine이 포인터를 전진시킴)
let line: string | null;
while ((line = br.readLine()) !== null) {
  console.log(line);
}

// After: 부수 효과(nextLine)와 조회(readLine)를 분리
for (; br.readLine() !== null; br.nextLine()) {
  const line = br.readLine();
  console.log(line);
}

제어할 수 없는 외부 API처럼 분리가 불가능한 경우, Cacher<T> 유틸리티 클래스로 부수 효과를 분리한다.

// After: Cacher를 이용한 부수 효과 격리
class Cacher<T> {
  private data: T;
  constructor(private mutator: () => T) {
    this.data = this.mutator();
  }
  get() { return this.data; }
  next() { this.data = this.mutator(); }
}

const tmpBr = new Reader();
const br = new Cacher(() => tmpBr.readLine());
for (; br.get() !== null; br.next()) {
  const line = br.get();
  console.log(line);
}

5.4 클래스 간 코드 통합 (Unify Code Across Classes)

5.4.1 전략 패턴 도입 배경

updateTile을 클래스 안으로 밀어 넣은 후, Stone과 Box 두 클래스에 **완전히 동일한 낙하 로직(update 메서드)**이 생겼다. 이는 수렴해야 할 중복이므로 전략 패턴(Strategy Pattern) 을 도입해 공통 로직을 FallStrategy라는 별도 클래스로 추출한다.

flowchart TD
    Stone["Stone\n+update(x,y)\n+moveHorizontal(dx)"] -->|has a| FallStrategy["FallStrategy\n+update(tile,x,y)\n+drop(tile,x,y)"]
    Box["Box\n+update(x,y)"] -->|has a| FallStrategy
    FallStrategy -->|has a| FallingState["FallingState\n+isFalling()"]
    FallingState --> Falling["Falling\n+isFalling(): true"]
    FallingState --> Resting["Resting\n+isFalling(): false"]

5.4.2 UML 클래스 다이어그램 기초 (5.4.1)

UML 클래스 다이어그램은 코드의 구조적 특성을 시각화하기 위해 사용한다.

실용 규칙: Only Inherit from Interfaces (R4.3.2)에 의해 상속 화살표는 사용하지 않는다. 실무에서는 구현과 합성 두 가지 관계로 대부분을 표현할 수 있다.

5.4.3 리팩터링 패턴: Introduce Strategy Pattern (P5.4.2)

• 설명: if 문이나 분기 로직을 별도의 클래스로 이동시켜 변경을 클래스 추가로 처리할 수 있게 만든다. 전략 패턴의 핵심 가치는 런타임에 전혀 알려지지 않은 클래스를 seamless하게 통합하는 최고 수준의 늦은 바인딩(late binding)이다.
• 적용 절차:

1. 격리할 코드에 메서드 추출(Extract Method)을 적용한다. 통합이 목적이라면 두 메서드가 동일해지도록 만든다.
2. 새로운 클래스를 생성한다.
3. 생성자에서 새 클래스를 인스턴스화한다.
4. 추출한 메서드를 새 클래스로 이동시킨다.
5. 필드 의존성이 있으면 필드를 새 클래스로 이전하고 접근자(accessor)를 만든다. 원래 클래스의 오류를 새 접근자로 수정한다.
6. 새 클래스의 잔여 오류를 해결하기 위해 this를 대체하는 파라미터를 추가한다.
7. 1단계의 추출을 인라인 메서드(Inline Method)로 되돌린다.

• 효과: 동일한 로직을 여러 클래스에서 재사용, 변경의 진원지를 단일화

// Before: Stone과 Box에 동일한 update 로직이 중복
class Stone implements Tile {
  constructor(private falling: FallingState) { }
  update(x: number, y: number) {
    if (map[y+1][x].isAir()) {
      this.falling = new Falling();
      map[y+1][x] = this;
      map[y][x] = new Air();
    } else if (this.falling.isFalling()) {
      this.falling = new Resting();
    }
  }
}

// After: FallStrategy로 공통 로직 추출
class FallStrategy {
  constructor(private falling: FallingState) { }
  getFalling() { return this.falling; }

  update(tile: Tile, x: number, y: number) {
    this.falling = map[y+1][x].isAir() ? new Falling() : new Resting();
    this.drop(tile, x, y);
  }

  private drop(tile: Tile, x: number, y: number) {
    if (this.falling.isFalling()) {
      map[y+1][x] = tile;
      map[y][x] = new Air();
    }
  }
}

class Stone implements Tile {
  private fallStrategy: FallStrategy;
  constructor(falling: FallingState) {
    this.fallStrategy = new FallStrategy(falling);
  }
  update(x: number, y: number) {
    this.fallStrategy.update(this, x, y);
  }
  moveHorizontal(dx: number) {
    this.fallStrategy.getFalling().moveHorizontal(this, dx);
  }
}

전략 패턴 vs. 상태 패턴: 전략 클래스에 필드가 있으면 상태 패턴(State Pattern)이라 부르기도 하나, 이는 학술적 구분에 불과하다. 핵심 개념은 동일하다.

5.4.4 규칙: No Interface with Only One Implementation (R5.4.3)

[No Interface with Only One Implementation (R5.4.3)]: 구현체가 하나뿐인 인터페이스는 만들지 않는다.

• 이유: 구현체가 하나인 인터페이스는 가독성을 높이지 않고 오히려 불필요한 일반화(unnecessary generality) 와 인지 오버헤드를 증가시킨다. 인터페이스는 변형 가능성(variation)의 신호인데, 구현체가 하나뿐이면 거짓 신호를 보내는 셈이다.
• 냄새 출처: John Carmack — “추상화는 실제 복잡도를 높이는 대가로 인지된 복잡도를 낮춘다.” 불필요한 추상화는 피해야 한다.
• 예외: 익명 내부 클래스를 위한 인터페이스는 구현체가 0개일 수 있으며 이는 허용된다.

5.4.5 리팩터링 패턴: Extract Interface from Implementation (P5.4.4)

• 설명: 인터페이스가 필요해지는 시점(변형을 도입할 때)까지 인터페이스 생성을 뒤로 미룬다. 필요한 시점이 되면 이 패턴으로 클래스에서 인터페이스를 추출한다.
• 적용 절차:

1. 추출할 클래스와 동일한 이름의 빈 인터페이스를 생성한다.
2. 원래 클래스의 이름을 변경하고 새 인터페이스를 구현(implements)하도록 선언한다.
3. 컴파일 오류를 따라 순서대로 수정한다. new 오류는 새 클래스 이름으로 교체하고, 그 외 오류는 해당 메서드를 인터페이스에 추가한다.

• 효과: 사전에 인터페이스를 설계하지 않아도 변형이 필요한 시점에 빠르게 인터페이스 도입 가능

// Before: SumProcessor 단독 클래스
class SumProcessor {
  constructor(private accumulator: number) { }
  getAccumulator() { return this.accumulator; }
  processElement(e: number) { this.accumulator += e; }
}

// Step 1: 동일한 이름의 빈 인터페이스 생성
interface SumProcessor { }

// Step 2: 클래스 이름 변경 및 인터페이스 구현 선언
class TmpName implements SumProcessor {
  constructor(private accumulator: number) { }
  getAccumulator() { return this.accumulator; }
  processElement(e: number) { this.accumulator += e; }
}

// Step 3: 컴파일 오류 수정 후 최종 결과
interface ElementProcessor {
  processElement(e: number): void;
  getAccumulator(): number;
}
class SumProcessor implements ElementProcessor {
  constructor(private accumulator: number) { }
  getAccumulator() { return this.accumulator; }
  processElement(e: number) { this.accumulator += e; }
}
class MinimumProcessor implements ElementProcessor {
  constructor(private accumulator: number) { }
  getAccumulator() { return this.accumulator; }
  processElement(e: number) {
    if (this.accumulator > e) this.accumulator = e;
  }
}

5.5 유사한 함수 통합 (Unifying Similar Functions)

removeLock1과 removeLock2는 검사 조건(isLock1 vs isLock2)만 다를 뿐 구조가 동일하다. 전략 패턴을 적용해 변화하는 부분(조건 검사)을 RemoveStrategy 인터페이스로 추출한다.

// Before: 거의 동일한 두 함수
function removeLock1() {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (map[y][x].isLock1())
        map[y][x] = new Air();
}
function removeLock2() {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (map[y][x].isLock2())
        map[y][x] = new Air();
}

// After: 전략 패턴으로 통합
interface RemoveStrategy {
  check(tile: Tile): boolean;
}
class RemoveLock1 implements RemoveStrategy {
  check(tile: Tile) { return tile.isLock1(); }
}
class RemoveLock2 implements RemoveStrategy {
  check(tile: Tile) { return tile.isLock2(); }
}

function remove(shouldRemove: RemoveStrategy) {
  for (let y = 0; y < map.length; y++)
    for (let x = 0; x < map[y].length; x++)
      if (shouldRemove.check(map[y][x]))
        map[y][x] = new Air();
}

class Key1 implements Tile {
  moveHorizontal(dx: number) {
    remove(new RemoveLock1());
    moveToTile(playerx + dx, playery);
  }
}

핵심 통찰: 이 변환은 새로운 잠금 타일을 추가하고 싶을 때 remove 함수를 수정하지 않고 새 클래스만 추가하면 된다는 점에서 “변경에 의한 확장(enable change by addition)“을 실현한다.

5.6 유사한 코드 통합 (Unifying Similar Code)

Key1/Key2와 Lock1/Lock2 쌍도 색상 코드만 다를 뿐 거의 동일하다. Unify Similar Classes (P5.1.1) 를 적용해 각 쌍을 Key와 Lock으로 통합한다.

이후, Key와 Lock의 생성자 파라미터(color, removeStrategy, lock1)들이 서로 연결되어 있다는 구조적 사실을 발견한다. 이를 KeyConfiguration이라는 새로운 클래스로 묶어 표현한다.

// After: Key와 Lock의 연결된 파라미터를 KeyConfiguration으로 캡슐화
class KeyConfiguration {
  constructor(
    private color: string,
    private _1: boolean,
    private removeStrategy: RemoveStrategy
  ) { }
  getColor() { return this.color; }
  is1() { return this._1; }
  getRemoveStrategy() { return this.removeStrategy; }
}

const YELLOW_KEY = new KeyConfiguration("#ffcc00", true, new RemoveLock1());

class Key implements Tile {
  constructor(private keyConf: KeyConfiguration) { }
  draw(g: CanvasRenderingContext2D, x: number, y: number) {
    g.fillStyle = this.keyConf.getColor();
    g.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
  }
  moveHorizontal(dx: number) {
    remove(this.keyConf.getRemoveStrategy());
    moveToTile(playerx + dx, playery);
  }
}

class Lock implements Tile {
  constructor(private keyConf: KeyConfiguration) { }
  isLock1() { return this.keyConf.is1(); }
  isLock2() { return !this.keyConf.is1(); }
  draw(g: CanvasRenderingContext2D, x: number, y: number) {
    g.fillStyle = this.keyConf.getColor();
    g.fillRect(x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
  }
}

function transformTile(tile: RawTile) {
  switch (tile) {
    case RawTile.KEY1: return new Key(YELLOW_KEY);
    case RawTile.LOCK1: return new Lock(YELLOW_KEY);
  }
}

핵심 통찰: 코드 통합 과정에서 “색상과 잠금 ID가 연결되어 있다”는 사실이 코드 구조 속에 이미 암묵적으로 존재하던 것이 명시화되었다. 이처럼 리팩터링은 종종 숨겨진 도메인 개념을 발굴하는 수단이 된다. 연결이 우연적인지 의도적인지 확인하는 작업이 중요하다.

챕터 5 요약

Chapter 6. Defend the Data: 데이터 보호하기

불변 조건(Invariant)을 국소화하는 것이 버그 예방의 핵심이다. 캡슐화는 불변 조건이 깨질 수 있는 범위를 클래스 내부로 제한하여, 문제를 추적하고 예방하는 비용을 획기적으로 낮춘다.

챕터 2에서 불변 조건의 국소화(Localization)가 갖는 이점을 논했다. 클래스를 도입하면 관련 기능과 데이터가 응집되어 불변 조건이 자연스럽게 좁은 범위로 모인다. 이 챕터는 한 발 더 나아가, 데이터와 기능에 대한 접근 자체를 제한하는 캡슐화(Encapsulation)에 집중한다.

6.1 Encapsulating without getters: 게터 없는 캡슐화

6.1.1 Rule: Do not use getters or setters (게터/세터를 사용하지 않는다)

[규칙 R6.1.1] Do not use getters or setters: Boolean이 아닌 필드에 대해 직접 값을 반환하거나 대입하는 게터/세터 메서드를 사용하지 않는다.

왜 게터/세터가 문제인가

• 게터의 문제: 객체를 반환하는 순간 캡슐화가 깨진다. 반환된 객체는 외부로 재배포될 수 있고, 외부 코드가 해당 객체의 퍼블릭 메서드를 호출해 내부 상태를 예측 불가능하게 변경한다. 이로 인해 불변 조건이 전역(global)으로 번진다.
• 세터의 문제: 내부 자료구조가 바뀌면 게터의 반환 타입도 함께 바꿔야 하고, 이를 사용하는 외부 코드도 전부 수정해야 한다. 이것이 우리가 피하고자 하는 **강한 결합도(Tight Coupling)**이다.
• 예외: Boolean 필드는 허용한다. Boolean은 그 자체로 의미가 완결되며, 아키텍처 문제를 일으키지 않는다.

풀 기반 아키텍처 vs 푸시 기반 아키텍처

코드 예시: 블로그 포스트 링크 생성

// Before: 풀 기반 - 게터로 데이터를 꺼내 중앙에서 조합
class Website {
  constructor(private url: string) {}
  getUrl() { return this.url; }
}
class User {
  constructor(private username: string) {}
  getUsername() { return this.username; }
}
class BlogPost {
  constructor(private author: User, private id: string) {}
  getId() { return this.id; }
  getAuthor() { return this.author; }
}
function generatePostLink(website: Website, post: BlogPost) {
  const url = website.getUrl();
  const user = post.getAuthor();    // Stranger 객체 획득
  const name = user.getUsername();  // Stranger에게 말 걸기 (Law of Demeter 위반)
  const postId = post.getId();
  return url + name + postId;
}

// After: 푸시 기반 - 연산을 데이터 클래스 안으로 밀어 넣음
class Website {
  constructor(private url: string) {}
  generateLink(name: string, id: string) {
    return this.url + name + id;
  }
}
class User {
  constructor(private username: string) {}
  generateLink(website: Website, id: string) {
    return website.generateLink(this.username, id);
  }
}
class BlogPost {
  constructor(private author: User, private id: string) {}
  generateLink(website: Website) {
    return this.author.generateLink(website, this.id);
  }
}
function generatePostLink(website: Website, post: BlogPost) {
  return post.generateLink(website); // 단 한 줄 - 사실상 인라인 가능
}

냄새(Smell): 데메테르 법칙(Law of Demeter)

• “낯선 사람에게 말 걸지 말라(Don’t talk to strangers)“로 요약된다.
• 낯선 사람이란 직접 참조하지 않고 게터를 통해 얻은 객체를 말한다.
• 게터가 이 법칙 위반의 가장 흔한 원인이다.

의도(Intent)

• 푸시 기반 아키텍처에서 메서드는 서비스처럼 외부에 노출된다.
• 메서드 사용자는 내부 자료구조를 알 필요가 없어진다.

6.1.2 게터 제거 적용 (Applying the rule)

KeyConfiguration의 getRemoveStrategy를 제거하는 실제 과정이다.

단계별 절차

1. 게터를 private으로 변경 → 컴파일 에러가 모든 사용 지점을 드러낸다.
2. 에러가 난 지점에 “코드를 클래스 안으로 밀어 넣기(Push code into classes, P4.1.5)“를 적용한다.
3. 게터는 Push code into classes 과정에서 인라인화되어 불필요해지므로 삭제한다.

// Before: 게터를 통한 간접 접근
class KeyConfiguration {
  private removeStrategy: RemoveStrategy;
  getRemoveStrategy() { return this.removeStrategy; }
}
class Key implements Tile {
  moveHorizontal(dx: number) {
    remove(this.keyConf.getRemoveStrategy()); // 게터 사용
    moveToTile(playerx + dx, playery);
  }
}

// After: 연산이 데이터 소유자(KeyConfiguration) 안으로 이동
class KeyConfiguration {
  private removeStrategy: RemoveStrategy;
  // getRemoveStrategy 삭제됨
  removeLock() {
    remove(this.removeStrategy); // 직접 사용
  }
}
class Key implements Tile {
  moveHorizontal(dx: number) {
    this.keyConf.removeLock(); // 의도가 명확한 메서드 이름
    moveToTile(playerx + dx, playery);
  }
}

setColor는 g.fillStyle에 값을 대입하는 것처럼 보이지만, 규칙 정의상 “필드를 직접 반환/대입하는 메서드”가 아니므로 세터가 아니다. 이름이 아니라 동작 방식으로 판단한다.

6.1.3 Refactoring Pattern: Eliminate getter or setter (게터/세터 제거)

게터와 세터는 구조가 동일하여 같은 절차로 제거할 수 있다.

설명 연산을 데이터 근처로 이동시켜 게터/세터를 제거한다. 게터 하나 대신, 사용 문맥(context)마다 이름이 다른 여러 메서드가 생기는 경우가 많다. 이것이 오히려 코드의 의도를 더 명확하게 표현한다.

• drive() → notifyGreenLight(): 메서드 이름을 “효과” 기반이 아닌 “사용 문맥” 기반으로 명명한다.

적용 절차

1. 게터 또는 세터를 private으로 선언하여 사용 지점에서 컴파일 에러를 발생시킨다.
2. 에러 지점에 Push code into classes (P4.1.5)를 적용한다.
3. 게터/세터가 인라인화되어 불필요해지므로 삭제한다.

효과

• 불변 조건이 클래스 내부로 국소화된다.
• 메서드 이름이 데이터 컨텍스트 대신 호출 컨텍스트를 반영하여 가독성이 향상된다.
• 결합도가 낮아져 내부 자료구조 변경이 외부에 영향을 미치지 않는다.

6.1.4 마지막 게터 제거: FallStrategy.getFalling

FallStrategy의 getFalling 게터도 동일한 3단계 절차로 제거한다.

// Before: getFalling 게터 사용
class Stone implements Tile {
  moveHorizontal(dx: number) {
    this.fallStrategy.getFalling().moveHorizontal(this, dx); // 체이닝 = Demeter 위반
  }
}
class FallStrategy {
  getFalling() { return this.falling; }
}

// After: 연산이 FallStrategy 안으로 이동
class Stone implements Tile {
  moveHorizontal(dx: number) {
    this.fallStrategy.moveHorizontal(this, dx); // 위임
  }
}
class FallStrategy {
  // getFalling 삭제됨
  moveHorizontal(tile: Tile, dx: number) {
    this.falling.moveHorizontal(tile, dx);
  }
}

추가 개선: FallStrategy.drop의 if 문과 update의 삼항 연산자도 규칙을 위반하므로, 이를 Tile과 FallingState 안으로 밀어 넣어 제거한다.

// After: 삼항 연산자와 if를 타입 다형성으로 대체
interface Tile {
  getBlockOnTopState(): FallingState; // 추가
}
class Air implements Tile {
  getBlockOnTopState() { return new Falling(); }
}
class Stone implements Tile {
  getBlockOnTopState() { return new Resting(); }
}

interface FallingState {
  drop(tile: Tile, x: number, y: number): void; // 추가
}
class Falling implements FallingState {
  drop(tile: Tile, x: number, y: number) {
    map[y + 1][x] = tile;
    map[y][x] = new Air();
  }
}
class Resting implements FallingState {
  drop(tile: Tile, x: number, y: number) { /* 아무것도 하지 않음 */ }
}

class FallStrategy {
  update(tile: Tile, x: number, y: number) {
    this.falling = map[y + 1][x].getBlockOnTopState(); // 삼항 연산자 제거
    this.falling.drop(tile, x, y);                     // drop의 if 제거
  }
}

6.2 Encapsulating simple data: 단순 데이터 캡슐화

6.2.1 Rule: Never have common affixes (공통 접두/접미사를 사용하지 않는다)

[규칙 R6.2.1] Never have common affixes: 코드에서 메서드나 변수가 공통 접두사(prefix)나 접미사(suffix)를 갖지 않도록 한다.

설명

• playerx, playery, drawPlayer처럼 같은 접두사/접미사를 공유하는 요소들은 해당 개념에 대한 **응집도(Cohesion)**를 나타내며, 클래스로 묶어야 한다는 신호다.
• 클래스로 묶으면 내부 구현을 숨길 수 있어, 글로벌 스코프를 오염시키지 않고 인터페이스를 완전히 통제할 수 있다.
• 데이터를 숨김으로써 그 불변 조건이 클래스 내부에서만 유지되며, 이것이 국소 불변 조건(Local Invariant)이 된다.

냄새(Smell): 단일 책임 원칙(Single Responsibility Principle)

• 이 규칙은 클래스 수준의 “메서드는 한 가지 일만 한다”와 동일한 원칙이다.
• 공통 접사는 클래스가 하나의 하위 책임을 과도하게 맡고 있다는 증거다.
• 중요한 점은, 이 원칙은 사전 설계보다 코드에서 보이는 증상을 통해 사후에 발견할 수 있다.

은행 계좌 예시

// Bad: 공통 접두사 account를 가진 전역 함수들
function accountDeposit(to: string, amount: number) {
  const accountId = database.find(to);
  database.updateOne(accountId, { $inc: { balance: amount } });
}
function accountTransfer(amount: number, from: string, to: string) {
  accountDeposit(from, -amount);
  accountDeposit(to, amount);
}
// 문제: deposit을 직접 호출하면 돈이 공중에서 생겨날 수 있다.

// Good: Account 클래스로 캡슐화 - deposit은 private
class Account {
  private deposit(to: string, amount: number) {
    const accountId = database.find(to);
    database.updateOne(accountId, { $inc: { balance: amount } });
  }
  transfer(amount: number, from: string, to: string) {
    this.deposit(from, -amount); // 항상 차감 먼저
    this.deposit(to, amount);
  }
}
// 효과: 불변 조건("이체는 항상 출금 후 입금")이 클래스 내부로 국소화됨

6.2.2 게임 코드에서 규칙 적용: Player 클래스 생성

playerx, playery, drawPlayer는 공통 접두사 player를 공유하므로 Player 클래스로 묶는다.

적용 절차 요약

1. Player 클래스를 생성한다.
2. playerx, playery를 클래스 내부로 이동하고 private으로 변경한다. 접두사 player를 이름에서 제거하고, 임시 게터/세터를 생성한다.
3. 컴파일 에러를 이용해 모든 참조 지점을 찾아 수정한다.
   • a. 인스턴스 변수명(player)을 결정한다.
   • b. 모든 직접 접근을 게터/세터로 교체한다.
   • c. 두 개 이상의 메서드에서 에러가 나면, player: Player를 첫 번째 파라미터로 추가한다.
   • d. 에러가 하나의 메서드에만 남을 때까지 c를 반복한다.
   • e. 변수가 선언되었던 위치에 let player = new Player()를 배치한다.
4. drawPlayer를 클래스 안으로 밀어 넣고, 원본 함수를 인라인(Inline method)한다.
5. 게터/세터를 Eliminate getter or setter로 제거한다.

// After: 게터/세터가 모두 제거된 최종 Player 클래스
class Player {
  private x = 1;
  private y = 1;

  draw(g: CanvasRenderingContext2D) {
    g.fillStyle = "#ff0000";
    g.fillRect(this.x * TILE_SIZE, this.y * TILE_SIZE, TILE_SIZE, TILE_SIZE);
  }
  moveHorizontal(dx: number) {
    map[this.y][this.x + dx].moveHorizontal(this, dx);
  }
  move(dx: number, dy: number) {
    this.moveToTile(this.x + dx, this.y + dy);
  }
  pushHorizontal(tile: Tile, dx: number) {
    if (map[this.y][this.x + dx + dx].isAir()
      && !map[this.y + 1][this.x + dx].isAir()) {
      map[this.y][this.x + dx + dx] = tile;
      this.moveToTile(this.x + dx, this.y);
    }
  }
  private moveToTile(newx: number, newy: number) {
    map[this.y][this.x] = new Air();
    map[newy][newx] = new PlayerTile();
    this.x = newx;
    this.y = newy;
  }
}
let player = new Player();

6.2.3 Refactoring Pattern: Encapsulate data (데이터 캡슐화)

설명 변수와 메서드를 클래스 안으로 이동시켜 접근 범위를 제한하고 구조를 명시적으로 만든다. 메서드를 캡슐화하면 이름이 단순해지고 응집도가 높아진다. 가장 큰 이점은 변수 캡슐화로, 불변 조건을 검증할 때 클래스 내부 코드만 확인하면 된다.

적용 절차

1. 클래스를 생성한다.
2. 변수를 클래스 내부로 이동시키고 let → private으로 변경한다. 이름을 단순화하고, 임시 게터/세터를 생성한다.
3. 컴파일 에러가 모든 참조 지점을 드러낸다. 다음 5단계로 수정한다.
   • a. 새 클래스의 인스턴스 변수명을 결정한다.
   • b. 직접 접근을 게터/세터로 교체한다.
   • c. 두 개 이상의 메서드에서 에러가 나면, 인스턴스를 첫 번째 파라미터로 추가한다.
   • d. 에러가 하나의 메서드에만 남을 때까지 c를 반복한다.
   • e. 변수가 선언되었던 위치에 클래스를 인스턴스화한다. (루프 안에 넣는 실수 방지)

주의: 클래스 인스턴스화 위치를 루프 내부에 잘못 배치하면 컴파일은 되지만 동작이 달라진다. 캡슐화한 변수가 원래 있던 위치에 인스턴스를 생성해야 한다.

효과

• 불변 조건 검증 범위가 클래스 내부로 축소된다.
• 관련 메서드의 이름을 단순화할 수 있다.
• 클래스가 많아지고 작아지며, 이는 아키텍처 관점에서 바람직하다.
• null 참조 오류를 예방한다. (파라미터로 전달하므로 사용 전 반드시 인스턴스화)

6.3 Encapsulating complex data: 복잡한 데이터 캡슐화

게임 코드에는 map, transformMap, updateMap, drawMap이라는 공통 접미사 map을 가진 그룹이 있다. Encapsulate data 패턴을 Map 클래스에 적용한다.

과정 요약

1. Map 클래스를 생성한다.
2. map 변수를 Map 내부로 이동하고, getMap()/setMap() 게터/세터를 임시 생성한다.
3. 모든 참조를 파라미터 전파(parameter propagation)로 수정한다. Tile 인터페이스의 메서드에도 map: Map이 추가된다.
4. transformMap, updateMap, drawMap을 Push code into classes로 Map.transform(), Map.update(), Map.draw()로 이동시키고 원본을 인라인한다.
5. getMap() 게터를 Eliminate getter or setter로 제거한다. 이 과정에서 연산들이 Map 내부로 점진적으로 이동한다.

// After: Map 클래스가 내부 배열 접근을 완전히 숨김
class Map {
  private map: Tile[][];

  constructor() { /* transform 로직이 생성자로 이동 */ }

  update() {
    for (let y = this.map.length - 1; y >= 0; y--)
      for (let x = 0; x < this.map[y].length; x++)
        this.map[y][x].update(this, x, y);
  }
  draw(g: CanvasRenderingContext2D) {
    for (let y = 0; y < this.map.length; y++)
      for (let x = 0; x < this.map[y].length; x++)
        this.map[y][x].draw(g, x, y);
  }
  isAir(x: number, y: number) { return this.map[y][x].isAir(); }
  setTile(x: number, y: number, tile: Tile) { this.map[y][x] = tile; }
  movePlayer(x: number, y: number, newx: number, newy: number) {
    this.map[y][x] = new Air();
    this.map[newy][newx] = new PlayerTile();
  }
  remove(shouldRemove: RemoveStrategy) {
    for (let y = 0; y < this.map.length; y++)
      for (let x = 0; x < this.map[y].length; x++)
        if (shouldRemove.check(this.map[y][x]))
          this.map[y][x] = new Air();
  }
  pushHorizontal(player: Player, tile: Tile, x: number, y: number, dx: number) {
    if (this.map[y][x + dx + dx].isAir() && !this.map[y + 1][x + dx].isAir()) {
      this.map[y][x + dx + dx] = tile;
      player.moveToTile(this, x + dx, y);
    }
  }
}

setTile은 map 배열에 대한 거의 완전한 접근권을 외부에 주지만, 겁내지 말고 코드를 추가한다. 이후에 setTile이 Map 내부에서만 쓰인다고 확인되면 private으로 변경하거나 삭제한다.

6.4 Eliminating a sequence invariant: 순서 불변 조건 제거

6.4.1 Refactoring Pattern: Enforce sequence (순서 강제)

배경: Map은 다른 메서드를 호출하기 전에 반드시 map.transform()을 먼저 호출해야 하는 **순서 불변 조건(Sequence Invariant)**을 갖는다. 이를 잊으면 버그가 발생한다.

해결책: transform을 생성자(constructor)로 변환한다. 생성자는 언제나 가장 먼저 실행되므로, 불변 조건이 컴파일러에 의해 자동으로 강제된다.

// Before: 순서를 수동으로 기억해야 함
class Map {
  transform() { /* 초기화 로직 */ }
}
window.onload = () => {
  map.transform(); // 까먹으면 버그
  gameLoop(map);
};

// After: 생성자가 순서를 강제 - 불변 조건이 사라짐
class Map {
  constructor() { /* 초기화 로직 */ }
}
window.onload = () => {
  // transform() 호출 불필요 - 인스턴스 생성 시 자동 실행
  gameLoop(map);
};

설명 컴파일러에게 실행 순서를 “가르치는” 가장 우아한 리팩터링 기법 중 하나다. 객체 지향 언어의 기본 보장 — “생성자는 항상 메서드보다 먼저 실행된다” — 을 활용한다. **클래스의 인스턴스 자체가 “해당 코드가 실행되었다는 증거”**가 된다.

두 가지 변형

적용 절차

1. “나중에 실행되어야 하는” 메서드에 Encapsulate data (P6.2.3)를 적용한다.
2. 생성자가 “먼저 실행되어야 하는” 메서드를 호출하도록 만든다.
3. 두 메서드의 인수가 연관되어 있다면 해당 인수를 필드로 만들고, 메서드에서 인수를 제거한다.

은행 계좌 예시 (완성형)

// After: 생성자가 출금을 먼저 강제하는 Transfer 클래스
class Transfer {
  constructor(from: string, private amount: number) {
    this.depositHelper(from, -this.amount); // 항상 먼저 실행
  }
  private depositHelper(to: string, amount: number) {
    const accountId = database.find(to);
    database.updateOne(accountId, { $inc: { balance: amount } });
  }
  deposit(to: string) {
    this.depositHelper(to, this.amount); // 나중에 호출
  }
}
// 사용법: new Transfer("Alice", 100).deposit("Bob")
// Transfer 인스턴스가 존재한다는 것 자체가 "출금이 완료됐다는 증거"