|
| 1 | +## 들어가며 |
| 2 | + |
| 3 | +- 네임스페이스 : 코드 단위를 고유한 식별자로 그룹화한 것 |
| 4 | +- 하나의 식별자를 여러 네임스페이스에서 참조 가능 |
| 5 | +- 전역 네임스페이스 내에 존재하는 다른 객체나 변수와의 충돌을 방지 |
| 6 | +- 프로그램의 기능들을 체계적으로 구성 |
| 7 | +- JS는 다른 언어들처럼 네임스페이스를 기본적으로 지원하지는 않음 |
| 8 | +- 단, **객체와 클로저를 활용하여 비슷한 효과를 낼 수 있음** |
| 9 | + |
| 10 | +## 단일 전역 변수 패턴 |
| 11 | + |
| 12 | +> 하나의 전역 변수를 주요 참조 객체로 사용하는 방식 |
| 13 | +
|
| 14 | +```javascript |
| 15 | +const myUniqueApplication = (() => { |
| 16 | + function myMethod() { |
| 17 | + // 코드 |
| 18 | + return; |
| 19 | + } |
| 20 | + |
| 21 | + return { |
| 22 | + myMethod |
| 23 | + }; |
| 24 | +})(); |
| 25 | + |
| 26 | + |
| 27 | +myUniqueApplication.myMethod(); |
| 28 | +``` |
| 29 | + |
| 30 | +- 가장 큰 문제점은 **다른 개발자가 같은 이름의 전역 변수를 이미 사용하고 있을 가능성이 있음** |
| 31 | + |
| 32 | + |
| 33 | +## 접두사 네임스페이스 패턴 |
| 34 | + |
| 35 | +> 고유한 접두사를 선정한 다음, 모든 메서드, 변수, 객체를 이 접두사 뒤에 붙여 정의 |
| 36 | +
|
| 37 | +```javascript |
| 38 | +const myApplication_propertyA = {}; |
| 39 | +const myApplication_propertyB = {}; |
| 40 | +function myApplication_MyMethod() { |
| 41 | + // 코드 |
| 42 | + return; |
| 43 | +} |
| 44 | +``` |
| 45 | + |
| 46 | +- **단일 전역 변수 문제에 대한 해결책 중 하나** |
| 47 | +- 전역에서 특정 변수와 이름이 겹칠 가능성을 효과적으로 줄임 |
| 48 | +- 스스로 고유한 이름을 가진 객체도 같은 효과를 낼 수 있음 |
| 49 | +- 문제점1 : **애플리케이션이 커질수록 많은 전역 객체가 생성됨** |
| 50 | +- 문제점2 : **다른 개발자가 같은 접두사를 전역 네임스페이스에서 사용하지 않고 있었을 것이라고 가정** |
| 51 | + |
| 52 | + |
| 53 | +## 객체 리터럴 표기법 패턴 |
| 54 | + |
| 55 | +> 키와 값으로 이뤄진 집합 |
| 56 | +
|
| 57 | +```javascript |
| 58 | +myApplication.foo = () => "bar"; |
| 59 | + |
| 60 | +myApplication.utils = { |
| 61 | + toString() { |
| 62 | + // ... |
| 63 | + }, |
| 64 | + export() { |
| 65 | + // ... |
| 66 | + } |
| 67 | +} |
| 68 | +``` |
| 69 | + |
| 70 | +- 키 자체가 새로운 네임스페이스가 될 수 있음 |
| 71 | +- 전역 네임스페이스를 오염시키지 않으면서도 코드와 매개변수를 논리적으로 구성하는 데 도움 |
| 72 | +- 동일한 이름의 변수가 있는지 검사하도록 설계되는 경우가 많음 -> 충돌 가능성을 크게 줄여줌 |
| 73 | +- 장점1 : 키-값 구조이므로 알아보기 쉬움 |
| 74 | +- 장점2 : 애플리케이션 내의 서로 다른 로직이나 기능을 쉽게 캡슐화하여 깔끔하게 분리 |
| 75 | +- 장점3 : 코드 확장에 있어 든든한 기반 제공 |
| 76 | +- JSON은 사실 객체 리터럴 표기법의 서브셋 |
| 77 | + |
| 78 | + |
| 79 | +## 중첩 네임스페이스 패턴 |
| 80 | + |
| 81 | +> 객체 리터럴 표기법 패턴을 확장한 것 |
| 82 | +
|
| 83 | +```javascript |
| 84 | +YAHOO.util.Dom.getElementsByClassName("test"); |
| 85 | +``` |
| 86 | + |
| 87 | +- 다른 패턴에 비해 충돌 위험이 낮음 |
| 88 | +- 단일 객체 네임스페이스 패턴과 성능상 차이가 크지 않음 |
| 89 | + |
| 90 | + |
| 91 | +## 즉시 실행 함수 표현식 패턴 |
| 92 | + |
| 93 | +```javascript |
| 94 | +(() => { /** */ })(); |
| 95 | + |
| 96 | +(function foobar() { /** */ })(); |
| 97 | + |
| 98 | +function foobar() { |
| 99 | + foobar(); |
| 100 | +} |
| 101 | +``` |
| 102 | + |
| 103 | +- JS에서는 즉시 실행 함수로 정의된 내부의 변수와 함수 모두 외부에서 접근 불가능 |
| 104 | +- 함수를 호출하는 것만으로도 쉽게 코드의 은닉성 구현 가능 |
| 105 | +- 애플리케이션의 로직을 캡슐화하여 전역 네임스페이스로부터 보호 |
| 106 | + |
| 107 | + |
| 108 | +## 네임스페이스 주입 패턴 |
| 109 | + |
| 110 | +> 즉시 실행 함수 패턴의 또다른 변형 |
| 111 | +
|
| 112 | +- 함수 내에서 this를 네임스페이스의 프록시로 활용 |
| 113 | +- 특정 네임스페이스와 속성을 '주입' |
| 114 | +- 장점1 : 여러 객체나 네임스페이스에 기능적인 동작을 쉽게 적용 가능 |
| 115 | +- 장점2 : 이후에 확장될 기본 메서드(예: 게터, 세터)에 적용할 때 유용 |
| 116 | +- 단점 : 같은 목적을 달성하는 더 쉽고 효율적인 방법이 존재할 수도 있음 |
| 117 | + |
| 118 | + |
| 119 | +## 나의 생각 |
| 120 | + |
| 121 | +이번 장은 전반적으로 저자가 알고 있는 지식과 경험을 토대로 내용을 많이 적은 것 같아요. 그래서 중간중간 나오는 내용도 지식의 전달이라기보다는 '나는 이게 나은 것 같다', '나의 주관적인 의견이다'라는 식으로 얘기를 많이 하고 있죠. 그런데 이게 독자에게 결정권을 주거나 사고의 확장을 노린 것일 수도 있지만, 한편으로는 책으로 쓰는 동안도 지식의 확신이 제대로 든 것일까 의문이 들기도 했어요. |
0 commit comments