docs: 13,14장 내용 정리

jina/13.패턴과_행복하게_살아가기 copy.md

@@ -0,0 +1,40 @@
+# 패턴과 행복하게 살아가기
+
+- 실전 디자인 패턴
+
+## 디자인 패턴의 정의
+
+**패턴**은 특정 컨텍스트 내에서 주어진 문제의 해결책
+
+**컨텍스트** : 패턴이 적용되는 상황. 반복적으로 일어날 수 있는 상황
+
+**문제** : 컨택스트 내에서 이뤄야 하는 목표. 컨텍스트 내의 제약조건
+
+**해결책** : 우리가 찾아내야 하는것. 제약조건 속에서 누가 적용해도 목표를 이룰 수 있는 일반적인 디자인
+
+> 어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받는 문제가 발생했다면, 그 제약조건 내에서 목적 달성을 위한 해결책이 되는 디자인을 적용하면 됨.
+
+## 디자인 패턴 분류하기
+
+**생성패턴**
+객체 인스턴스를 생성하는 패턴. 클라이언트와 그 클라이언트가 생성해야하는 객체 인스턴스 사이의 연결을 끊어주는 패턴
+
+- 빌더, 프로토타입, 싱글턴, 추상 팩토리, 팩토리 메소드
+
+**행동패턴**
+클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 방법을 다루는 패턴
+
+- 템플릿 메소드, 싱글턴, 반복자, 옵저버, 상태, 전략, 비지터, 중재자, 인터프리터, 역할 변경, 메멘토
+
+**구조패턴**
+클래스와 객체를 더 큰 구조로 만들 수 있게 구상을 사용하는 패턴
+
+- 데코레이트, 컴포지트, 프록시, 퍼사드, 어댑터, 플라이웨이트, 브리지
+
+## 안티패턴
+
+> 어떤 문제의 나쁜 해결책에 이르는 길을 알려줌
+
+- 어떤 이유로 나쁜 해결책에 유혹되는지 알려줌
+- 장기적인 관점에서 그 해결책이 나쁜 이유를 알려줌
+- 좋은 해결책을 만들때 적용할 수 있는 다른 패턴을 제안

jina/14.기타_패턴.md

