[변수미] 챕터 7: 자바스크립트 디자인 패턴 (2/3)

챕터_7/변수미.md

@@ -2,7 +2,8 @@
 
 ## 7.2 생성자 패턴
 
-자바스크립트의 클래스는 객체 템플릿을 정희하고 캡슐화, 상속을 구현할 수 있도록 하였다.
+자바스크립트의 클래스는 객체 템플릿을 정의하고 캡슐화, 상속을 구현할 수 있도록 하였다.
+
 
 클래스는 아래와 같은 특징을 가지고있습니다.
 
@@ -57,7 +58,8 @@ import : 모듈에서 내보낸 바인딩을 가져올 수 있도록 함
 
 ### 7.3.4 WeakMap을 이용한 최신 모듈 패턴
 
-WeakMap은 기본적으로키가 약하게 유지되는 맵이다.
+WeakMap은 기본적으로 키가 약하게 유지되는 맵이다.
+
 <- 참조되지 않은 키는 가비지컬렉션의 대상이 된다.
 
 ## 7.4 노출 모듈 패턴
@@ -95,7 +97,9 @@ WeakMap은 기본적으로키가 약하게 유지되는 맵이다.
 
 - 프로토타입 상속은 클래스처럼 따로 정의되는 것이 아니라, 이미 존재하는 다른 객체를 복제하여 새로운 객체를 만들어낸다.
 - 다른 언어의 기능을 따라하지 않고, 자바스크립트만이 가진 고유의 방식으로 작업 가능
-- 객체 내에 함수를 정의할 때 복사본이 아닌 참조로 생성되어, ㅁ모든 자식 객체가 동일한 함수를 가리킨다 <- 성능 이점
+
+- 객체 내에 함수를 정의할 때 복사본이 아닌 참조로 생성되어, 모든 자식 객체가 동일한 함수를 가리킨다 <- 성능 이점
+
 
 ## 7.7 팩토리 패턴
 
@@ -114,3 +118,97 @@ WeakMap은 기본적으로키가 약하게 유지되는 맵이다.
 
 같은 목표를 가진 각각의 팩토리들을 하나의 그룹으로 캡슐화 하는 패턴
 객체가 어떻게 생성되는지에 대한 세부사항을 알 필요없이 객체를 사용할 수 있도록 함
+
+
+## 7.8 구조 패턴
+
+구조패턴은 클래스와 객체의 구성을 다룬다.
+상속의 개념을 통해 인터페이스와 객체를 구성하여 새로운 기능을 추가할 수 있는 것처럼
+
+## 7.9 퍼사드 패턴
+
+> 심층적인 복잡성을 숨기고 사용하기 편리한 높은 수준의 인터페이스를 제공하는 패턴
+
+주로 jQuery와 같은 라이브러리에서 흔히 볼 수 있는 패턴이다.
+
+- 광범위한 기능 구현을 가지고 있으면서도
+- 퍼사드 특징(실제 모습을 숨기고 꾸며낸 겉모습 만을 드러냄)을 가지거나, 제한된 추상화 메서드 만이 공개되어 사용 가능
+
+클래스의 인터페이스를 단순화 하고 코드의 구현 부분과 사용 부분을 분리합니다.
+-> 하위 시스템에 직접 접근하기 보다는 간접적으로 상호작용
+-> 사용자는 내부에서 무슨 일이 벌어나든, 구현 수준의 세부사항을 알지 않고도 사용할 수 있음
+
+## 7.10 믹스인 패턴
+
+(?)
+
+## 7.11 서브 클래싱
+
+> 부모 클래스를 확장하는 자식 클래스를 서브 클래스라고 한다.
+
+서브 클래싱이란 부모 클래스에서 속성을 상속받아 새로운 객체를 만드는 것
+
+- 오버라이드 된 부모 클래스의 메소드 호출 -> 메서드 체이닝
+- 오버라이드 된 부모 클래스의 생성자 호출 -> 생성자 체이닝
+
+여기서 나온 메서드 체이닝이 내가 아는 개념이랑 같은건가? 했는데,
+prototype등을 타고타고 메서드를 호출하는것도, 부모 클래스의 메소드를 호출하는것도 다 메서드 체이닝으로 부르는듯 합니다. -> https://www.geeksforgeeks.org/method-chaining-in-javascript/
+
+## 7.12 믹스인 패턴
+
+> 믹스인은 최소한의 복잡성으로 객체의 기능을 빌리거나 상속할 수 있게 해줍니다.
+> 다른 여러 클래스를 아울러 쉽게 공유할 수 있는 속성과 메서드를 가진 클래스입니다.
+
+장점 : 함수의 중복을 줄이고 재사용성을 높인다.
+단점: 복잡해짐.
+
+> 글의 저자는 문서화를 잘 해두면 괜찮을거다, 라고 이야기하였는데 웬만한 상황이 아니라면 믹스인 패턴은 안쓰는게 나을것 같다고 생각했습니다.
+
+## 7.13 데코레이터 패턴
+
+> 코드 재사용을 목표로 하는 구조패턴
+> 기존 클래스에 **동적으로 기능을 추가**하기 위해 사용, 하지만 기존 클래스에 필수적인 기능은 아니였던
+> 데코레이터 패턴은 객체의 생성을 신경쓰지 않는 대신 기능의 확장에 초점을 둡니다.
+
+책에서 써있듯 게임 예제가 잘 맞는다는 생각이 드네요.
+기존 클래스에서 필수 기능은 아니였지만, 다양한 캐릭터, 능력을 추가하기 위해 확장에 열려있어야한다는 점에서?
+
+## 7.14 의사클래스 데코레이터
+
+인터페이스 : 객체가 가져야할 메서드를 정의하는 방법. 단, 어떻게 구현해야하지는 명지하지 않음
+왜 인터페이스를 사용해야할까?
+: 인터페이스는 스스로 문서의 역할을 하고, 재사용성을 높이기 때문
+
+Interface 클래스를 만들어, 엄격한 기능 검사를 하는 패턴
+자바스크립트에 내장된 기능이 아니며 -> 인터페이스가 내장된 typescript를 사용하면 된다.
+
+### 7.14.2 추상 데코레이터
+
+추가 옵션, 데코레이터가 많아질 수록 기존 데코레이터 패턴은 모든 추가 옵션 조합에 대해 새로운 서브 클래스가 필요해집니다.
+
+```js
+const MacBook = new Interface('Macbook', ['addEngraving', 'add4GBRam',...])
+```
+
+나중에 더 많은 옵션을 추가할 수 있도록, 추상 데코레이터 클래스는 MacBook 인터페이스를 구현하기 위해 필요한 기본 메서드를 정의하며, 그 외 나머지 옵션은 서브 클래스가 됩니다.
+
+추상 데코레이터는 모든 가능한 조합의 클래스를 따로 정의하지 않고도, 필요한 만큼의 데코레이터만을 사용해 기본 클래스에 독립적으로 기능을 추가할 수 있도록 합니다.
+
+```
+class CaseDecorator extends MacBookDecorator {
+	contructor(macbook) {
+		super(macbook)
+	}
+	addCase() {
+		return `${this.macbook.addCase()}`
+	}
+}
+```
+
+## 7.15 데코레이터 장/단점
+
+단점
+
+- 네임스페이스에 작고 비슷한 객체를 추가하기 때문에 잘 관리하지 않으면 애플리케이션 구조를 복잡하게할 수 있다.
+- 패턴에 익숙하지 않다면, 패턴의 사용 목적을 파악하기 어렵다. <- 문서화나 패턴에 대한 이해도를 높여 해결 가능
+