[Design Patterns] 02. 패턴 분석의 프레임워크

1
2
3
4

□ 해결하려는 핵심 문제가 명확한가?
□ 문제의 범위가 적절히 정의되었는가?
□ 해결책의 본질이 간결하게 표현되었는가?
□ 다른 패턴과 구분되는 고유성이 있는가?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Context: 전략을 사용하는 주체
public class SortContext {
    private SortStrategy strategy;  // 의존성 주입 지점
    
    public void setStrategy(SortStrategy strategy) {
        this.strategy = strategy;   // 런타임 교체 가능
    }
    
    public void executeSort(int[] data) {
        strategy.sort(data);        // 위임(delegation)
    }
}

// Strategy: 알고리즘의 공통 인터페이스
public interface SortStrategy {
    void sort(int[] data);          // 템플릿 메서드
}

// ConcreteStrategy: 구체적 구현
public class QuickSortStrategy implements SortStrategy {
    public void sort(int[] data) {
        Arrays.sort(data);  // java.util.Arrays의 이중 피벗 퀵정렬에 위임 (표준 라이브러리 우선)
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

// Client: 명령을 조립하는 역할
public class MacroRecorder {
    public void createMacro() {
        Command[] commands = {
            new CopyCommand(editor),
            new PasteCommand(editor),
            new SaveCommand(editor)
        };
        MacroCommand macro = new MacroCommand(commands);
        invoker.setCommand(macro);
    }
}

// Invoker: 명령을 실행하는 역할
public class MenuButton {
    private Command command;
    
    public void click() {
        command.execute();  // 구체적 명령을 몰라도 실행 가능
    }
}

// Command: 명령의 추상화
public interface Command {
    void execute();
    void undo();           // 실행 취소 지원
}

// ConcreteCommand: 구체적 명령 구현
public class CopyCommand implements Command {
    private TextEditor receiver;
    private String backup;
    
    public void execute() {
        backup = receiver.getSelection();
        receiver.copy();
    }
    
    public void undo() {
        receiver.setSelection(backup);
    }
}

// Receiver: 실제 작업을 수행하는 객체
public class TextEditor {
    public void copy() { /* 실제 복사 로직 */ }
    public void paste() { /* 실제 붙여넣기 로직 */ }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Subject.notifyObservers() 호출 시:

1. Subject → Observer1: update()
2. Subject → Observer2: update()  
3. Subject → Observer3: update()

Observer.update() 내부에서:

4. Observer1 → Subject: getState()
5. Observer1: updateInternalState()
6. Observer2 → Subject: getState()
7. Observer2: updateInternalState()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// 예시: 로깅 시스템에서 Strategy 패턴 적용 검토

// 현재 상황
public class Logger {
    public void log(String message, LogLevel level) {
        if (level == LogLevel.DEBUG) {
            System.out.println("[DEBUG] " + message);
        } else if (level == LogLevel.INFO) {
            writeToFile("[INFO] " + message);
        } else if (level == LogLevel.ERROR) {
            sendToSentry("[ERROR] " + message);
        }
    }
}

// Strategy 패턴 적용 가능성 평가

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

- 알고리즘이 여러 개인가? 
   → YES: DEBUG/INFO/ERROR 각각 다른 출력 방식

- 런타임에 알고리즘을 변경해야 하는가?
   → YES: 환경(개발/운영)에 따라 로깅 방식 변경

- 새로운 알고리즘이 추가될 가능성이 있는가?
   → YES: WARN 레벨, 외부 모니터링 시스템 연동 등

- 알고리즘들이 공통 인터페이스를 가질 수 있는가?
   → YES: log(String message) 인터페이스로 통일 가능

- 알고리즘들 간에 상태 공유가 필요한가?
   → NO: 각 로그 전략은 독립적

결론: Strategy 패턴 적용 적합

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 옵션 1: Proxy 패턴
public class CacheProxy implements DataService {
    private DataService realService;
    private Map<String, Object> cache = new HashMap<>();
    
    public Object getData(String key) {
        if (cache.containsKey(key)) {
            return cache.get(key);
        }
        Object data = realService.getData(key);
        cache.put(key, data);
        return data;
    }
}

// 옵션 2: Decorator 패턴 (캐싱 로직은 Proxy와 동일하므로 computeIfAbsent로 축약)
public class CacheDecorator implements DataService {
    private final DataService wrappedService;
    private final Map<String, Object> cache = new HashMap<>();

    public Object getData(String key) {
        return cache.computeIfAbsent(key, wrappedService::getData);
    }
}

// 옵션 3: Strategy 패턴
public class DataServiceContext {
    private CacheStrategy cacheStrategy;
    private DataService dataService;
    
    public Object getData(String key) {
        return cacheStrategy.getData(key, dataService);
    }
}

1
2
3
4

선택 기준:
- 단순 캐싱만 필요 → Proxy
- 캐싱 + 로깅 + 압축 등 다중 기능 → Decorator  
- 캐싱 전략을 런타임에 변경 → Strategy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// 일반 객체 방식: 성능 우수, 유연성 낮음
public class Character {
    private char character;
    private Font font;
    private Color color;
    private int x, y;
    
    // 10,000개 문자 = 10,000개 Font, Color 객체
}

// Flyweight 방식: 메모리 효율적, 복잡성 증가
public class CharacterFlyweight {
    private char character;
    private Font font;      // intrinsic state (공유)
    private Color color;    // intrinsic state (공유)
    
    public void render(int x, int y, Graphics g) {
        // extrinsic state는 파라미터로 전달
    }
}

public class CharacterFactory {
    private Map<String, CharacterFlyweight> flyweights = new HashMap<>();
    
    public CharacterFlyweight getFlyweight(char c, Font f, Color col) {
        String key = c + f.toString() + col.toString();
        return flyweights.computeIfAbsent(key, 
            k -> new CharacterFlyweight(c, f, col));
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

10,000개 문자 객체 생성 시:

일반 방식:
- 메모리 사용량: ~40MB (4KB × 10,000)
- 생성 시간: ~50ms
- 접근 시간: ~1ns (직접 접근)

Flyweight 방식:
- 메모리 사용량: ~1MB (공유 객체 + 팩토리)
- 생성 시간: ~20ms (중복 제거)
- 접근 시간: ~100ns (HashMap 조회)

결론: 메모리가 중요하면 Flyweight, 속도가 중요하면 일반 방식

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// 단순한 팩토리: 복잡성 낮음, 재사용성 낮음
public class ButtonFactory {
    public Button createButton(String os) {
        if ("Windows".equals(os)) {
            return new WindowsButton();
        } else if ("Mac".equals(os)) {
            return new MacButton();
        }
        throw new IllegalArgumentException("Unsupported OS");
    }
}

// Abstract Factory: 복잡성 높음, 재사용성 높음
public abstract class GUIFactory {
    public abstract Button createButton();
    public abstract Checkbox createCheckbox();
    public abstract Menu createMenu();
}

public class WindowsFactory extends GUIFactory {
    public Button createButton() { return new WindowsButton(); }
    public Checkbox createCheckbox() { return new WindowsCheckbox(); }
    public Menu createMenu() { return new WindowsMenu(); }
}

public class MacFactory extends GUIFactory {
    public Button createButton() { return new MacButton(); }
    public Checkbox createCheckbox() { return new MacCheckbox(); }
    public Menu createMenu() { return new MacMenu(); }
}

1
2
3
4
5
6
7

구현 방식          | 클래스 수 | Cyclomatic | 이해 시간(예시) | 확장 비용
Simple Factory    |    3     |     3      |     5분        |   높음
Abstract Factory  |    12    |     8      |     30분       |   낮음

비교 기준:
- 제품군이 2개 이하 → Simple Factory
- 제품군이 3개 이상이고 자주 확장 → Abstract Factory

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// Singleton: 메모리 효율적, 전역 상태 위험
public class DatabaseConnection {
    private static DatabaseConnection instance;
    private Connection connection;
    
    public static DatabaseConnection getInstance() {
        if (instance == null) {
            synchronized (DatabaseConnection.class) {
                if (instance == null) {
                    instance = new DatabaseConnection();
                }
            }
        }
        return instance;
    }
    
    // 메모리: 1개 인스턴스만 유지
    // 동시성: synchronized로 인한 성능 저하
}

// Factory: 유연성 높음, 메모리 사용량 증가
public class ConnectionFactory {
    private Pool<Connection> connectionPool;
    
    public Connection getConnection() {
        return connectionPool.borrowObject();
    }
    
    // 메모리: N개 Connection 객체 유지
    // 동시성: Thread-safe pool 구현
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

동시 접속 1000명 시:

Singleton 방식:
- 메모리: 50MB (1개 Connection + 대기 큐)
- 평균 응답시간: 500ms (순차 처리)
- TPS: 2000

Connection Pool 방식:  
- 메모리: 200MB (20개 Connection pool)
- 평균 응답시간: 50ms (병렬 처리)  
- TPS: 20000

Trade-off: 메모리 4배 증가로 성능 10배 향상

1
2
3
4

가중 평균 계산:
Observer = (6×0.25 + 5×0.20 + 9×0.20 + 7×0.15 + 6×0.10 + 8×0.10) = 6.75
Strategy = (8×0.25 + 9×0.20 + 9×0.20 + 8×0.15 + 9×0.10 + 9×0.10) = 8.60
Command = (4×0.25 + 7×0.20 + 8×0.20 + 5×0.15 + 7×0.10 + 9×0.10) = 6.35

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// 초급 팀: 단순하고 직관적인 패턴 선호
public class SimpleFactory {
    public static Logger createLogger(String type) {
        switch (type) {
            case "file": return new FileLogger();
            case "console": return new ConsoleLogger();
            default: throw new IllegalArgumentException();
        }
    }
}

// 중급 팀: 적당한 복잡도의 패턴 활용 가능
public class LoggerBuilder {
    private String output;
    private String format;
    private LogLevel level;
    
    public LoggerBuilder output(String output) {
        this.output = output;
        return this;
    }
    
    public Logger build() {
        return new Logger(output, format, level);
    }
}

// 고급 팀: 복잡한 패턴도 효과적으로 활용
public class LoggerFactory {
    private Map<String, Supplier<Logger>> loggerSuppliers;
    
    public <T extends Logger> void registerLogger(
        String name, 
        Class<T> loggerClass,
        Function<Configuration, T> factory) {
        // 제네릭과 함수형 인터페이스를 활용한 고급 팩토리
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// 초보자가 보는 것: 20줄의 개별 코드
public class WeatherStation {
    private List<Display> displays = new ArrayList<>();
    
    public void addDisplay(Display display) {
        displays.add(display);
    }
    
    public void removeDisplay(Display display) {
        displays.remove(display);
    }
    
    public void notifyDisplays() {
        for (Display display : displays) {
            display.update(temperature, humidity, pressure);
        }
    }
    
    public void measurementsChanged() {
        notifyDisplays();
    }
}

// 전문가가 보는 것: "Observer 패턴"
// → 즉시 다음 사항들을 추론:
//   - Subject-Observer 관계
//   - Push vs Pull 모델 (Push 사용)
//   - 느슨한 결합
//   - 확장 가능한 구조

1
2
3
4
5
6
7

Observer 패턴 스키마:
┌─ 구조적 스키마 ─┐    ┌─ 행동적 스키마 ─┐    ┌─ 적용 스키마 ─┐
│ Subject         │    │ attach()       │    │ 상태 변경     │
│ Observer        │    │ detach()       │    │ 통지 필요     │
│ ConcreteSubject │    │ notify()       │    │ 일대다 관계   │
│ ConcreteObserver│    │ update()       │    │ 느슨한 결합   │
└─────────────────┘    └─────────────────┘    └─────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// 전통적 Observer (Java 스타일)
class Subject {
    constructor() {
        this.observers = [];
    }
    
    attach(observer) {
        this.observers.push(observer);
    }
    
    notify(data) {
        this.observers.forEach(observer => observer.update(data));
    }
}

// JavaScript 관용적 Observer (EventEmitter)
const EventEmitter = require('events');

class WeatherStation extends EventEmitter {
    updateWeather(data) {
        this.emit('weatherChanged', data);
    }
}

const station = new WeatherStation();
station.on('weatherChanged', data => console.log(data));

// 현대적 Reactive Observer (RxJS)
import { Subject } from 'rxjs';

const weatherSubject = new Subject();
const subscription = weatherSubject.subscribe({
    next: data => console.log(data),
    error: err => console.error(err),
    complete: () => console.log('Complete')
});

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// 1세대: Singleton (1990년대)
public class DatabaseConnection {
    private static DatabaseConnection instance;
    // 전역 상태, 테스트 어려움
}

// 2세대: Service Locator (2000년대)  
public class ServiceLocator {
    private static Map<Class<?>, Object> services = new HashMap<>();
    
    public static <T> T getService(Class<T> serviceClass) {
        return (T) services.get(serviceClass);
    }
    // 중앙집중식 관리, 여전히 전역 상태
}

// 3세대: Dependency Injection (2010년대~)
@Component
public class OrderService {
    private final PaymentService paymentService;
    
    @Autowired
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
    // 명시적 의존성, 테스트 용이
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

// Strategy 패턴: 출력 전략
public interface LogAppender {
    void append(LogEvent event);
}

public class ConsoleAppender implements LogAppender {
    public void append(LogEvent event) {
        System.out.println(event.getMessage());
    }
}

public class AsyncAppender implements LogAppender {
    private final LogAppender delegate;
    private final BlockingQueue<LogEvent> queue = new LinkedBlockingQueue<>();
    
    public AsyncAppender(LogAppender delegate) {
        this.delegate = delegate;
        startBackgroundThread();
    }
    
    public void append(LogEvent event) {
        queue.offer(event);  // 비동기 처리
    }
}

// Chain of Responsibility: 필터 체인
public abstract class LogFilter {
    protected LogFilter next;
    
    public void setNext(LogFilter next) {
        this.next = next;
    }
    
    public final void filter(LogEvent event) {
        if (shouldProcess(event)) {
            process(event);
            if (next != null) {
                next.filter(event);
            }
        }
    }
    
    protected abstract boolean shouldProcess(LogEvent event);
    protected abstract void process(LogEvent event);
}

// Builder 패턴: 로거 구성
public class LoggerBuilder {
    private List<LogAppender> appenders = new ArrayList<>();
    private LogLevel level = LogLevel.INFO;
    private LogFormatter formatter = new SimpleFormatter();
    
    public LoggerBuilder addAppender(LogAppender appender) {
        this.appenders.add(appender);
        return this;
    }
    
    public LoggerBuilder level(LogLevel level) {
        this.level = level;
        return this;
    }
    
    public Logger build() {
        return new Logger(appenders, level, formatter);
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Strategy (LogAppender):
- 출력 방식이 다양함
- 런타임 교체 필요 없음 (설정 시점에 결정)
- 각 전략이 독립적

Chain of Responsibility (LogFilter):  
- 여러 필터를 조합해야 함
- 필터 순서가 중요함
- 동적으로 필터 체인 구성 가능

Builder (LoggerBuilder):
- 설정 옵션이 많음
- 선택적 매개변수 지원
- 불변 객체 생성