@@ -0,0 +1,167 @@
+# 기타패턴
+
+## 브리지 패턴
+
+구현과 더불어 추상화 부분까지 변경해댜 한다면 브리지 패턴 사용
+
+**장점**
+
+- 구현과 인터페이스를 완전히 결합하지 않아서 구현과 추상화 부분 분리 가능
+- 추상과 부분과 구현부분 독립적으로 확장 가능
+- 추상화 부분을 구현한 구상 클래스가 바뀌어도 클라이언트에는 영향없음
+
+**활용법 및 단점**
+
+- 여러 플랫폼에서 사용해야하는 그래픽스와 윈도우 처리 시스템에서 유용
+- 인터페이스와 실제 구현부분을 서로 다른 방식으로 변경해야할때 유용
+- 디자인이 복잡해지는 단점
+
+---
+
+## 빌더 패턴
+
+제품을 여러 단계로 나눠서 만들도록 제품 생산 단계를 캡슐과 하고 싶다면 빌더 패턴 사용
+
+**장점**
+
+- 복합 객체 생성 과정을 캡슐화
+- 여러 단계와 다양한 절차를 걸쳐 객체 만들기 가능
+- 제품의 내부 구조를 클라이언트로부터 보호 가능
+- 클라이언트는 추상 인터페이스만 볼 수 있기에 구현코드 변경이 쉬움
+
+**활용법 및 단점**
+
+- 복합 객체 구조를 구축하는 용도로 많이 쓰임
+- 팩토리를 사용할 때보다 객체를 만들때 클라이언트에 관해 더 많이 알아야함
+
+---
+
+## 책임 연쇄 패턴
+
+1개의 요청을 2개이상의 객체에서 처리해야 한다면 책임 연쇄 패턴 사용
+책임 연쇄 패턴에서는 주어진 요청을 검토하는 객체 사슬 생성 후 그 사슬에 속해있는 객체는 자기가 받은 요청을 검사해서 직접 처리하거나 사슬에 들어있는 다른 객체에게 넘김.
+
+**장점**
+
+- 요청을 보낸 쪽과 받는 쪽을 분리가능
+- 객체는 사슬구조를 몰라도 되고 그 사슬에 들어있는 다른 객체의 직접적인 레퍼런스를 가질 필요도 없어서 객체를 단순하게 만들기 가능
+- 사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로 역할을 동적으로 추가하거나 제거 가능
+
+**활용법 및 단점**
+
+- 윈도우 시스템에서 마우스 클릭과 키보드 이벤트를 처리할 때 흔히 쓰임
+- 요청이 반드시 수행된다는 보장이 없다.
+- 실행시 과정을 살펴보거나 디버깅이 어려움
+
+---
+
+## 플라이웨이트 패턴
+
+어떤 클래스의 인스턴스 하나로 여러개의 '가상 인스턴스'를 제공하고 싶다면 플라이웨이트 패턴 사용
+
+**장점**
+
+- 실행시에 객체 인스턴스의 개수를 줄여 메모리 절약 가능
+- 여러 '가상' 객체를 한곳에 모아둘 수 있음
+
+**사용법 및 단점**
+
+- 어떤 클래스의 인스턴스가 아주 많이 필요하지만, 모두 같은 방식으로 제어해야할때 유용
+- 특정 인스턴스만 다른 인스턴스와 다르게 행동하게 할 수 없음
+
+---
+
+## 인터프리터 패턴
+
+어떤 언어의 인터프리터를 만들때 인터프리터 패턴 사용
+
+**장점**
+
+- 문법을 클래스로 표현해서 쉽게 언어 구현 가능
+- 문법이 클래스로 표현되므로 언어를 쉽게 변경하거나 확장 가능
+- 클래스 구조에 메소드만 추가하면 프로그램을 해석하는 기본 기능 외에 예쁘게 출력하는 기능이나 더 나은 프로그램 확인 기능 같은 새로운 기능 추가 가능
+
+**활용법 및 단점**
+
+- 간단한 언어를 구현할때 유용
+- 효율보다는 단순하고 간단하게 문법을 만드는것이 더 중요한 경우 유용
+- 스크립트 언어와 프로그래밍 언어에서 모두 사용 가능
+- 문법 규치그이 개수가 많아지면 복잡해짐.
+
+---
+
+## 중재자 패턴
+
+서로 관련된 객체 사이의 복잡한 통신과 제어를 한곳으로 집중하려면 중재자 패턴 사용
+
+> 상태가 바뀔때마다 중재자에게 알려줌
+> 중재자에서 보낸 요청에 응답
+
+**장점**
+
+- 시스템과 객체를 분리함으로써 재사용성을 향상시킬수 있음
+- 제어 로직을 한 군데 모아놨으므로 관리가 수월
+- 시스템에 들어있는 객체 사이에서 오가는 메시지를 줄이고 단순화 가능
+
+**활용법 및 단점**
+
+- 서로 연관된 GUI 구성 요소를 관리하는 용도로 많이 쓰임
+- 디자인을 잘 하지 못하면 중재자 객체가 너무 복잡해질 수 있음
+
+---
+
+## 메멘토 패턴
+
+객체를 이전 상태로 복구해야 한다면 메멘토 패턴 사용
+
+**메멘토 패턴의 목적**
+
+- 시스템에서 핵심적인 기능을 담당하는 객체의 상태 저장
+- 핵심적인 객체의 캡슐화 유지
+
+**장점**
+
+- 저장된 상태를 핵심 객체와는 다른 별도의 객체에 보관 가능
+- 핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지 가능
+- 복구 기능 구현하기 쉬움
+
+**활용법 및 단점**
+
+- 메멘토 객체를 써서 상태 저장
+- 상태를 저장하고 복구하는데 시간이 오래걸릴 수 있음
+
+---
+
+## 프로토타입 패턴
+
+어떤 클래스의 인스턴스를 만들때 자원과 시간이 많이 들거나 복잡하다면 프로토타입 패턴 사용
+프로토타입 패턴을 사용하면 기존 인스턴스를 복사하기만 해도 새로운 인스턴스를 만들수 있음
+
+**장점**
+
+- 클라이언트는 새로운 인스턴스를 만드는 과정을 몰라도됨
+- 클라이언트는 구체적인 형식을 몰라도 객체 생성가능
+- 상황에 따라서 객체를 새로 생성하는 것보다 객체를 복사하는것이 더 효율적
+
+**활용법 및 단점**
+
+- 시스템에서 복잡한 클래스 계층구조에 파묻혀있는 다양한 형식의 객체 인스턴스를 새로 만들어야 할 때 유용
+- 때때로 객체의 복사본을 만드는일이 매우 복잡할 수 있다는 단점
+
+---
+
+## 비지터 패턴
+
+다양한 객체에 새로운 기능을 추가해야하는데 캡슐화가 별로 중요하지 않다면 비지터 패턴 사용
+비지터 객체는 트래버서 객체와 함께 돌아다님. 트래버서는 컴포지트 패턴을 쓸때 복합객체 네에 속해있는 모든 객체에 접근하는 일을 도와주는 역할.
+
+**장점**
+
+- 구조를 변경하지 않으면서도 복합 객체 구조에 새로운 기능 추가 가능
+- 비교적 손쉽게 새로운 기능 추가 가능
+- 비지터가 수행하는 기능과 관련된 코드를 한곳에 모아둘 수 있음
+
+**단점**
+
+- 복합 클래스의 캡슐화가 깨짐
+- 컬렉션 내의 모든 항목에 접근하는 트래버서가 있으므로 복합 구조를 변경하기 더 어려워짐