feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,20 +1,33 @@
|
||||
---
|
||||
category: Unified
|
||||
id: wiki-2026-0508-객체-지향-프로그래밍-oop
|
||||
title: 객체 지향 프로그래밍(OOP)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
title: [[객체 지향 프로그래밍 (OOP)|객체 지향 프로그래밍 (OOP]]
|
||||
last_updated: 2026-05-02
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[객체 지향 프로그래밍 (OOP)|객체 지향 프로그래밍 (OOP]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 객체 지향 프로그래밍(OOP)은 데이터와 그 데이터를 다루는 동작([[Behavior|Behavior]])을 객체(object)라는 단위 안에 캡슐화하여 소프트웨어의 복잡성을 관리하는 프로그래밍 패러다임입니다 [1, 2]. 클래스와 상속 구조를 통해 코드 중복을 방지하고 재사용성을 높일 수 있습니다 [3]. 주로 단일 책임 원칙(SRP)을 포함한 SOLID 설계 원칙과 함께 적용되어 유지보수가 용이하고 유연한 소프트웨어 아키텍처를 구축하는 데 핵심적인 역할을 합니다 [1, 4].
|
||||
|
||||
---
|
||||
|
||||
> 객체 지향 프로그래밍(OOP)은 데이터와 그 동작([[Behavior|Behavior]])을 하나의 '객체(Object)' 내에 캡슐화하여 코드를 구성하는 프로그래밍 패러다임입니다 [1, 2]. 이 방식은 각 객체가 특정 기능이나 관심사에 대한 책임을 지도록 설계함으로써 관심사의 분리([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])를 자연스럽게 이끌어냅니다 [1, 2]. 주로 기능 단위의 수직적 분리를 통해 객체 간의 책임을 나누며, 소프트웨어 설계를 더욱 이해하기 쉽고 유연하며 유지보수하기 좋게 만듭니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **캡슐화와 관심사의 분리 (Encapsulation & SoC):** 1980년대에 본격적으로 부상한 OOP 패러다임은 데이터와 행동을 객체 내에 캡슐화하는 아이디어를 도입했습니다 [1]. 각 객체에 특정한 기능이나 관심사에 대한 책임을 부여함으로써, 시스템 구조 내에서 자연스럽게 '관심사의 분리([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])'를 이끌어냈습니다 [2].
|
||||
- **클래스 상속(Inheritance)과 코드 재사용:** OOP에서는 여러 클래스가 공통으로 공유하는 속성이나 동작을 하나의 기본 클래스(base class)에 배치할 수 있습니다 [3]. 다른 클래스들은 이 기본 클래스를 상속받아 기능을 이어받으므로, 코드를 중복해서 다시 정의할 필요 없이 DRY(Don't Repeat Yourself) 원칙을 효과적으로 달성할 수 있습니다 [3].
|
||||
- **SOLID 설계 원칙 기반:** 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수 가능하게 만들기 위해 고안된 5가지 기본 원칙인 SOLID 원칙의 토대가 됩니다 [4]. 특히 객체와 클래스가 단 하나의 책임만 가져야 한다는 단일 책임 원칙(SRP)은 OOP의 핵심 철학을 뒷받침합니다 [1, 5].
|
||||
@@ -27,7 +40,7 @@ last_updated: 2026-05-02
|
||||
- **SOLID 설계 원칙의 근간:** OOP는 시스템을 더 쉽게 관리하고 확장하기 위해 창안된 5가지 설계 원칙인 SOLID(단일 책임, 개방/폐쇄, 리스코프 치환, 인터페이스 분리, 의존성 역전)의 토대가 됩니다 [3]. 예를 들어 단일 책임 원칙(SRP)은 클래스가 오직 하나의 책임을 갖도록 설계하는 것을 강조하며 [1], 의존성 역전 원칙(DIP)은 추상화가 세부 사항에 의존하는 것이 아니라 세부 사항이 추상화에 의존해야 함을 명시하여 시스템의 결합도를 낮춥니다 [7].
|
||||
- **AOP(관점 지향 프로그래밍)와의 관계:** OOP는 책임을 객체별로 분리하여 클래스를 설계하는 수직적 접근법을 따르지만, 이 방식만으로는 시스템 전체에 퍼져 있는 로깅이나 보안 같은 횡단 관심사(Cross-Cutting Concerns)를 깔끔하게 분리하는 데 한계가 있습니다 [4, 5]. 따라서 이러한 공통 기능을 수평적으로 분리하여 모듈화하는 AOP 방식을 더하여 OOP 코드의 단순화와 역할 분리를 상호 보완적으로 수행합니다 [4, 5].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -36,7 +49,7 @@ last_updated: 2026-05-02
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[관심사의 분리 (SoC)|관심사의 분리 (SoC]], SOLID 원칙, [[관점 지향 프로그래밍 (AOP)|관점 지향 프로그래밍 (AOP]]
|
||||
- **Projects/Contexts:** [[소프트웨어 시스템 설계 및 아키텍처 구축|소프트웨어 시스템 설계 및 아키텍처 구축]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 OOP는 객체 간 책임을 분리하고 기능 단위의 수직적 분리를 달성하는 데 탁월하지만, 시스템 전반에 걸친 공통 기능(횡단 관심사)을 분리하는 데는 단점이 존재하며 이는 AOP 방식을 통해 반대/보완적으로 해결될 수 있다고 설명합니다 [6, 7].
|
||||
@@ -56,3 +69,52 @@ last_updated: 2026-05-02
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user