Extract Method Object Skill

지역 변수가 상호 의존해 Extract Method가 어려운 거대 메서드를 별도 클래스로 추출.

GOAL

• 성공 = 지역 변수가 상호 의존하는 긴 메서드가 Method Object로 추출되어 커밋 완료됨
• 50줄 이상의 복잡한 메서드가 식별됨
• 지역 변수가 메서드 전역에 걸쳐 상호 의존해 Extract Method 불가
• 후보 보고 후 Method Object 패턴 적용 (Tidy 계열 — 승인 없이)
• 모든 테스트 통과

CONSTRAINTS

• 계열: Tidy — 후보 보고 후 승인 없이 적용 (../../references/refactoring-procedure.md §0·§3-A)

Hard Rules

• 동작 변경 금지 — 구조 개선만 수행
• 테스트 수정 금지 — 구조 변경이 테스트를 실패시키면 되돌리기
• 커밋 단위 — 1파일 x 1기법 = 1커밋 (논리적으로 연결된 파일은 함께)
• git add -A 금지 — 변경된 파일만 명시적으로 추가

적용 패턴

Extract Method Object 리팩토링 단계:

1. 메서드를 클래스로 변환

   • 새 클래스 생성 (메서드명 + "er" 또는 명사형)
   • 원본 메서드를 invoke() 또는 execute() 메서드로 이동

2. 지역 변수를 필드로 변환

   • 메서드 내 지역 변수들을 클래스 필드로 변환
   • 읽기 전용 변수는 final 필드로

3. 외부 의존성을 생성자 파라미터로 전달

   • 원본 클래스의 필드 참조를 생성자 파라미터로
   • 필요한 최소한의 의존성만 전달

4. 작은 메서드로 분해

   • 큰 invoke() 메서드를 의미 있는 작은 private 메서드들로 분해
   • 각 메서드는 단일 책임 수행

Before/After 예시

// Before: 지역 변수가 상호 의존하는 거대 메서드 (50+ lines)
public class RefundService {
    public List<RefundDiff> refundDiff() {
        // 지역 변수 선언
        Map<String, Cost> costMap = new HashMap<>();
        Map<String, AcmeCost> acmeCostMap = new HashMap<>();
        List<RefundDiff> differences = new ArrayList<>();
        
        // 복잡한 로직이 50줄 이상...
        for (Cost cost : costs) {
            costMap.put(cost.getItemId(), cost);
        }
        
        for (AcmeCost acmeCost : acmeCosts) {
            acmeCostMap.put(acmeCost.getItemId(), acmeCost);
        }
        
        for (OrderItem item : orderItems) {
            Cost cost = costMap.get(item.getItemId());
            AcmeCost acmeCost = acmeCostMap.get(item.getItemId());
            
            if (cost != null && acmeCost != null) {
                double diff = cost.getAmount() - acmeCost.getAmount();
                if (Math.abs(diff) > 0.01) {
                    differences.add(new RefundDiff(item, diff));
                }
            }
        }
        
        return differences;
    }
}

// After: Method Object로 추출
public class RefundService {
    public List<RefundDiff> refundDiff() {
        return new RefundDifferenceCalculator(costs, acmeCosts).invoke(orderItems);
    }
}

class RefundDifferenceCalculator {
    private final List<Cost> costs;
    private final List<AcmeCost> acmeCosts;
    private Map<String, Cost> costMap;
    private Map<String, AcmeCost> acmeCostMap;
    private List<RefundDiff> differences;
    
    RefundDifferenceCalculator(List<Cost> costs, List<AcmeCost> acmeCosts) {
        this.costs = costs;
        this.acmeCosts = acmeCosts;
    }
    
    List<RefundDiff> invoke(List<OrderItem> orderItems) {
        buildCostMaps();
        calculateDifferences(orderItems);
        return differences;
    }
    
    private void buildCostMaps() {
        costMap = costs.stream()
            .collect(Collectors.toMap(Cost::getItemId, c -> c));
        acmeCostMap = acmeCosts.stream()
            .collect(Collectors.toMap(AcmeCost::getItemId, c -> c));
    }
    
    private void calculateDifferences(List<OrderItem> orderItems) {
        differences = new ArrayList<>();
        for (OrderItem item : orderItems) {
            findAndAddDifference(item);
        }
    }
    
    private void findAndAddDifference(OrderItem item) {
        Cost cost = costMap.get(item.getItemId());
        AcmeCost acmeCost = acmeCostMap.get(item.getItemId());
        
        if (cost != null && acmeCost != null) {
            addDifferenceIfSignificant(item, cost, acmeCost);
        }
    }
    
    private void addDifferenceIfSignificant(OrderItem item, Cost cost, AcmeCost acmeCost) {
        double diff = cost.getAmount() - acmeCost.getAmount();
        if (Math.abs(diff) > 0.01) {
            differences.add(new RefundDiff(item, diff));
        }
    }
}

적용 기준

Extract Method Object를 적용해야 하는 경우:

1. 메서드 길이: 50줄 이상의 긴 메서드
2. 지역 변수 상호 의존(entanglement): 여러 지역 변수가 메서드 전체에 걸쳐 상호작용
3. Extract Method 불가: 파라미터가 너무 많아져 Extract Method로 분해 불가
4. 임시 변수 과다: 중간 결과를 저장하는 임시 변수가 많음
5. 단계적 계산: 여러 단계의 계산이 순차적으로 진행됨

