Create 13. 패턴과-행복하게-살아가기-실전-디자인-패턴.md

doeun/13. 패턴과-행복하게-살아가기-실전-디자인-패턴.md

@@ -0,0 +1,67 @@
+## Chapter 13. 패턴과 행복하게 살아가기 (실전 디자인 패턴)
+
+> **"패턴(Pattern)은 특정 컨텍스트 내에서 주어진 문제의 해결책이다."**
+
+---
+
+### 1. 디자인 패턴의 본질적 정의 (3대 단어 풀이)
+
+디자인 패턴은 단순히 코드 조각이나 라이브러리가 아니라, **[컨텍스트 - 문제 - 해결책]**의 결합
+
+| 요소 | 정의 | 실전 예시 (반복자 패턴) |
+| :--- | :--- | :--- |
+| **컨텍스트 (Context)** | 패턴이 적용되는 상황 (반복적으로 일어날 수 있는 상황이어야 함) | "객체들의 컬렉션이 주어져 있다." |
+| **문제 (Problem)** | 컨텍스트 내에서 이뤄야 하는 목표와 제약조건 | "컬렉션의 내부 구현을 드러내지 않으면서, 그 안에 있는 각 객체를 대상으로 순환 작업을 할 수 있어야 한다." |
+| **해결책 (Solution)** | 제약조건 속에서 누가 적용해도 목표를 이룰 수 있는 일반적인 디자인 | "반복 작업을 별도의 클래스로 캡슐화한다." |
+
+#### ⚠️ 모든 해결책이 패턴이 될 수 없는 이유
+1. **반복성:** 반복적으로 등장하는 문제에 적용할 수 있어야 합니다. (예: 차 키를 놓고 내렸다고 매번 차 유리창을 깨는 행위는 패턴이 될 수 없음)
+2. **범용성:** 다른 사람이 처한 문제에도 일반적인 해결책으로 적용할 수 있어야 합니다.
+3. **명명성:** 해당 구조를 명확히 가리킬 수 있는 고유한 **이름**이 존재해야 합니다.
+
+---
+
+### 2. GoF(Gang of Four) 디자인 패턴 분류하기
+
+카탈로그에서는 디자인 패턴을 체계적으로 관리하기 위해 크게 두 가지 기준(**용도**와 **범위**)으로 분류합니다.
+
+#### ① 용도(Purpose)에 따른 분류
+
+| 범주 | 설명 | 주요 패턴 |
+| :--- | :--- | :--- |
+| **생성 (Creational)** | 객체 인스턴스 생성을 캡슐화하여, 클라이언트와 생성 대상 객체 간의 연결을 끊어줌 | 싱글턴, 추상 팩토리, 팩토리 메소드, 빌더, 프로토타입 |
+| **행동 (Behavioral)** | 클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 매커니즘을 다룸 | 템플릿 메소드, 반복자, 옵저버, 상태, 전략, 인터프리터, 중재자, 비지터 등 |
+| **구조 (Structural)** | 클래스와 객체를 조합하여 더 큰 구조를 만들 수 있게 구상을 활용함 | 프록시, 데코레이터, 컴포지트, 퍼사드, 어댑터, 브리지, 플라이웨이트 |
+
+> 💡 **토론 포인트 (데코레이터 패턴)**
+> 데코레이터 패턴은 객체에 동적으로 '행동을 추가'하는 목적을 갖기 때문에 행동 패턴으로 오해하기 쉬우나, 객체를 감싸서(Composition) 더 큰 구조를 형성하는 방식이므로 GoF 카탈로그에서는 **구조 패턴**으로 분류합니다.
+
+#### ② 범위(Scope)에 따른 분류
+
+* **클래스 패턴 (Class Pattern)**
+  * 클래스 사이의 관계가 주로 **상속(Inheritance)**으로 정의됩니다.
+  * 관계가 **컴파일 시점**에 결정되므로 고정적이고 정적입니다.
+  * *해당 패턴:* 템플릿 메소드, 팩토리 메소드, 어댑터(클래스 버전), 인터프리터
+* **객체 패턴 (Object Pattern)**
+  * 객체 사이의 관계가 주로 **구성(Composition/합성)**으로 정의됩니다.
+  * 관계가 실행 중(**런타임**)에 동적으로 결정되므로 보다 유연하고 안전합니다.
+  * *해당 패턴:* 전략, 옵저버, 상태, 데코레이터, 컴포지트, 커맨드, 반복자, 퍼사드, 프록시, 추상 팩토리, 싱글턴 등
+
+---
+
+### 3. 패턴으로 생각하기 (실전 도입 원칙)
+
+패턴을 안다는 것은 모든 곳에 패턴을 쑤셔 넣는 것이 아니라, **패턴 적용 여부를 결정할 수 있는 안목**을 갖추는 것을 의미합니다.
+
+1. **KISS (Keep It Simple, Stupid):** 최대한 단순한 방법으로 문제를 해결하려고 노력해야 합니다. 패턴은 목표가 아닌 해결책입니다.
+2. **영향 평가:** 패턴을 사용할 때, 그 패턴이 우리가 설계한 전체 디자인과 아키텍처에 미칠 영향과 결과(장단점)를 먼저 철저하게 계산해야 합니다.
+3. **확신을 가질 것:** 디자인상의 문제에 적합하다는 객체지향적 확신이 들 때만 패턴을 도입합니다.
+4. **예측과 대비:** 간단한 해결책으로 당장 문제가 해결되더라도, 시스템의 어떤 부분이 향후 빈번하게 변경될 것이라고 예측되는 상황이라면 디자인 패턴을 적용합니다.
+5. **과감한 리팩터링:** 꼭 필요하지 않은 패턴, 혹은 패턴보다 더 간단한 해결책이 나중에 발견된다면 과감하게 패턴을 제거해야 합니다.
+
+---
+
+### 4. 전문 용어(Shared Vocabulary)의 힘
+
+* 디자인 패턴의 이름은 개발자 간의 **공유 어휘**로 작동합니다.
+* 장황한 코드 설명 대신 "여기는 어댑터로 맞추고 데이터는 옵저버로 공유하자"라는 한마디로 설계 의도를 명확히 전달하여 의사소통 비용을 극적으로 낮춥니다.