2nd/10_Wiki/Topic_Programming/Architecture/SOLID Principles.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-solid-principles	SOLID Principles	10_Wiki/Topics	verified	self	SOLID SOLID 원칙 OOD Principles	none	A	0.9	applied	oop design-principles clean-code		2026-05-10	pending	language framework typescript none

SOLID Principles

매 한 줄

"매 5개 OOD 원칙 — 매 변경에 견디는 클래스 설계의 기본기". Robert C. Martin이 2000년대 초 정리한 5원칙(SRP/OCP/LSP/ISP/DIP)은 매 객체지향 설계의 lingua franca. 2026년에도 매 TypeScript/Kotlin/Swift 코드 review의 매 첫 lens.

매 핵심

매 5원칙

• SRP — Single Responsibility: 매 클래스는 매 한 가지 변경 이유.
• OCP — Open/Closed: 매 확장에 열려, 수정에 닫혀.
• LSP — Liskov Substitution: 매 서브타입은 매 부모 대체 가능.
• ISP — Interface Segregation: 매 client는 매 unused method 의존 X.
• DIP — Dependency Inversion: 매 추상에 의존, 구체에 의존 X.

매 적용 원리

• 결합도 ↓: 매 DIP/ISP가 핵심.
• 응집도 ↑: 매 SRP가 driver.
• 다형성 안전성: 매 LSP/OCP.

매 응용

1. Hexagonal/Clean Architecture 의 layering 근거.
2. DI container (Spring, NestJS) 의 설계 정당성.
3. AI agent tool interface 분리 (ISP).

💻 패턴

SRP — 책임 분리

// X — 매 두 책임 (저장 + 알림)
class Order {
  save() { db.insert(this); }
  notify() { mailer.send(this.user, "ordered"); }
}

// O
class Order { /* domain only */ }
class OrderRepo { save(o: Order) { db.insert(o); } }
class OrderNotifier { notify(o: Order) { mailer.send(o.user, "ordered"); } }

OCP — 확장 가능 구조

interface Discount { apply(price: number): number; }
class SeasonalDiscount implements Discount { apply(p: number) { return p * 0.9; } }
class VipDiscount implements Discount { apply(p: number) { return p * 0.8; } }

class Checkout {
  constructor(private d: Discount) {}
  total(p: number) { return this.d.apply(p); }
}
// 새 할인 추가 = 새 구현만, Checkout 수정 X.

LSP — 안전한 대체

// X — Square가 Rectangle invariant 깨뜨림
class Rectangle { setW(w:number){} setH(h:number){} }
class Square extends Rectangle { setW(w:number){ super.setW(w); super.setH(w); } }

// O — 분리된 계층
interface Shape { area(): number; }
class Rectangle implements Shape { constructor(public w:number, public h:number){} area(){ return this.w*this.h; } }
class Square implements Shape { constructor(public s:number){} area(){ return this.s*this.s; } }

ISP — fat interface 분리

// X
interface Worker { code(): void; eat(): void; }

// O — robot은 eat 안함
interface Codeable { code(): void; }
interface Eatable { eat(): void; }
class Human implements Codeable, Eatable { code(){} eat(){} }
class Robot implements Codeable { code(){} }

DIP — 의존성 역전

// 매 high-level은 abstraction에 의존
interface Logger { log(msg: string): void; }
class ConsoleLogger implements Logger { log(m:string){ console.log(m); } }

class OrderService {
  constructor(private logger: Logger) {} // 매 추상 의존
  place() { this.logger.log("ordered"); }
}
new OrderService(new ConsoleLogger()).place();

React/Hook 적용 (SRP + DIP)

// 매 hook 분리 + DI
function useOrders(repo: OrderRepo = defaultRepo) {
  return useQuery(["orders"], () => repo.list());
}

NestJS DI (DIP 자연스러움)

@Injectable()
class OrderService {
  constructor(@Inject("OrderRepo") private repo: OrderRepo) {}
}

매 결정 기준

상황	Approach
매 작은 script	매 SOLID 강제 X. 매 over-engineering 위험.
매 production service	매 5원칙 routinely 적용.
매 plugin/extension architecture	OCP+DIP 우선.
매 legacy refactor	SRP부터. 매 클래스 분리.

기본값: 매 production code → 5원칙 review. 매 prototype → 무시 OK.

🔗 Graph

• 부모: Clean Code
• 응용: Hexagonal Architecture · Clean Architecture · Dependency Injection
• Adjacent: Single Responsibility Principle (SRP) · Open Closed Principle

🤖 LLM 활용

언제: 매 코드 review, 매 architecture 결정 정당화, 매 refactor 우선순위 산정. 언제 X: 매 throwaway script, 매 학습용 toy code.

❌ 안티패턴

• SOLID 광신: 매 모든 클래스를 5원칙 강제 → 매 over-abstraction.
• SRP 오해: 매 "한 메서드 = 한 클래스" 로 해석.
• DIP 표면적 적용: 매 interface만 만들고 매 구현 1개 → 매 abstraction noise.
• LSP 명목적 통과: 매 throw NotImplemented로 매 LSP 우회.

🧪 검증 / 중복

• Verified (R.C. Martin "Agile Software Development", Clean Architecture).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 5원칙 working code patterns 추가