신규 기능 추가 경로 — 계획된 목표 구조로서의 Method Object

Method Object는 레거시 개선용만이 아니다. 새 기능을 추가할 때 처음부터 목표 구조로 계획하면 다음 3단계 경로가 효과적이다:

1. 검증 조건을 테스트로 먼저 확정 — 정확한 기대값을 가진 인수 테스트를 구현 전에 작성한다.
2. 새 클래스 하나에 절차적으로 구현 — WELC(Working Effectively with Legacy Code)의 Sprout Class처럼 정적 메서드 하나를 진입점으로 노출해 기존 호출부 변경을 한 줄로 최소화한다. 이 단계는 절차적으로 구현한다 (make it work).
3. 절차를 Method Object로 변환 — 상태가 없는 순수 계산이라도, 메서드 간 인자 전달을 최소화하기 위해 입력을 final 필드로 받는 객체로 전환한다. 정적 진입점은 유지한다:

// public API는 처음부터 끝까지 정적 메서드 하나 — 내부가 절차→객체로 바뀌어도 호출부 불변
public static BigDecimal calculate(final Line[] lines) {
    return new TaxCalculator(List.of(lines)).total();
}

이 경로에서는 내부 구조 변화(절차 → 객체, 메서드 분해, 인자 제거)가 호출부에 전혀 전파되지 않아, 각 단계를 독립적인 작은 refactor: 커밋으로 안전하게 진행할 수 있다.

추출 후 데이터 결정 — 무엇을 필드로, 무엇을 파라미터로

Method Object 내부의 데이터는 세 종류로 나뉘고, 종류마다 답이 다르다:

데이터 종류	예	판정
입력 (생성자로 받는 본질적 상태)	주문 라인 목록	final 필드 — 전체를 순회·합산하는 메서드들의 인자가 사라진다
파생값 (계산 도중의 중간 결과)	과세표준, 세액	파라미터 유지(데이터 흐름이 시그니처에 명시) 또는 no-arg 질의로 전환(replace-temp-with-query). 가변 필드에 저장하는 방식은 호출 순서 결합(temporal coupling)을 만들므로 피한다
loop 변수 (반복마다 다른 값)	개별 라인	파라미터 필수 — 호출마다 값이 달라 필드화 불가능

explicit-parameters 스킬과의 경계: explicit-parameters는 협력 객체 의존성(Singleton·전역 상태·서비스)을 파라미터로 드러내는 기법이다. Method Object의 입력·계산 상태 필드는 그 스킬의 대상이 아니다 — 방향이 반대인 두 스킬은 적용 대상이 달라 충돌하지 않는다.

OUTPUT FORMAT

실행 절차

공통 골격(대상 파일 수집 → 후보 제시(계열별 승인 규칙) → 적용 → 테스트 → 커밋/되돌리기, 브랜치·PR이 필요한 조건)은 이 스킬 디렉터리 기준 ../../references/refactoring-procedure.md가 정본이다. 아래는 이 기법에 고유한 부분만 규정한다.

Method Object 후보 식별 (공통 절차 2단계)

대상 파일에서 다음 패턴을 찾는다:

• 50줄 이상의 긴 메서드
• 5개 이상의 지역 변수 선언
• 지역 변수가 메서드 전체에 걸쳐 읽기/쓰기됨
• Extract Method 시 파라미터가 4개 이상 필요
• 여러 단계의 계산이 순차적으로 진행

후보 제시 예시 (공통 절차 3단계)

후보를 보고하고 즉시 적용한다(Tidy 계열 — 정본 §3-A):

## 리팩토링 후보 1: Extract Method Object

**파일**: RefundService.java
**대상**: refundDiff() 메서드 (68줄)

**현재 코드**:
[해당 메서드 전체]

**지역 변수 분석**:
- costMap, acmeCostMap, differences (메서드 전체에서 사용)
- 5개 이상의 지역 변수가 상호 의존함
- Extract Method 불가 (파라미터 6개 필요)

**제안 변경**:
1. RefundDifferenceCalculator 클래스 생성
2. 지역 변수를 필드로 변환
3. costs, acmeCosts를 생성자 파라미터로
4. invoke(orderItems) 메서드로 계산 수행
5. buildCostMaps(), calculateDifferences() 등으로 분해

→ 승인 없이 적용 (Tidy 계열)

Method Object 추출 실행 (공통 절차 4단계)

확정된 리팩토링을 하나씩 수행:

1. Method Object 클래스 생성 및 메서드 이동
2. 지역 변수를 필드로 변환
3. 외부 의존성을 생성자 파라미터로
4. 작은 메서드로 분해

커밋 메시지 형식:

refactor: extract method object [클래스명] from [원본클래스명].[메서드명]

결과 보고

사용자에게 보고:

• 적용된 Method Object 목록

FAILURE CONDITIONS

공통 실패 조건(계열별 승인 규칙 위반, 테스트 실패 방치, 테스트 수정, 커밋 단위, git add -A, heredoc 한글 메시지)은 ../../references/refactoring-procedure.md에 있다. 아래는 이 기법에 고유한 것만.

• 지역 변수가 적은 (3개 이하) 단순 메서드에 적용 (Extract Method로 충분)
• Method Object 생성 후 작은 메서드로 분해하지 않음 (단순히 코드만 옮김)
• 필요 이상의 의존성을 생성자로 전달 (원본 클래스 전체 전달 등)