Initial commit

2025-11-30 09:05:40 +08:00
commit f525cc10dc
51 changed files with 11777 additions and 0 deletions
--- a/commands/design-patterns.md
+++ b/commands/design-patterns.md
@@ -0,0 +1,186 @@
+## 디자인 패턴
+
+코드베이스에 적용 가능한 디자인 패턴을 제안하고 SOLID 원칙의 준수 여부을 평가합니다.
+
+### 사용법
+
+```bash
+/design-patterns [분석대상] [옵션]
+```
+
+### 옵션
+
+- `--suggest` : 적용 가능한 패턴 제안 (기본값)
+- `--analyze` : 기존 패턴의 사용 현황 분석
+- `--refactor` : 리팩터링 안 생성
+- `--solid` : SOLID 원칙 준수 여부 체크
+- `--anti-patterns` : 안티패턴 검출
+
+### 기본 사용 예시
+
+```bash
+# 프로젝트 전체의 패턴 분석
+/design-patterns
+
+# 특정 파일에 대한 패턴 제안
+/design-patterns src/services/user.js --suggest
+
+# SOLID 원칙 체크
+/design-patterns --solid
+
+# 안티패턴 검출
+/design-patterns --anti-patterns
+```
+
+### 분석 카테고리
+
+#### 1. 생성 관련 패턴
+
+- **Factory Pattern**: 객체 생성의 추상화
+- **Builder Pattern**: 복잡한 객체의 단계적 구축
+- **Singleton Pattern**: 인스턴스의 유일성 보장
+- **Prototype Pattern**: 객체의 클론 생성
+
+#### 2. 구조 관련 패턴
+
+- **Adapter Pattern**: 인터페이스의 변환
+- **Decorator Pattern**: 기능의 동적 추가
+- **Facade Pattern**: 복잡한 서브시스템의 단순화
+- **Proxy Pattern**: 객체에 대한 접근 제어
+
+#### 3. 행동 관련 패턴
+
+- **Observer Pattern**: 이벤트 통지 구현
+- **Strategy Pattern**: 알고리즘의 전환
+- **Command Pattern**: 조작의 캡슐화
+- **Iterator Pattern**: 컬렉션의 순회
+
+### SOLID 원칙 체크 항목
+
+```text
+S - Single Responsibility Principle (단일 책임 원칙)
+O - Open/Closed Principle (개방 폐쇄 원칙)
+L - Liskov Substitution Principle (리스코프 치환 원칙)
+I - Interface Segregation Principle (인터페이스 분리 원칙)
+D - Dependency Inversion Principle (의존성 역전 원칙)
+```
+
+### 출력 예시
+
+```text
+디자인 패턴 분석 리포트
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+현재 사용 중인 패턴
+├─ Observer Pattern: EventEmitter (12 곳)
+├─ Factory Pattern: UserFactory (3 곳)
+├─ Singleton Pattern: DatabaseConnection (1 곳)
+└─ Strategy Pattern: PaymentProcessor (5 곳)
+
+권장 패턴
+├─ [HIGH] Repository Pattern
+│  └─ 대상: src/models/*.js
+│  └─ 이유: 데이터 접근 로직의 분리
+│  └─ 예시:
+│      class UserRepository {
+│        async findById(id) { ... }
+│        async save(user) { ... }
+│      }
+│
+├─ [MED] Command Pattern
+│  └─ 대상: src/api/handlers/*.js
+│  └─ 이유: 요청 처리의 통일화
+│
+└─ [LOW] Decorator Pattern
+   └─ 대상: src/middleware/*.js
+   └─ 이유: 기능 조합 개선
+
+SOLID 원칙 위반
+├─ [S] UserService: 인증과 권한 관리 모두 담당
+├─ [O] PaymentGateway: 새 결제수단 추가 시 수정 필요
+├─ [D] EmailService: 구상 클래스에 직접 의존
+└─ [I] IDataStore: 사용되지 않는 메서드 포함
+
+리팩터링 제안
+1. UserService 를 인증과 권한 관리로 분할
+2. PaymentStrategy 인터페이스 도입
+3. EmailService 인터페이스 정의
+4. IDataStore 를 용도별로 분리
+```
+
+### 고급 사용 예시
+
+```bash
+# 패턴 적용의 영향 분석
+/design-patterns --impact-analysis Repository
+
+# 특정 패턴의 구현 예시 생성
+/design-patterns --generate Factory --for src/models/Product.js
+
+# 패턴의 조합 제안
+/design-patterns --combine --context "API with caching"
+
+# 아키텍처 패턴의 평가
+/design-patterns --architecture MVC
+```
+
+### 패턴 적용 예시
+
+#### Before (문제가 있는 코드)
+
+```javascript
+class OrderService {
+  processOrder(order, paymentType) {
+    if (paymentType === "credit") {
+      // 신용카드 처리
+    } else if (paymentType === "paypal") {
+      // PayPal 처리
+    }
+    // 기타 결제 방법...
+  }
+}
+```
+
+#### After (Strategy Pattern 적용)
+
+```javascript
+// 전략 인터페이스
+class PaymentStrategy {
+  process(amount) {
+    throw new Error("Must implement process method");
+  }
+}
+
+// 구상 전략
+class CreditCardPayment extends PaymentStrategy {
+  process(amount) {
+    /* 구현 */
+  }
+}
+
+// 컨텍스트
+class OrderService {
+  constructor(paymentStrategy) {
+    this.paymentStrategy = paymentStrategy;
+  }
+
+  processOrder(order) {
+    this.paymentStrategy.process(order.total);
+  }
+}
+```
+
+### 안티패턴 검출
+
+- **God Object**: 과도하게 많은 책무를 가진 클래스
+- **Spaghetti Code**: 제어 흐름이 복잡하게 얽힌 코드
+- **Copy-Paste Programming**: 중복 코드의 과도한 사용
+- **Magic Numbers**: 하드코딩된 상수
+- **Callback Hell**: 깊게 중첩된 콜백
+
+### 베스트 프랙티스
+
+1. **점진적 적용**: 한 번에 많은 패턴을 적용하지 않기
+2. **필요성 검증**: 패턴은 문제 해결의 수단이지 목적이 아님
+3. **팀 합의**: 패턴 적용 전에 팀에서 논의
+4. **문서화**: 적용한 패턴의 의도를 기록