design-pattern-advisor

name	design-pattern-advisor
description	코드 작성/수정, 리팩토링, TODO 작성 시 자동 활성화. 복잡도 증가, 조건문 남발, 중복 코드 발견 시 적절한 디자인 패턴 제안. OO 설계 원칙(개방-폐쇄, 단일책임, 의존성역전) 위반 감지하고 Strategy, Observer, Decorator, Factory 등으로 리팩토링 방향 제시. 긴 if-else, switch문, 상속 남용, 새 기능 추가 시 기존 코드 수정 필요 등 code smell 발견 시 사용.
version	1.0.0

디자인 패턴 판단 및 적용 가이드

코드를 작성하거나 리팩토링할 때 적절한 디자인 패턴을 선택하고, OO 설계 원칙에 따라 판단하도록 돕습니다.

1. 핵심 OO 설계 원칙

1-1. 캡슐화 (Encapsulation)

"Identify the aspects that vary and separate them from what stays the same."

• 위반 징후: 하나의 요구사항 변경이 여러 클래스 수정을 유발

1-2. 인터페이스 프로그래밍

"Program to an interface, not an implementation."

• 위반 징후: new ConcreteClass() 직접 호출이 많음

1-3. 구성 우선 (Composition over Inheritance)

"Favor composition over inheritance."

• 위반 징후: 깊은 상속 계층, 여러 클래스에 같은 코드 복사

1-4. 느슨한 결합 (Loose Coupling)

"Strive for loosely coupled designs between objects that interact."

• 위반 징후: 한 클래스 변경이 연쇄적으로 다른 클래스 수정 요구

1-5. 개방-폐쇄 원칙 (Open-Closed Principle)

"Classes should be open for extension, but closed for modification."

• 위반 징후: 새 기능 추가 시마다 기존 클래스 수정 필요

1-6. 의존성 역전 원칙 (Dependency Inversion)

"Depend upon abstractions. Do not depend upon concrete classes."

• 위반 징후: 구체 클래스에 직접 의존하는 코드가 많음

1-7. 단일 책임 원칙 (Single Responsibility)

"A class should have only one reason to change."

• 위반 징후: 클래스가 여러 이유로 변경될 수 있음

1-8. 최소 지식 원칙 (Principle of Least Knowledge)

"Talk only to your immediate friends."

• 위반 징후: 메서드 체이닝이 많음 (a.getB().getC().doSomething())

2. 패턴 선택 Decision Tree

1. 알고리즘/동작을 런타임에 선택/변경해야 하는가?
   ├─ YES → Strategy Pattern 검토
   └─ NO ↓

2. 한 객체의 상태 변화를 여러 객체에 알려야 하는가?
   ├─ YES → Observer Pattern 검토
   └─ NO ↓

3. 기존 객체에 동적으로 기능을 추가해야 하는가?
   ├─ YES → Decorator Pattern 검토
   └─ NO ↓

4. 객체 생성 과정을 캡슐화해야 하는가?
   ├─ YES → Factory Pattern 검토
   └─ NO ↓

5. 단 하나의 인스턴스만 필요한가?
   ├─ YES → Singleton Pattern 검토
   └─ NO ↓

6. 요청을 객체로 캡슐화해야 하는가?
   ├─ YES → Command Pattern 검토
   └─ NO ↓

7. 호환되지 않는 인터페이스를 변환해야 하는가?
   ├─ YES → Adapter Pattern 검토
   └─ NO ↓

8. 복잡한 시스템을 단순한 인터페이스로 제공해야 하는가?
   ├─ YES → Facade Pattern 검토
   └─ NO ↓

9. 알고리즘의 뼈대는 유지하고 세부 단계만 변경하는가?
   ├─ YES → Template Method Pattern 검토
   └─ NO ↓

10. 객체의 상태에 따라 동작이 달라지는가?
    ├─ YES → State Pattern 검토
    └─ NO ↓

11. 객체에 대한 접근을 제어해야 하는가?
    └─ YES → Proxy Pattern 검토

3. 패턴 레퍼런스

패턴 정의, 구조 다이어그램, Before/After 예시는 REFERENCE.md 참조. Decision Tree로 후보를 좁힌 뒤 해당 패턴 섹션만 읽으면 컨텍스트를 최소로 유지할 수 있습니다.