정리

챕터_7/서준환.md

@@ -0,0 +1,147 @@
+# 챕터7 자바스크립트 디자인 패턴
+
+## 7.2.2 생성자의 기본 특징
+
+> 책에서 car 생성자로 객체를 생성할 때마다 toString()과 같은 함수를 다시 정의한다고 했는데, 궁금해서 아래 코드를 만들어 실행해 보았습니다.
+
+```js
+class User {
+  constructor(name) {
+    this.name = name;
+  }
+
+  toString() {
+    return `User(${this.name})`;
+  }
+}
+
+const user = new User("Lee");
+const user2 = new User("Kim");
+
+console.log(user.toString()); // User(Lee)
+console.log(user2.toString()); // User(Kim)
+
+console.log(user.toString === user2.toString); // true
+```
+
+> 위 코드에서 보듯이, 생성자 함수를 통해 객체를 생성할 때마다 toString() 함수가 다시 정의되는 것이 아니라, 한 번 정의된 함수를 재사용하던데 제가 잘못,,이해했을지도,,
+> [ref](https://stackoverflow.com/questions/1635116/javascript-class-method-vs-class-prototype-method)
+
+## 7.3.2 모듈 패턴
+
+> 흔히 사용하던 것이지만 의식하지 않아서 몰랐읍니다..
+
+### 비공개
+
+비공개 상태와 구성을 캡슐화하기 위해 `클로저`를 사용한다.
+
+```js
+const User = (function () {
+  let _name = "Lee";
+
+  function getName() {
+    return _name;
+  }
+})();
+
+console.log(User.getName()); // Lee
+console.log(User._name); // undefined
+```
+
+이렇게 사용하면 user에 할당하기에 전역스코프를 오염시키지 않을 뿐더러, 내부의 비공개 상태를 보호할 수 있다.
+
+더불어 ES2019부턴 접근 제한자 (#)를 사용할 수 있다.
+
+```js
+class User {
+  #name = "Lee";
+}
+
+console.log(user.#name); // SyntaxError: Private field '#name' must be declared in an enclosing class
+```
+
+> 2033년: 옛날에는 이렇게도 사용했단다~
+
+### 정리
+
+예제 코드의 모듈 패턴을 통해 해당 네임스페이스에서 내보내는 모듈은 `공개`되고, 내부에서 사용하는 변수는 `비공개`로 설정할 수 있다.
+
+단점으론 공개 여부를 바꾸기 위해 값이 위치한 파일로 가서 바꿔줘야한다.
+
+[ref](https://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html)
+
+### 7.3.4  WeakMap을 사용하는 최신 모듈 패턴
+
+은 다시 읽겠습니다.
+
+### 7.4 노출 모듈 패턴
+
+3번 읽어도 잘 이해되지 않는 패턴이네요,, 
+
+일반적인 모듈 패턴에서 public으로 노출할 요소를 바로 노출하는 것이 아닌 선언 후 포인터로 가르키기만 하는 느낌?,,
+
+### 7.5 싱글톤 패턴
+
+인스턴스가 오직 하나만 존재하도록 제한하는 패턴,,
+
+> 최근에 승준님께서 CJS, ESM으로 빌드한 산출물을 접근할 때 싱글턴이 깨질 수도 있다고 하셨었는데, 듣고보니 맞는 것 같더라구요.
+
+> 더불어 뭔가 코드가 private static 변수를 사용하는 것이 더 맞는 것 같기도?,, 하네요!
+
+```js
+class Singleton {
+  static #instance;
+  constructor(data) {
+    if (Singleton.#instance) {
+      return Singleton.#instance;
+    }
+    this.data = data;
+    Singleton.#instance = this;
+  }
+
+  getData() {
+    return this.data;
+  }
+}
+
+const singleton1 = new Singleton("data1");
+const singleton2 = new Singleton("data2");
+
+console.log(singleton1.getData()); // data1
+console.log(singleton2.getData()); // data1
+
+console.log(singleton1 === singleton2); // true
+```
+
+뭔가 꼭 기억해야할 것 같은 문장이 있었는데요, "자바스크립트에서 싱글톤이 필요하다는 것은 설계를 다시 생각해 봐야 한다는 신호일 수도 있습니다."
+
+#### 7.5.1 리액트의 상태 관리
+
+Context API나 리덕스와 같은 도구들은 컴포넌트가 전역 상태를 직접 변경할 수 없게 만들어 전역 상태가 가지는 단점을 조금이나마 보완하는 것 같습니다.
+
+### 7.6 프로토타입 패턴 (다시 읽기)
+
+프로토타입 패턴은 프로토타입의 상속을 기반으로 한다.
+
+> 옛날에 회사의 날짜 처리가 조금 괴상해서,, Date 관련 유틸 함수가 있었는데요, 이걸 Date.prototype에 넣어서 사용할까?,, 라는 생각도 해보았읍니다,, (결국 안 함)
+
+어 음 되게 어렵네요,,
+
+### 7.7 팩토리 패턴
+
+한 눈에 봤을 때 팩토리 패턴은 객체 생성할 때 간단 혹은 깔끔한 인터페이스를 제공하는 것 같습니다.
+
+#### 7.7.1 팩토리 패턴을 사용하면 좋은 상황
+
+- 객체를 생성하는 과정이 복잡할 때
+- 편리하게 생성할 수 있는 인터페이스가 필요할 때
+- 같은 속성을 공유하는 여러 객체를 생성할 때
+
+#### 7.7.2 팩토리 패턴을 사용하면 안 되는 상황
+
+그래서 실제로 굉장히 다양하고 복잡한 일들을 할 수도 있어서 실제 구현체를 보기위해 `go to reference` ->  `exit` 할 것 같습니다.
+
+#### 7.7.3 추상 팩토리 패턴 (다시 읽기)
+
+뭐랄까요?,, SDK 만들거나 라이브러리 만들 때 "멋있어"보일 것 같습니다.
+