Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

5.2 KiB

Raw Blame History

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

title

Switch Statements (Switch 문)

📌 한 줄 통찰 (The Karpathy Summary)

Switch 문은 객체지향 프로그래밍에서 상속이나 다형성(Polymorphism)의 이점을 제대로 살리지 못하고 절차지향적으로 코드가 구현되었음을 나타내는 대표적인 '코드 스멜(OO Abusers)' 중 하나입니다 [1-3]. 이러한 조건문은 프로그램 여러 곳에 흩어져 코드 중복을 유발하며, 새로운 조건이 추가될 때마다 관련된 모든 Switch 문을 찾아 수정해야 하는 구조적 결함을 낳습니다 [2]. 일반적으로 '조건식을 다형성으로 바꾸기(Replace Conditional with Polymorphism)'와 같은 리팩토링 기법을 통해 이 문제를 해결하고 시스템의 유지보수성을 향상시킬 수 있습니다 [4, 5].

📖 구조화된 지식 (Synthesized Content)

객체지향 설계의 결함 지표: 객체지향 코드의 가장 뚜렷한 특징 중 하나는 Switch(또는 case) 문이 상대적으로 적다는 것입니다 [2]. Switch 문이 반복적으로 등장하는 것은 객체지향 구성 요소를 남용했거나(OO Abusers) 잘못 사용했다는 신호로 간주됩니다 [1, 3]. Switch 문의 근본적인 문제는 중복을 발생시킨다는 점이며, 새로운 분기 조건이 생길 때마다 흩어진 코드를 모두 수정해야 하므로 변경을 방해합니다 [2].
다형성을 활용한 리팩토링: Switch 문을 마주치면 가장 먼저 다형성의 적용을 고려해야 합니다 [4].
- Switch 문이 종종 타입 코드(Type Code)를 기반으로 작동하는 경우, 우선 '함수 추출하기(Extract Method)'와 '함수 옮기기(Move Method)'를 사용해 해당 Switch 문을 다형성이 필요한 클래스로 이동시킵니다 [4].
- 그 다음 '타입 코드를 서브클래스로 바꾸기(Replace Type Code with Subclasses)'나 '타입 코드를 상태/전략 패턴으로 바꾸기(Replace Type Code with State/Strategy)'를 통해 상속 구조를 구축합니다 [4].
- 마지막으로 '조건식을 다형성으로 바꾸기(Replace Conditional with Polymorphism)'를 적용하여 분기 로직을 동적 바인딩으로 대체합니다 [4, 5]. 이를 통해 새로운 타입이 추가될 때 기존 코드를 수정할 필요가 없게 되어 개방-폐쇄 원칙(Open-Closed Principle)을 준수할 수 있습니다 [5, 6].
다형성 외의 대안 기법: 조건이 Null인 경우를 처리하는 분기가 있다면 '널 객체 도입하기(Introduce Null Object)' 기법을 활용하여 Switch 문의 복잡성을 덜어낼 수 있습니다 [7].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

다형성 적용의 오버엔지니어링(Overkill) 위험: Switch 문을 제거하기 위해 무조건 다형성을 도입하는 것은 주의해야 합니다. 단일 메서드에만 영향을 미치는 소수의 조건 케이스만 존재하고 향후 이 조건들이 변경될 것으로 예상되지 않는 경우, 다형성을 도입하는 것은 오히려 불필요한 복잡성을 가중시키는 오버엔지니어링(Overkill)이 될 수 있습니다 [7].
이러한 제약 상황에서는 다형성 대신 '매개변수를 명시적 메서드로 바꾸기(Replace Parameter with Explicit Methods)'와 같이 더 단순한 리팩토링 방식을 선택하는 것이 타당합니다 [7].

Last updated: 2026-05-03

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: (TODO: 최소 2개)
Opposite / Trade-off: (TODO)
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.2 KiB Raw Blame History