Fix: Restore unified Topics folder and reorganize specialized category folders
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-DEV-SOLID
|
||||
title: "SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["SOLID", "SOLID 원칙", "객체 지향 설계 원칙", "객체 지향 5대 원칙", "로버트 마틴"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["SOLID", "OOP", "Design_Principles", "Clean_Code", "Refactoring"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
---
|
||||
|
||||
# [[SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)]]
|
||||
|
||||
## 1. 개요
|
||||
SOLID 원칙은 객체 지향 프로그래밍과 설계(OOAD)에서 소프트웨어를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴이 정리한 이 원칙들은 구성 요소 간의 결합도를 낮추고 응집도를 높임으로써, 시스템의 일부분을 변경하더라도 다른 부분에 미치는 영향을 최소화하는 견고한 아키텍처의 토대를 제공한다.
|
||||
|
||||
## 2. 5대 핵심 원칙
|
||||
- **S (SRP: Single Responsibility Principle)**: 클래스는 단 하나의 변경 이유(책임)만 가져야 한다. 하나의 클래스가 너무 많은 역할을 수행하지 않도록 분리.
|
||||
- **O (OCP: Open/Closed Principle)**: 소프트웨어 요소는 확장에 대해서는 열려 있어야 하지만 수정에 대해서는 닫혀 있어야 한다. 기존 코드를 고치지 않고 기능을 추가할 수 있도록 설계(추상화 활용).
|
||||
- **L (LSP: Liskov Substitution Principle)**: 서브타입은 언제나 자신의 기반 타입(Base Type)으로 교체할 수 있어야 한다. 상속 구조에서 자식 클래스가 부모 클래스의 계약을 위반하지 않도록 보장.
|
||||
- **I (ISP: Interface Segregation Principle)**: 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강제되어서는 안 된다. 범용 인터페이스 하나보다 구체적인 인터페이스 여러 개로 분리.
|
||||
- **D (DIP: Dependency Inversion Principle)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다. 의존성 주입(DI)을 통해 구현 기술로부터 비즈니스 로직을 보호.
|
||||
|
||||
## 3. 엔지니어링 가치
|
||||
- **변경에 유연한 구조**: 비즈니스 요구사항이 변할 때 코드의 대대적인 수정 없이도 안전하게 기능을 확장하거나 변경 가능.
|
||||
- **테스트 가능성 향상**: 결합도가 낮고 인터페이스 기반으로 설계되어 있어, 개별 모듈을 독립적으로 테스트하거나 모의 객체(Mock)로 대체하기 용이함.
|
||||
- **코드 가독성 및 재사용성**: 각 클래스의 역할이 명확하고(SRP) 모듈 간의 연결이 추상화되어 있어(DIP), 코드를 처음 접하는 개발자도 구조를 빠르게 이해하고 필요한 부분을 재사용 가능.
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **초기 설계 오버헤드**: 원칙을 지키기 위해 더 많은 인터페이스와 클래스를 정의해야 하므로, 초기 개발 속도가 다소 느려질 수 있음.
|
||||
- **과도한 추상화의 함정**: 모든 곳에 SOLID를 강박적으로 적용하면 코드가 파편화되어 오히려 전체적인 흐름을 파악하기 어려워질 수 있음(인지 부하 증가).
|
||||
- **점진적 적용의 미학**: 레거시 시스템을 단번에 SOLID로 바꾸려 하기보다, 새로운 기능을 추가하거나 버그를 수정할 때 해당 영역부터 점진적으로 개선하는 것이 현실적임.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Design_Patterns]]: SOLID 원칙을 실현하기 위한 구체적인 구현 템플릿들.
|
||||
- [[Clean_Architecture]]: SOLID 원칙이 시스템 전반의 레이어 분리에 적용된 사례.
|
||||
- [[Dependency_Inversion_Principle]]: SOLID 원칙 중 아키텍처적으로 가장 영향력이 큰 원칙.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 객체 지향 시스템의 건전성을 평가하고 지속 가능한 코드베이스를 유지하기 위한 글로벌 설계 표준 정립.
|
||||
Reference in New Issue
Block a user