wasabeef 디자인 패턴 제안 및 SOLID 원칙 평가
코드베이스에 적용 가능한 디자인 패턴을 제안하고 SOLID 원칙의 준수 여부을 평가합니다.
사용법
/design-patterns [분석대상] [옵션]
옵션
--suggest: 적용 가능한 패턴 제안 (기본값)--analyze: 기존 패턴의 사용 현황 분석--refactor: 리팩터링 안 생성--solid: SOLID 원칙 준수 여부 체크--anti-patterns: 안티패턴 검출
기본 사용 예시
# 프로젝트 전체의 패턴 분석
/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 원칙 체크 항목
S - Single Responsibility Principle (단일 책임 원칙)
O - Open/Closed Principle (개방 폐쇄 원칙)
L - Liskov Substitution Principle (리스코프 치환 원칙)
I - Interface Segregation Principle (인터페이스 분리 원칙)
D - Dependency Inversion Principle (의존성 역전 원칙)
출력 예시
디자인 패턴 분석 리포트
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
현재 사용 중인 패턴
├─ 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 를 용도별로 분리
고급 사용 예시
# 패턴 적용의 영향 분석
/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 (문제가 있는 코드)
class OrderService {
processOrder(order, paymentType) {
if (paymentType === "credit") {
// 신용카드 처리
} else if (paymentType === "paypal") {
// PayPal 처리
}
// 기타 결제 방법...
}
}
After (Strategy Pattern 적용)
// 전략 인터페이스
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: 깊게 중첩된 콜백
베스트 프랙티스
- 점진적 적용: 한 번에 많은 패턴을 적용하지 않기
- 필요성 검증: 패턴은 문제 해결의 수단이지 목적이 아님
- 팀 합의: 패턴 적용 전에 팀에서 논의
- 문서화: 적용한 패턴의 의도를 기록