Merlin Tech Blog | Feed

객체를 바르게 만들기

Sat, 02 Jan 2021 10:00:03 GMT

원시형

ECMAScript 5 기준으로 다음과 같다.

문자열
숫자
Boolean
null
undefined

객체 리터럴

객체 리터럴은 다음과 같이 선언할 수 있다.

const test = { name: 'koko', genus: 'gorilla', genius: 'sing language' }

다음은 객체 리터럴이 함수 반환값인 경우다.

const amazeTheWorld = function () {
  // ...

  return { name: 'koko', genus: 'gorilla', genius: 'sing language' }
}

객체 리터럴을 여럿 생성할 때 반복되는 프로퍼티명을 입력하다 보면 실수하기 마련이다.
TDD 방식으로는 어떤 함수가 원하는 프로퍼티를 지닌 객체를 반환하는지는 충분히 확인 가능하지만 단순 객체 리터럴만으로는 직접 테스트할 방법이 마땅치 않다.
단순 객체 리터럴에서는 의존성 주입은 아예 시도조차 해볼 기회가 없지만, 함수는 애플리케이션 시작부에서 의존성을 주입하는 과정에 잘 어울린다.
단순 객체 리터럴은 생성 시 검증할 수 없다는 것도 문제다. 생성자는 전달받은 인자를 어떤 식으로든 검증하여 올바른 결과를 보장하지만, 단순 객체 리터럴은 그런 검증을 할 수 없다.
객체 리터럴은 한 곳에서 다른 곳으로 데이터 뭉치를 옮길 때 쓰기 편하다. 예를 들어 함수 인자가 많아 그 순서를 정확히 맞추기 쉽지 않을 때 객체 리터럴을 사용하면 유용하다.

모듈 패턴

데이터 감춤이 주목적인 함수가 모듈 API를 이루는 객체를 반환하게 한다.
임의로 함수를 호출하여 생성하는 모듈
선언과 동시에 실행하는 함수에 기반을 둔 모듈이 있다.

임의 모듈 생성

원하는 시점에 언제라도 생성할 수 있는 모듈로, 모듈 함수를 호출하여 API를 얻는다.

const MyApp = MyApp || {};

MyApp.wildLifePreserveSimulator = function (animalMaker) {
  // private
  const animal = [];

  return { 
    addAnimal: function (species, sex) {
      animals.push(animalMaker.make(species, sex))
    },
    getAnimalCount: function () {
      return animal.length
    }
  }
}

모듈은 다음과 같이 사용된다.

const perserve = MyApp.wildLifePreserveSimulator(realAnimalMaker);
perserve.addAnimal(gorilla, female);

animalMaker 같은 의존성을 외부 함수에 주입하여 리터럴에서 참조하게 만들 수도 있다. 임의 모듈 생성 방식으로 만든 모듈은 의존성을 쉽게 주입할 수 있다. 다른 모듈에 주입할 수 있어 확장성이 좋다.

즉시 실행 모듈 생성

외부 함수를 선언하자마자 실행하는 방법이다. 반환된 API는 이름공간을 가진 전역 변수에 할당된 후 해당 모듈의 싱글톤 인스턴스가 된다.

const MyApp = MyApp || {};

MyApp.wildLifePreserveSimulator = (function (animalMaker) {
  // private
  const animal = [];

  return { 
    addAnimal: function (species, sex) {
      animals.push(animalMaker.make(species, sex))
    },
    getAnimalCount: function () {
      return animal.length
    }
  }
}()); // <-- 즉시 실행한다.

함수 즉시 실행 시 의존성을 가져오지 못하면 외부 함수에 주입할 수 없다. 싱글톤이 꼭 필요하다면 임의 모듈 패턴으로 모듈을 코딩하고 해당 모듈을 요청할때마다 의존성 주입 프레임워크에서 같은 인스턴스를 제공하는 편이 의존성 주입 측면에서 더 낫다.

모듈 생성의 원칙

단일 책임 원칙에 따라 한 모듈에 한 가지 일만 시키자. 그래야 결속력이 강하고 다루기 쉬운 API를 작성하게 된다.
모듈 자신이 쓸 객체가 필요하다면 의존성 주입 형태로 이 객체를 제공하는 방안을 고려하라.
다른 객체 로직을 확장하는 모듈은 해당 로직의 의도가 바뀌지 않도록 분명히 밝혀라. (리스코프 치환 원칙)

객체 프로토타입과 트로토타입 상속

프로토타입 상속

ECMAScript 5 부터 나오는 Object.create 메서드를 사용하면 기존 객체와 프로토타입이 연결 된 객체를 새로 만들 수 있다.

const ape = { 
  hasThumbs: true, 
  hasTail: false, 
  swing: function () {
    return '매달리기'
  }
}

const chimp = Object.create(ape);
const bonobo = Object.create(ape);
bonobo.habitat = '중앙 아프리카';

// chimp의 __proto__ 는 ape
// bonobo의 __proto__ 는 ape

위 코드에서 ape는 공유 프로퍼티라서 수정하면 chimp와 bonobo 모두에 즉시 영향을 미친다.

프로토타입 체인

프로토타입 체인 이라는 다층 프로토타입을 이용하면 여러 계층의 상속을 구현할 수 있다.

const primate = { 
  stereoscopicVision: true
}

const ape = Object.create(primate);
ape.hasThumbs = true;
ape.hasTail = false;
ape.swing = function () {
  return '매달리기';
}

const chimp = Object.create(ape);

console.log(chimp.hasTail); // false (ape 프로토타입)
console.log(chimp.stereoscopicVision) // true (primate 프로토타입)

new 객체 생성

new 키워드를 앞에 붙여 생성자 함수를 실행하면 다음과 같이 실행이 된다.

빈 객체를 하나 만든다.
새 객체의 프로토타입(__proto__)을 생성자 함수의 프로토타입 프로퍼티(prototype)에 연결한다.
생성자 함수를 this로 실행하여 새 객체를 찍어낸다.

instanceof의 작동 원리는 다음과 같다.

instanceof의 우변 피연산자의 프로토타입이 좌변 피연산자의 프로토 타입 체인에 있는지 확인해본다.
만약 있으면 좌변 피연산자는 우변 피연산자의 인스턴스라고 결론 내린다.

new를 사용하도록 강제

function Marsupial(name, nocturnal) {
  if(!(this instanceof Marsupial)) {
    return new Marsupial(name, nocturnal);
  }
}

// 하지만 에러를 내는게 더 옳다고 본다.
function Marsupial(name, nocturnal) {
  if(!(this instanceof Marsupial)) {
    throw new Error('이 객체는 new를 사용하여 생성해야 합니다')
  }
}

함수 프로퍼티를 생성자 함수의 프로토타입에 정의하면 객체 인스턴스를 대량 생성할 때 함수 사본 개수를 한 개로 제한하여 메모리 점유율을 낮추고 성능까지 높이는 추가 이점이 있다.

클래스 상속

고전적 상속 흉내 내기

function Marsupial(name, nocturnal) {
  // ...
}

Marsupial.prototype.isAwake = function () {
  // ...
}

function Kangaroo(name) {
  // ...
}

Kangaroo.prototype = new Marsupial();
Kangaroo.prototype.hop = function {
  // ...
}

위 코드는 결론적으로 Kangaroo의 프로토타입이 된 Marsupial 인스턴스에 hop 함수를 추가하여 확장할 수 있게 됐다. hop 함수는 Marsupial 생성자 함수는 물론 Marsupial 생성자 함수의 프로토타입 어느쪽에도 추가되지 않는다.

하지만 위 코드처럼 작성하게 되면 코드 반복과 메모리 점유는 피하기 어렵다.

Marsupial 생성자 함수에 인자가 없다. 또한 Kangaroo의 프로토타입을 지정하는 시점은 물론이고 Kangaroo 인스턴스가 만들어지기 전까지 어떤 인자가 올지 알 길이 없다. 프로토타입 지정 시 인자를 알 수 없으므로 Marsupial 함수의 프로퍼티 할당 작업은 Kangaroo 함수에서도 되풀이 된다.

function Marsupial(name, nocturnal) {
  // ...
  this.name = name
  this.isNocturnal = nocturnal
}

function Kangaroo(name) {
  // ...
  // 중복을 만들 게 된다.
  this.name = name
  this.isNocturnal = false
}

함수형 상속

함수형 상속을 하면 데이터를 숨긴 채 접근을 다스릴 수 있다. 고전적 상속 흉내 내기의 생성자 반복 문제를 함수형 상속에서 해결 할 수 있다.

const AnimalKingdom = AnimalKingdom || {};

AnimalKingdom.marsupial = function (name, nocturnal) { 

  // ...
  return {
    getName: function () {
      return instanceName;
    },
    getIsNocturnal: function () {
      return instanceIsNocturnal;
    }
  }
}

AnimalKingdom.kangaroo = function (name) {
  const baseMarsupial = AnimalKingdom.marsupial(name, false);

  baseMarsupial.hop = function () {
    // ...
  }

  return baseMarsupial;
}

멍키 패칭

멍키 패칭은 추가 프로퍼티를 객체에 붙이는 것이다. 다른 객체와 함수를 붙여 객체의 덩치를 불리는 일은 자바스크립트 언어가 제격이다.

const MyApp = MyApp || {};

MyApp.Hand = function () {
  this.dataAboundHand = {};
}
MyApp.Hand.prototype.arrangeAndMove = function (sign) {
  this.dataAboundHand = '새로운 수화 동작'
}

MyApp.Human = function (handFactory) {
  this.hands = [handFactory(), handFactory()]
}
MyApp.Human.prototype.useSignLanguage = function (message) {
  const sign = {};
  // 메시지를 sign에 인코딩 한다.
  this.hands.forEach((hand) => {
    hand.arrangeAndMove(sign);
  })

  return '손을 움직여 수화하고 있어.';
}

MyApp.Gorilla = function (handFactory) {
  this.hands = [handFactory(), handFactory()]
}

// 트레이너가 코코에게 수화를 가르쳐 준다.
MyApp.TeachSignLanguageToKoko = (function () {
  const handFactory = function () {
    return new MyApp.Hand();
  }

  // 빈자의 의존서 주입
  const trainer = new MyApp.Human(handFactory);
  const koko = new MyApp.Gorilla(handFactory);

  // 멍키 패칭
  koko.useSignLanguage = trainer.useSignLanguage;

  console.log(koko.useSignLanguage('안녕하세요'))
}());

여기서 나중에 빌린 함수에(trainer.useSignLanguage) 다른 요건이 추가될 가능성이 항상 있기에 패치를 관장하는 빌려주는 객체가 빌리는 객체가 요건을 충족하는지 알아보게 하는 것이 가장 좋은 멍키 패칭 방법이다.

MyApp.Human.prototype.endowSigning = function (receivingObject) {
  if(typeof receivingObject.getHandCount === 'function'
    && receivingObject.getHandCount() >= 2 
  ) {
    receivingObject.useSignLanguage = this.useSignLanguage;
  } else {
    throw new Error('너에게는 수화를 가르쳐줄 수 없어');
  }
}

// 멍키패칭
trainer.endowSigning(koko);

이런 식으로 한 객체의 기능 다발 전체를 다른 객체로 패치할 수도 있다.

javascript pattern (...ing)

Fri, 01 Jan 2021 10:00:03 GMT

Goal

다양한 자바스크립트 패턴을 익히고 어느 상황에서 사용되는지 파악한다.

Good Javascript

일급 객체인 함수를 인자로 주고 반환값으로 돌려받는 형태에 길들어야 한다.
자바스크립트 함수는 일급 시민으로서 자신만의 프로퍼티와 메서드를 가질 수 있다.
클로저는 꼭 함수 같은 객체지만, 함수 생성 당시 환경을 내부에 고스란히 간직한다.
this는 함수를 호출한 객체를 참조한다.

SOLID 원칙

단일 책임 원칙

모든 클래스, 함수는 반드시 한 가지 변경 사유가 있어야 한다. 특정 함수의 유일한 관심사를 만들자. 어떻게 이행할지는 철저하게 외부에서 제공한 함수에 달려있게 하자.

개방/폐쇄 원칙

모든 소프트웨어 개체는 확장 가능성은 열어 두되 수정 가능성은 닫아야 한다.
어떤 경우라도 실행 코드를 변경하지 말고, 어떻게든 (상속 등의 방법으로) 재사용하고 확장 가능하라는 뜻이다.
변경 사항이 생길 만한 것을 추상화하여 함수 밖으로 빼내자.

리스코프 치환 원칙

어떤 타입에서 파생된 타입의 객체가 있다면 이 타입을 사용하는 코드는 변경하지 말아야 한다.
한 객체를 다른 객체에서 파생하더라도 그 기본 로직이 변경되어서는 안 된다는 뜻이다.
작성중인 함수가 기반 클래스로 하는 일과 서브 클래스로 하는 일이 다르다면 이 원칙을 어긴 셈이다.

인터페이스의 분리 법칙

인터페이스란 어떤 기능을 '구현'하지 않고 (명칭, 파라미터, 반환타입을) '서술'만 한 코드 조각이다.
함수가 기대하는 인자가 무엇인지 명확히 하고 그 기대치를 최소화해야 한다.
특정 타입의 인자를 바라기보다는 이 타입에서 실제로 필요한 프로퍼티가 더러 있을 거라 기대하는 것이다.

의존성 역전 원칙

상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며 이 둘은 추상화에 의존해야 한다.

// projection 추상화
function d3_svg_line(projection) {
  // ...
  function line(data) {
    // ... 

    function segment() {
      segments.push('M', interolate(projection(points), tension))
    }
  }
}

d3.svg.line = function () {
  return d3_svg_line(d3_identity);
}

d3.svg.line.radial = function () {
  const line = d3_svg_line(d3_svg_lineRadial);
}

DRY 원칙

반복하지 마라
DRY한 코드로 만드는 과정에 의존성 주입과 단일 책임 문제가 개입된다.
'지식 조각'을 반복시키지 말자.

테스트

테스트 더블

더미(dummy): 보통 인자 리스트를 채우기 위해 사용되며, 전달은 하지만 실제로 사용되지는 않는다.
틀(stub): 더미를 조금 더 구현하여 아직 개발되지 않은 클래스나 메서드가 실제 작동하는 것처럼 보이게 만든 객체로 보통 리턴값은 하드 코딩한다.
스파이(spy): 틀과 비슷하지만 내부적으로 기록을 남긴다는 점이 다르다. 특정 객체가 사용되었는지, 예상되는 메서드가 특정 인자로 호출되었는지 등의 상황을 감시하고 이러한 정보를 제공하기도 한다.
모의체(fake): 틀에서 조금 더 발전하여 실제로 간단히 구현된 코드를 갖고는 있지만, 운영 환경에서 사용할 수는 없는 객체다.
모형(mock): 더미, 틀, 스파이를 혼합한 형태와 비슷하나 행위를 검증하는 용도로 주로 사용된다.

경량 의존성 주입 프레임 워크

DI 프레임워크를 사용하지 않고 의존성 주입(DI)하는 것을 두고 '빈자의 의존성 주입(poor man's dependency injection)'이라 한다.
의존성 주입 프레임워크는 다음과 같이 동작한다.
1. 애플리케이션이 시작되자마자 인젝터블을 확인하고 해당 인젝터블이 지닌 지칭하며 순서대로 DI 컨테이너에 등록한다.
2. 객체가 필요하면 컨테이너에 요청한다.
3. 컨테이너는 일단 요청받은 객체와 그 의존성을 모두 재귀적으로 인스턴스화한다. 그런 다음, 요건에 따라 필요한 객체에 각각 주입한다.

DiContainer = function() {
  // ...
  this.registrations = [];
}

DiContainer.prototype.register = function (name, dependencies, func) {
  var ix;

  if(typeof name !== 'string' ||
    !Array.isArray(dependencies) ||
    typeof func !== 'function') {
      throw new Error(this.messages.registerRequiresArgs);
    }

  for(ix = 0; ix < dependencies.length; ++ix) {
    if(typeof dependencies[ix] !== 'string') {
      throw new Error(this.messages.registerRequiresArgs);
    }
  }

  this.registrations[name] = { dependencies, func };
}

diContainer.prototype.get = function (name) {
  var self = this;
  var registration = this.registrations[name];
  var dependencies = [];

  if(registration === undefined) {
    return undefined;
  }

  registration.dependencies.forEach(function(dependencyName) {
    var dependency = self.get(dependencyName);
    dependencies.push( dependency === undefined ? undefined : dependency);
  })

  return registration.func.apply(undefined, dependencies);
}

애스팩트 지향 프로그래밍(AOP)

단일한 책임 범위 내에 있지 않은 하나 이상의 객체에 유용한 코드를 한데 묶어 눈에 띄지 않게 객체에 배포하는 기법.
배포할 코드 조각을 어드바이스(advice), 어드바이스가 처리할 문제를 애스팩트(aspect) 또는 황단 관심사라고 한다.
AOP의 핵심은 함수 실행(타깃)을 가로채어 다른 함수(어드바이스)를 실행하기 직전이나 직후, 또는 전후에 실행시키는 것이다.
around 함수의 핵심 (fnName, advice, fnObj)
- 원본 함수를 어드바이스로 대체한다.
- 타깃 정보를 어드바이스에 전달한다. 내부에 원본 타깃 함수를 저장한 객체를 만들어 어드바이스에 넘긴다.
- 타깃에 넘기는 인자도 함께 전달한다.

Aop = {
  around: function (fnName, advice, fnObj) {
    var origianlFn = fnObj[fnName];
    fnObj[fnName] = function () {
      return advice.call(this, {fn: origianlFn, args: arguments})
    }
  },
  // 어드바이스 작성시에 원본 함수를 호출할 수 있도록 해주는 도우미 함수
  next: function (targetInfo) {
    return targetInfo.fn.apply(this, targetInfo.args)
  }
}

인터페이스

인터페이스는 기능이 정의된 모듈과 그것을 사용할 모듈 사이에 일종의 규약(contract)처럼 쓰인다.
인터페이스 분리 원칙은 객체 사용부가 할 일을 단순화하고 변경에 따른 영향도를 개발자가 잘 파악할 수 있게 해준다.

규약 정의

규약 정의는 규약명과 객체가 규약을 지키는지를 true/false로 반환하는 평가 함수로 이루어진다.

// define 시그니처
function define(contractName, evaluator)

규약을 지키는지 판단

// fullfills 메서드 틀
function fullfills(contractName, obj)

규약을 지킨다고 단언

규약을 지켰는지 여부는 fulfills 메서드를 다시 쓰면 된다.

function assert(contractName, obj)

규약 레지스트리 코드

// fullfills 함수
// obj가 규약을 지키면 true, 어기면 false를 반환한다.
var ReliableJavaScript = ReliableJavaScript || {};
ReliableJavascript.contractRegistry = function() {
  'use strict';

  // 등록된 규약
  var registry = {};

  return {
    define: function define(contractName, evaluator) {
      // ...에러 조건문
      registry[contractName] = evaluator
    },
    fullfills: function fullfills(contractName, obj) {
      // ...에러 조건문
      return registry[contractName](obj);
    },
    assert: function assert(contractName, obj) { 
      if(!this.fulfills(contractName, obj)) {
        throw new Error(this.getMessageForFiledContract(contractName, obj))
      }
    },
    attachReturnValidator: function attachReturnValidator(funcName, funcObj, contractName) {
      var self = this;
      if(typeof funcName !== 'string') {
        throw new Error(self.messages.funcNameMustBeString);
      }
      if(typeof funcObj !== 'object') {
        throw new Error(self.messages.funcObjMustBeObject);
      }
      if(typeof contractName !== 'string') {
        throw new Error(self.messages.nameMustBeString);
      }

      Aop.around(funcName,
        function(targetInfo) {
          var ret = Aop.next(targetInfo); // 실제 모듈을 호출해서 객체를 얻는다.
          self.assert(contractName, ret): // 실제 모듈이 contractName을 지켰는지 확인한다.
        }, funcObj)
    },
    messages: {
      // ...
    },
    getMessageForNameNotRegistered: function getMessageForNameNotRegistered(contractName) {
      return this.messages.nameMustBeRegistered.replace('_', contractName)
    },
    getMessageForFiledContract: function getMessageForFiledContract() {
      // ...
    }
  }
}

실제 사용 예

// attendeeContracts.js
// 이 함수를 호출하여 Conference.attendee() 가 올바르게 attendee를 생성했는지 확인하는 애스팩트를 설치한다.
Conference.attendeeContracts = function attendeeContracts(registry) {
  'use strict';

  var attendeePersonalInfo = 'Conference.attendee.personalInfo';
  var attendeeCheckInManagement = 'Conference.attendee.checkInManagement';

  function fulfillsPersonalInfo(att) {
    //...
  }

  function fullfillsCheckInManagement(att) {
    // ...
  }

  registry.define(attendeePersonalInfo, fulfillsPersonalInfo);
  registry.define(attendeeCheckInManagement, fullfillsCheckInManagement);

  // 실제 Conference의 attendee를 호출해서 attendeePersonalInfo 가 맞는 지 확인한다.
  registry.attachReturnValidator('attendee', Conference, attendeePersonalInfo);
  registry.attachReturnValidator('attendee', Conference, attendeeCheckInManagement);
  
}

var registry = ReliableJavaScript.contractRegistry();
Conference.attendeeContracts(registry);

// 올바르게 생성된 객체인지 애스팩트가 보장한다.
var a = Conference.attendee('Rock', 'Star'); // 예외를 던지지 않음.

Pattern

Callback pattern

콜백은 나중에 실행할 부차 함수(second function)에 인자로 넣는 함수다. 즉, 함수를 넘겨주면 나중에 실행시켜줘 라고 하는 것과 같다.
여기서 콜백이 실행될 '나중' 시점이 부차 함수의 실행 완료 이전이면 동기(synchronous), 반대로 실행 완료 이후면 비동기(asynchronous)라고 본다.

단위 테스트

콜백 실행 횟수가 정확한가?
콜백이 실행될 떄마다 알맞은 인자가 전달 되는가?
스파이 함수를 이용하면 이런일에 제격이다.
익명 콜백함수를 곧장 콜백으로 넘기기 보다는 별도의 기능 모듈로 분리할 수 있다면 추출해서 따로 테스트를 진행하자.
익명 함수는 디버깅을 매우 어렵게 만든다.

시나리오

컨퍼런스에 attend(참가자) 등록을 하는 시스템이 있다.
한명 또는 여러명을 한번에 참가 등록을 할수 있다.
attend(참가자)는 또는 참가자들은 참가자 등록이 되었는지 안되었는지 확인할 수 있다.
attend(참가자)는 또는 참가자들은 이름을 알 수 있다.

code

var C = {};

// 참가자 체크인 여부를 비롯한 각종 정보를 attendee 함수가 생성한 객체에 담아둔다.
C.attendee = function(firstName, lastName) { 
  //...

  return { 
    getFullName: function() {},
    isCheckedIn: function() {},
    checkIn: function() {}
  }
}

// singleton
var C.attend = function(name){
  var fullName = name;
  return {
    registry: function() {},
    isRegistry: function() {},
    getFullName: function() {}
  }
}

// 참가자 한명이 생성되었다.
// 참가자는 참가자 등록에 실제 현실에선 수동적이지만 oop 에선 능동적으로 생각한다.
var attendee1 = C.attend('merlin1');
var attendee2 = C.attend('merlin2');

var C.attendeeCollection = function(){
  var attendees = [];

  return {

    contains: function (attendee) {
      return attendees.indexOf(attendee) > -1; // 들어있니??

    },
    add: function (attendee) {
      if (!this.contains(attendee)) {
        attendees.push(attendee);
      }

    },
    remove: function (attendee) {
      var index = attendees.indexOf(attendee);

      if (index > -1) {
        attendees.splice(index, 1);
      }
    },
    getCount: function() {
      return attendees.length;
    },
    iterate: function (callback) {   // 반복..
      // attendees의 각 attendee에 대해 콜백을 실행한다..
      attendees.forEach(callback);

    }

  }
}

var attendees = C.attendeeCollection();
function addAttendeesToCollection(attendeeArray) {
      attendeeArray.forEach(function(attendee) {
        collection.add(attendee);
      });
}
addAttendeesToCollection([attendee1, attendee2]);
attendees.iterate(function doCheckIn(attend) { // 익명의 콜백함수 -> 디버깅 용이함을 위해 이름을 지정한다.
  attend.checkIn();
  // 외부 서비스를 통해 체크인 등록한다.
});

// 참가자 체크인은 중요한 기능이므로 checkInService 자체 모듈에 캡슐화 하자.
// 체크인 로직을 attendeeCollection에서 분리하여 코드를 재사용할 수도 있다.
// 외부 시스템의 체크인 등록 기능을 별도의 책임으로 보고 등록용 객체를 cehckInSevice에 주입하자.
// checkInRecorder 주입
C.checkInService = function(checkInRecorder) {
  const recorder = checkInRecorder;

  return {
    checkIn: function(attendee) { // attendee 주입
      // attendeeCollection 에서의 attendee 한명
      attendee.checkIn();
      recorder.recordCheckIn(attendee);
    }
  }
}

// 다음과 같이 사용
const checkInService = C.checkInService(C.checkInRecorder())
const attendees = C.attendeeCollection()

attendees.iterate(checkInService.checkIn);

주의사항

콜백을 사용할때는 디버깅에 용이하기 위해 이름을 붙여주자.
콜백 헬이 발생할때는 편 코딩으로 해결할수 있다.
콜백 함수 안의 this를 주의하자. this 값은 함수를 호출한 (대게 함수 앞에 점으로 연결한) 객체를 가리키지만, 콜백 함수를 만들어 넣을 때 어떤 객체를 참조하라고 직접 지정할 수는 없다. 이런 이유로 콜백 함수는 대부분 this를 명시적으로 가리킨다.

var Conference = Conference || {};

// 체크인을 마친 attendeeCollection의 attendee 객체 수를 세는 모듈
Conference.checkedInAttendeeCounter = function() {
  var checkedInAttendees = 0;
  
  return {
    increment: function() {},
    getCount: function() {},
    countIfCheckedIn: function(attendee) {
      if(attendee.isCheckedIn()) {
        // this.increment(); // 이부분의 this 가 문제..
      }
    }
  }
}

// test시에
var count = Conference.checkedInAttendeeCounter();
count.countIfCheckedIn.call({}, attendee) // this가 checkedInAttendeeCounter를 꼭 가리키는건 아니라는걸 판별하자.

// 해결 
Conference.checkedInAttendeeCounter = function() {
  var checkedInAttendees = 0;
  var self = {
    increment: function() {},
    getCount: function() {},
    countIfCheckedIn: function(attendee) {
      if(attendee.isCheckedIn()) {
        // this.increment(); // 이부분의 this 가 문제..
        self.increment();
      }
    }
  }

  return self;
}

정리

한가지 일을 여러번 수행해야 할때 함수하나를 인자로 보내(콜백 패턴) 여러번 호출을 진행할수 있다.
A작업이 끝난뒤에 B작업이 수행되어지길 바랄때 콜백 패턴을 이용할 수 있다.

Promise pattern

비동기 액션을 초기화하고 성공과 실패 케이스를 각각 처리할 콜백을 준다.
이벤트 기반의 비동기 프로그래밍보다 훨씬 더 이해하기 쉽고 우아하며 탄탄한 코드를 작성할 수 있다.
'귀결되었다'는 말은 프라미스 숙명이 어느 한쪽으로 결정됐단 뜻이다.
Promise는 나중에 벌어질 이벤트와 그 성공/실패에 따라 각기 실행할 콜백을 캡슐화한 장치다.
Promise 생성자의 인자는 비동기 작업을 감싼 함수다. 이 함수는 두 인자, resolve, reject를 받는다. Promise가 귀결 또는 버림 처리될 때 둘중 한 함수가 호출된다.
Promise 객체의 핵심은 then 메서드로, 콜백 함수 2개를 인자로 취한다.
Promise가 '귀결되면' 첫 번째 콜백으로 이어지고, 이 콜백은 귀결값을 파라미터로 받는다.
Promise가 '버려지면' 두 번째 콜백이 실행되고 버림 사유를 파라미터로 받는다. 버림 사유는 보통 Error 객체로 받지만, 단순 문자열도 상관없다.

Promise 기반 코드를 테스트할 때 조심할 함정에 대해서는 다음과 같다.

비동기로 작동하는 Promise는 조심하지 않으면 테스트 기대식이 실행될 때 여전히 미결 상태로 남을 수 있다. 그래서 실패해야 할 테스트가 성공한 것처럼 눈속임한다. jasmine은 특별히 비동기 코드 테스팅을 done() 함수로 지원한다.
XMLHttpRequest를 사용한 코드를 테스트할 때 서버를 직접 호출하지 않고 비동기적인 HTTP 특성을 흉내 내고 싶을 때가 있다. jasmine이 제공하는 AJAX 모의 라이브러리를 사용하면 된다.
Promise는 구조상 체이닝을 할 수 있다. 경우의 수를 모두 따져보고 의도했던 then 콜백으로 실행 흐름이 이루어지는지 확인하라.

partial pattern

커링 요소에 뭔가 더 보태서 기능을 할 수있게 끔 만드는 패턴이다.
인자가 여럿 있고 그중 일부는 값이 불변인 함수를 쓸 경우가 있다. 이때 같은 값을 계속 반복하기보다 원본함수를 새로운 함수로 감싼 다음, 상수 인자는 건네주고 값이 달라지는 나머지 인자만 표출하는 것이 좋다.
값이 불면인 상수 인자를 지난 함수 호출부는 상수성(constancy)을 캡슐화하여 함수를 새로 만드는 것이 좋다.
커링은 여러 인자를 거느린 함수를 인자 하나만으로 취하는 여러 단계의 함수들로 쪼갠다.

부분 패턴 시나리오

행사장 근처에 있는 음식점 위치를 알려주는 서드파티 웹 서비스가 있다고 하자.
getRestaurantsWithinRadius(address, radiusMiles, cuisine) 요건상 address와 cuisine부분은 변경의 필요성이 없어 보인다.
restaurantApi 에서 반환하는 api 객체에 새로운 메서드를 집어넣기로 하자.
address 와 raius 파라미터를 고정한 채 getRestaurnatsNearConference(cuisine) 가 getRestaurantsWithinRadius 반환값을 무조건 반환하게 하자.

부분 패턴 단위 테스트

올바른 인자로 기존 api를 잘 호출하고 있는가?
기존 api에서 반환되는 값을 잘 반환하고 있는가?

부분 패턴 code

function addGetRestaurantsNearConference(targetInfo) {
    'use strict';

    //ThirdParty.retaurantApi() 가 반환한 원본 API
    var api = Aop.next.call(this, targetInfo); // Aop.next 는 원본 함수에 원본 인자를 넣어 호출해준다...


    //API에 추가할 함수
    function getRestaurantsNearConference(cuisine) {
      return api.getRestaurantsWithinRadius(
        '울산 남구 신정로 20번길 988', 2.0, cuisine);
      // 앞에 2개의 인자는 값이 불변인 상수 인자.

    }

    // 없으면 이 함수를 추가한다
    api.getRestaurantsNearConference = api.getRestaurantsNearConference || getRestaurantsNearConference;

    //수정한 API를 반환한다
    return api;

  },

커링

커링은 인자를 여럿 취하는 함수를 인자 하나만 받는 함수 여러 개로 해체 하는 기법이다.
구체적인 형태를 아주 간단히 표현하면 다음과 같다.

function getRestaurantsCurried(address) {
  const self = this;
  return function(radius) {
    return function(cuisine) {
      return self.getRestaurantsWithinRadius(address, radius, cuisine);
    };
  };
}

부분 적용 함수

부분 적용 함수는 언뜻 인자를 여럿 받는 함수를 더 적은 인자를 받는 함수로 바꾸는 커링과 비슷해 보인다.
그러나 위 addGetRestaurantsNearConference 구현부를 보면 알 수 있듯이 오히려 정반대에 가깝다.
즉, 부분 적용 함수는 이전 단계에서 생성된 커링 요소에 뭔가 더 보태서 부분 적용 함수 버전과 기능이 같은 함수로 만든 것이다.

function getRestaurantsNearConference(cuisine) {
  return getRestaurantsCurried("울산")(2.0)(cuisine);
}

memoization pattern

일명 기억패턴 , 보통 함수 호출시 전달받은 인자를 키로 그 반환 결과를 어떤 구조체에 저장하고, 같은 키를 인자로 다시 함수를 호출하면 저장해둔 값을 꺼내어 바로 바환한다. 물론, 이때 함수 본체는 그냥 건너 뛴다.

메모이제이션 시나리오

서드파티 api가 요청 건당 과금을 하는 통해 카드 청구서가 수북하다.
그러니 검색 결과를 어디다가 저장해놓았다가 다른 참가자가 같은걸 요구하게 되면 그 데이터를 그대로 반환하면 좋을꺼 같다.
현재 제공되고 있는 api에 퍼사드(facade)나 래퍼(wrpper)를 끼워넣고 이전 검색 결과를 저장/반환하는 기능을 붙이면 된다.
여기서 퍼스드의 경우에는 프로그래밍을 잘 모르는 사용자에게 최소한의 api만 공개하는, 이렇게 일부만 노출하는 패턴을 퍼사드 패턴이라고 한다.

메모이제이션 단위 테스트

여러 번 호출해도 서드파티 API는 딱 한 번만 질의한다.
다시 호출하면 이전에 서드파티 API가 반환했던 음식점 정보를 그대로 반환한다.

메모이제이션 code

memoizedRestaurantApi = function (thirdPartyApi) {
  'use strict';

  var api = thirdPartyApi,
    cache = {};

  return {
    getRestaurantsNearConference: function (cuisine) {
      if (cache.hasOwnProperty(cuisine)) {
        return cache[cuisine];
      }

      var returnPromise = api.getRestaurantsNearConference(cuisine);

      cache[cuisine] = returnPromise;
      return returnPromise;
    }
  }

메모이제이션 애스팩트 생성하기

목표 : 다른 코드에서도 메모이제이션 덕을 보게끔 메모이제이션 코드를 위 memoizedRestaurantApi에서 추출하여 애스팩트로 옮기는 것이다.

var Aspects = Aspects || {};

Aspects.returnValueCache = function() {
  'use strict';

  var cache = {};

  return {
    advice: function(targetInfo) {
      // 함수에 넘긴 인자를 캐시 키로 사용한다.
      var cacheKey = JSON.stringify(targetInfo.args);

      if(cache.hasOwnProperty(cacheKey)) {
        return cache[cacheKey];
      }

      var returnValue = Aop.next(targetInfo); // 원본 함수
      cache[cacheKey] = returnValue;

      return returnValue;
    }
  }
}

// 사용법
Aop.around('getRestaurantsWithinRadius', Aspects.returnValueCache().advice, api);

returnValueCache 애스팩트를 restaurantApi에 적용하기

// getRestaurantsWithinRadius에 메모이제이션 패턴 적용
Aop.arount(
  // 반환값을 수정해야 할 함수
  'restarantApi',

  // 반환값을 수정하는 함수
  function addMemoizationToGetRestatantsWithinRadius(targetInfo) {
    var api = Aop.next.call(this, targetInfo);

    Aop.around('getRestaurantsWithinRadius', Aspects.returnValueCache().advice, api);

    return api;
  }, 
  ThirdParty
)

// ThirdParty.restaurantApi()에 getRestaurantsNearConference 멤버 추가
Aop.around(
  'restarantApi',

  // 반환값을 수정하는 함수
  function addGetRestaurantsNearConference(targetInfo) {
    'use strict';

    var api = Aop.next.call(this, targetInfo);

    // API에 추가할 함수
    function getRestaurantsNearConference(cuisine) {
      return api.getRestaurantsWithinRadius('포항', 2.0, cuisine)
    }

    // 없으면 이 함수를 추가한다.
    api.getRestaurantsNearConference = api.getRestaurantsNearConference || getRestaurantsNearConference;

    return api;
  },
  ThirdParty
)

singleton pattern

다중 객체 인스턴스를 만들 필요가 없거나, 오히려 만들면 안 될 때도 있다. 이렇게 하나의 객체 인스턴스만 존재해야 할 때는 싱글톤 패턴을 사용한다.

싱글톤 패턴 시나리오

위에서 생각해봤던 메모이제이션을 적용했던 restaurantApi 인스턴스(api)가 2개 만들어져 각각 똑같은 인자로 getRestaurantsWithinRadius 함수를 2번 객체를 호출하면 1번 객체의 함수 호출 후 캐시된 결과를 다시 사용할까???
위 질문에서 "1번 객체 함수 호출로 캐시된 결과를 다시 사용해" 라고 대답할 수 있어야 한다.
restaurantApi 인스턴스들이 전부 따로 캐시를 두지 않고 단일 캐시를 공유할 수 있으면 이상적이다.
의존성 주입으로 인스턴스간에 캐시 객체를 공유할수 있게 해주면 좋을듯 싶다.

싱글톤 패턴 code

// 공유할 캐시 객체를 주입받는다.
const cache = {}; // 데이터 감춤 따위의 기능은 없다.
memoizedRestaurantApi = function(cache, thirdPartyApi) {
  const restaurantCache = cache || {}; // 캐시를 주입안하면 내부적으로 생성한다.
  //(...)
};

캐시가 일반적인 객체가 아닌 여러가지 기능을 하는 캐쉬의 역활도 할수 있음 좋겠다. 예를들어 최저 사용빈도 기능과 일정 시간까지만 캐시값을 저장해두는게 더 합리적인 상황도 필요할 수있다.
이럴땐 리터럴가지고만은 캐시를 만들수 없다.

simpleCache = function() {
  "use strict";

  var privateCache = {};

  function getCacheKey(key) {
    return JSON.stringify(key);
  }

  return {
    hasKey: function(key) {
      return privateCache.hasOwnProperty(getCacheKey(key));
    },
    setValue: function(key, value) {
      privateCache[getCacheKey(key)] = value;
    },
    getValue: function(key) {
      return privateCache[getCacheKey(key)];
    },
  };
};

객체 리터럴을 공유 캐시로 쓸 때는 객체 리터럴이 이미 싱글톤이니 캐시 인스턴스가 하나만 있다는 사실이 명백했다.
위 simpleCache 캐시는 함수라서 이 함수를 실행하게 되면 각자 객체 인스턴스를 생성하기 때문에 다시 같은 문제를 야기하게 된다.
restaurantApi 인스턴스가 다들 단일 인스턴스를 바라보게 하려면 즉시 실행을 응용하여 싱글톤 패턴을 구현하는 것이 좋다.
다음 코드 RestaurantsWithinRadiusCache 모듈은 호출할 때마다 똑같은 simpleCache 인스턴스를 반환하는 단일 함수인 getInstance를 표출한다.

const Conference = Conference || {};
Conference.caches = Conference.cache || {};

// restaurantApi.getRestaurantsWithinRadius 함수에서
// 캐시로 사용할 simpleCache(싱글톤) 생성
Conference.caches.RestaurantsWithinRadiusCache = (function() {
  "use strict";

  var instance = null;
  return {
    getInstance: function() {
      if (!instance) {
        instance = Conference.simpleCache();
      }
      return instance;
    },
  };
})();
const cache = RestaurantsWithinRadiusCache.getInstance();

factory pattern

팩토리 패턴은 객체를 단순히 찍어내는 함수이다.
Object.create 메서드 역시 언어 자체에 포함된 팩토리이다.
모듈은 데이터 감춤이라는 부가 기능이 있지만, 객체 생성/반환이 주 임무라는 점에서 엄밀히 말하면 팩토리 이다.
일반 new 나 일반 함수를 호출해서 객체를 만들어 쓰면 되는데, 굳이 팩토리를 이용하는 이유는 제어와 추상화를 강화하기 위해서이다.
용도에 특화된 유형별 create 메서드가 여럿 있는 팩토리도 있다.
팩토리엔 대부분 create 같은 이름의, 하나 또는 그 이상의 파라미터를 받는 메서드가 하나 있다. 이 메서드는 전달 받은 파라미터를 살펴보고 알맞은 객체를 내어준다.
팩토리는 객체 생성을 강력하게 다스리고 한 겹 더 추상화한다.

팩토리 패턴 시나리오

유형이 다른 두가지의 프레젠테이션 모델링을 고민 해보자.
일반은 제목과 발표자 정보가 있고, 벤더 프레젠테이션은 여기에 벤더명, 제품정보가 추가된다.
프로퍼티 뭉치로 되어있는 객체를 하나 받았을때 프레젠테이션 유형은 알아서 판단하고 싶다.

팩토리 단위 테스트

create 함수는 잘못된 파라미터를 받지 않는다.
파라미터가 정상적으로 전달되면 그에 따른, 원객체의 생성함수를 정확히 호출한다.
이렇게 하여 반환된 객체가 바로 create가 반환한 객체다.

팩토리 패턴 code

// 팩토리에서 하는일
// 1. create의 파라미터는 이전에 객체 리터럴로 넘겼을때 undefined로 자리 끼움했던 보기 흉한 형태에서 완전히 벗어났다
// 2. 파라미터에 무엇이 들었든 잘 건네주기만 하면 뒷일은 팩토리가 알아서 처리한다.
// 3. 나중에 유형이 다른 프레젠테이션도 얼마든지 추가할 수 있다.
// 4. new 키워드로 객체를 생성해야 한다는 사실을 팩토리가 대신 기억해준다. 팩토리 안에서 new...

const Conference = Conference || {};


Conference.presentationFactory = function presentationFactory() {
  "use strict";

  return {
    create: function(obj) {
      // obj가 샬롯이 주는 데이터이다...
      var baseProperty = ["title", "presenter"],
        vendorProperty = ["vendor", "product"],
        allProperty = baseProperty.concat(vendorProperty),
        p,
        ix;

      for (p in obj) {
        if (allProperty.indexOf(p) < 0) {
          // indexOf 배열에서 지정된 요소를 찾을 수있는 첫 번째 인덱스를 반환 -1 이면 못찾음.
          throw Error(
            Conference.presentationFactory.messages.unexpectedProperty + p
          );
        }
      }

      // 나중에 Presentation 에서 유래한 객체를 반환할 예정..

      for (ix = 0; ix < vendorProperty.length; ++ix) {
        if (obj.hasOwnProperty(vendorProperty[ix])) {
          return new Conference.VendorPresentation(
            obj.title,
            obj.presenter,
            obj.vendor,
            obj.product
          );
        }
      }
      return new Conference.Presentation(obj.title, obj.presenter);
    },
  };
};

sandbox pattern

샌드박스 패턴은 자바스크립트의 이름공간의 단점을 해결하는 방안으로 다른 모듈 및 그 샌드박스에 전혀 영향을 주지 않고 어떤 모듈을 실행할수 있는 독자적 환경을 구축한다는 점이다.
단일 전역 변수에 지나치게 의존하지 않고 점으로 길게 연결된 이름을 가진 타입이 범람하지 않게 한다.
다른 모듈 및 샌드박스에 전혀 영향을 주지 않고 어떤 모듈을 '실행할 수 있는' 독자적 환경을 구축한다는 점

샌드박스 시나리오

대시보드 특성 측면상 대시보드는 보통 담당자 별로 보고 싶어하는 타입으로 커스터마이징을 할수 있어야 한다. 예를 들면 어떤 사람은 a,b 만을 어떤 사람은 a,c 만을 보고 싶어할 수도 있다.
각 위젯마다의 의존성은 없어야 겠다.
우선 이런 위젯들을 서로 떼어놓을수 있다면 테스트와 구성 요소간 결합도가 낮아진다. 이에 해결책은 각각 위젯을 자신의 샌드박스에 가둬두자.

샌드박스 code

샌드박스 편
WidgetSandbox의 목표는 대시보드 위젯 간 결합도를 낮추고 떼어놓는 일이다.

const Conference = Conference || {};

Conference.WidgetSandbox = function() {
  "use strict";

  // new로 실행했는지 보장한다..
  if (!(this instanceof Conference.WidgetSandbox)) {
    throw new Error(Conference.WidgetSandbox.messages.mustBeCalledWithNew);
  }

  var widgetFunction,
    toolsToLoad = [],
    argsArray;

  // var widgetFunction = arguments[arguments.length -1],
  //   toolsToLoad = [];

  // arguments에서 *진짜* 배열을 추출한다.
  argsArray = Array.prototype.slice.call(arguments);

  // 배열 마지막 원소는 widgetFunction일 것이다..
  widgetFunction = argsArray.pop();

  if (typeof widgetFunction !== "function") {
    throw new Error(Conference.WidgetSandbox.messages.fcnMustBeProvided);
  }

  // if(arguments[0] instanceof Array){
  //   toolsToLoad = arguments[0];
  // }

  toolsToLoad = argsArray[0] instanceof Array ? argsArray[0] : argsArray;

  toolsToLoad.forEach(function(toolName) {
    if (!Conference.WidgetTools.hasOwnProperty(toolName)) {
      throw new Error(Conference.WidgetSandbox.messages.unknownTool + toolName);
    }

    Conference.WidgetTools[toolName](this);
  }, this); // 콜백 내에서 this가 sandbox 인스턴스를 가리키도록 보장한다..

  widgetFunction(this);
};

위젯 편

const Conference = Conference || {};
Conference.Widgets = Conference.Widgets || {};

Conference.Widgets.attendeeNamesWidget = function(sandbox) {
  "use strict";

  // 해당 도구를 사용할 수 없으면 즉시 실패처리를 한다.
  if (!sandbox.dom) {
    throw new Error(Conference.Widgets.messages.missingTool + "dom");
  }
  if (!sandbox.attendeeNames) {
    throw new Error(Conference.Widgets.messages.missingTool + "attendeeNames");
  }

  // attendeeNames를 조회하여 대시보드에 추가한다.
  sandbox.attendeeNames.getAll().then(
    function resolve(name) {
      // sandbox.dom 으로 이름 목록을 표시한다.
    },
    function rejected(reson) {
      // sandbox.dom 으로 위젯 대신 에러 메시지를 나타낸다.
    }
  );
};

도구 편
도구를 모듈로 정의하면 도구마다 모듈 함수가 WidgetSandbox 인스턴스를 받고, 다음 코드 처럼 도구가 스스로 WidgetSandbox 프로퍼티에 추가한다.

const Conference = Conference || {};
Conference.WidgetTools = Conference.WidgetTools || {};

Conference.WidgetTools.attendeeNames = function(sandbox, injectedAttendeeWebApi) {
  "use strict";

  // attendeeApi를 선택적으로 주입할 수 있게 코딩한다 단위 테스트 할때 유용하다.
  var attendeeWebApi = injectedAttendeeWebApi || Conference.attendeeWebApi();

  sandbox.attendeeNames = {
    getAll: function gatAll() {
      return attendeeWebApi.getAll().then(function extractNames(attendees) {
        //각 참가자의 전체 성명만 추출하여 반환한다
        var names = [];
        attendees.forEach(function addName(attendee) {
          names.push(attendee.getFullName());
        });

        return names;
      });
    },
  };
};

샌드박스 정리

WidgetSandbox는 new로 호출되어야 한다. 여러 샌드박스를 만들기 위해서 위젯 하나당 하나의 widgetSandbox 인스턴스를 가진다고 생각하면 될듯 싶다.
도구들은 모듈로 정의를 하고 도구마다 모듈 함수가 WidgetSandbox 인스턴스를 받고 도구가 스스로를 WidgetSandbox 인스턴스의 프로퍼티에 추가한다.
WidgetSandbox 생성자는 다음둘중 하나를 받는다.
- 첫 번째 인자는 위젯에서 쓸 도구명이 담긴 배열, 두번째 인자는 위젯함수 또는 도구명을 개별 인자로 죽 나열하고 위젯 함수를 제일 마지막 인자에 넣는다.
```
const weatherSandbox = new Conference.WidgetSandbox(['toolA', 'toolB'], Conference.widgets.weatherWidget);
```
- 도구명을 개별 인자로 죽 나열하고 위젯 함수를 제일 마지막 인자에 넣는다.
```
const weatherSandbox = new Conference.WidgetSandbox('toolA', 'toolB', Conference.widgets.weatherWidget);
```
각 도구들은 싱글톤 객체이다.
위젯샌드박스에서 각 도구를 실행시키면 this ( 여기서 this는 WidgetSandbox 의 인스턴스가 되겠다.) 에 도구 이름으로 된 프로퍼티로 도구 스스로가 등록하게 된다.

WidgetTools.toolA = function(sandbox) {
  sandbox.toolA = {
    function1: function() {
      // function1 구현부
    },
    function2: function() {
      // function2 구현부
    },
  };
};

여기서 샌드박스의 역활은 샌드박스를 new로 선언하면서 해당 this안에 도구와 위젯을 가둬두는 것이다. 즉, 새로운 객체 안에 위젯과 도구를 함께 등록해서 사용할 수 있게 만든다. 이때 만들어진 객체는 모래밭의 경계가 되어 다른 어떤 것에도 영향을 미치지 않게 도와준다.
도구1(this), 도구2(this), ... 도구n(this), 위젯(this) 이렇게 순차대로 호출하면 위젯에서는 원하는 도구를 this.도구1 , this.도구2 이런식으로 활용할 수 있다.

decoration pattern

객체를 바꾸지 않고 그 기능을 늘리는 수법
기존 책임을 하는 api 객체는 그대로 놔두고 그 객체를 감싼 객체에 기능을 새로 넣자. 이 래퍼 객체에는 원 객체와 파라미터 개수 및 의미가 같은 메서드가 있는데 추가 할 기능만 자신이 맡고 물밑에서 실제로 처리하는 일은 자신이 감싼 원 객체에게 떠맡긴다.
실제로 상황에 따라 어떠한 특성 혹은 행동을 덧붙이는 패턴이다.
다양한 형태로 기능을 확장해야 하는 경우, 예를 들면 여러 종류의 단위 기능이 있고 이들을 조합해서 사용할 경우 장식자 패턴을 사용하면 장식자 개체에서 필요한 단위 기능을 하는 형식 개체를 포함을 시키는 것으로 이를 해결할 수있다.
단일 책임 원칙을 준수하면서 믿음성이 강화된 코드를 효과적으로 작성할 수 있다.

데코레이션 시나리오

컨퍼런스에서 참가자가 등록버튼을 눌러 등록하면 post로 참가자가 등록하게 된다.
하지만 이때, 신규 참가자 페이지에서 사용자를 계속 붙잡아 두면 안되겠고, post가 끝난 다음에 참가자 명단 페이지에 가서 확인하라고 하는것 또한 안된다.
post가 실패할 확률은 희박하다.
다음과 같이 하자
1. 새 레코드를 post 하기전, 대기 레코드(pendingPosts) 배열에 담는다.
2. post promise가 귀결되면 해당 레코드를 배열에서 들어낸다 ( 삭제 시킨다. ) 배열 splice
3. 그러는 동안 대기 레코드들을 get 결과에 덧붙인다. 이렇게 하면 참가자 명단 페이지에서 post 처리된 레코드를 바로 보여줄 수 있다. 대기 레코드들은 아직 DB에서 참가자 ID를 발급받지 못한 상태라 수정/삭제가 불가피 하지만, 어쨌든 그 사이에 적어도 이름을 명단에 보여주는 건 가능하다.
4. post 결과 참가자 id가 넘어오면 조금전 3번에서 get으로 덧붙인 해당 레코드에 집어넣고 수정/삭제할 수 있는 상태로 바뀐다.
5. 드물긴 하지만, post가 실패하면 에러 메시지를 띄우고 등록 실패한 참가자를 명단 페이지에서 지운다. 오류가 발생한 참가자가 명단에 잠시 머물렀다 해도 문제 될 일은 없다. 화면에서 id가 다시 넘어오기 전까지 수정/삭제를 할 수 없을 뿐이니까.

데코레이션 code

원 객체 ( baseWebApi )

// fake 모의체
fakeAttendeeWebApi = function() {
  "use strict";

  var attendees = []; // 가짜 데이터베이스 테이블

  return {
    //서버에 attendee를 POST 전송하는 척한다.
    //attendee 사본(마치 서버에서 새 버전을 조회해오는 것처럼 ) 으로
    // 귀결되는 프라미스를 반환하고 귀결 시점에 이 레코드에는
    // 데이터베이스에서 할당된 PK(attendeeId)가 들어있을 것이다..

    //프라미스를 버려야 하는 테스트라면 스파이를 이용하자.
    post: function post(attendee) {
      return new Promise(function(resolve, reject) {
        // 5밀리초에 불과하지만,
        // setTimeout은 프라미스 귀결을 다음 차례로 지연한다..
        setTimeout(function pretendPostingToServer() {
          var copyOfAttendee = attendee.copy();
          copyOfAttendee.setId(attendees.length + 1);
          attendees.push(copyOfAttendee);
          resolve(copyOfAttendee);
        }, 5);
      });
    },
    // 전체 참가자에 대한 프라미스를 반환한다..
    // 이 프라미스는 반드시 귀결되지만 , 필요하면 테스트 코드에서 스파이를 심을수도 있다..
    getAll: function getAll() {
      return new Promise(function(resolve, reject) {
        // setTimeout은 실제 조건을 흉내 내기 위해
        // post보다 지연시간이 짧다..
        setTimeout(function pretendToGetAllFromServer() {
          var copies = [];
          attendees.forEach(function(a) {
            copies.push(a.copy());
          });
          resolve(copies);
        }, 1);
      });
    },
  };
};

장식자

attendeeWebApiDecorator = function(baseWebApi) {
  "use strict";

  var self = this,
    // post 함수에 전달할 레코드
    // 호출 결과는 아직 귀결되지 않은 상태다.
    pendingPosts = [],
    messages = {
      postPending: "이 참가자에 대한 처리가 진행 중인 것 같습니다.",
    };

  //attendee에 해당하는 'posts' 원소를 반환하거나
  // 그런 원소가 없으면 -1을 반환한다..
  function indexOfPostForSameAttendee(posts, attendee) {
    var ix;
    for (ix = 0; ix < posts.length; ++ix) {
      if (posts[ix].isSamePersonAs(attendee)) {
        return ix;
      }
    }
    return -1;
  }

  return {
    post: function post(attendee) {
      if (indexOfPostForSameAttendee(pendingPosts, attendee) >= 0) {
        return Promise.reject(new Error(messages.postPending));
      }

      pendingPosts.push(attendee);

      return baseWebApi.post(attendee).then(
        function onPostSucceeded(attendeeWithId) {
          var ix = pendingPosts.indexOf(attendee);
          if (ix >= 0) {
            pendingPosts[ix].setId(attendeeWithId.getId());
            pendingPosts.splice(ix, 1);
          }

          return attendeeWithId;
        },
        function onPostFailed(reason) {
          var ix = pendingPosts.indexOf(attendee);
          if (ix >= 0) {
            pendingPosts.splice(ix, 1);
          }

          return Promise.reject(reason);
        }
      );
    },
    getAll: function getAll() {
      return baseWebApi.getAll().then(function(records) {
        pendingPosts.forEach(function(pending) {
          var ix = indexOfPostForSameAttendee(records, pending);
          if (ix < 0) {
            records.push(pending);
          }
        });
        return records;
      });
    },
    getMessages: function getMessages() {
      return messages;
    },
  };
};

데코레이션 정리

기존의 api 호출을 하는 객체를 사용한다면, post 호출후 어떤식으로든 완료가 되고 getAll로 그 리스트를 가져와야 하는 일련의 시간을 사용자가 기다리게 마련이다.
이런 경험을 높히기 위해서 기존 api 호출 하는 객체에 추가 기능을 래퍼 객체로 만들어 주었다.
여기서 래퍼는 post를 보내고 나서 바로 getAll에 post 보낸 정보를 덧대였고( id가 없는 상황 ) post가 끝나면 그 덧댄 객체에게 id를 setting 해주는 식이다.
기존 객체에서 발생하는 에러 및 성공을 잘 패스-스루(장식된 객체에서 -> 장식자 -> 호출부로의 전달) 해주는지 확인해야하고, 장식자의 고유 기능을 넣는다.
논리적으로 다음 단계는 장식자의 일반화 문제를 다뤄야 한다.
실제로 HTTP 의 PUT과 DELETE는 물론이고 연관된 POST GET 까지 캡슐화한 객체를 여럿 두고 구현한 애플리케이션도 있다. ( 예를 들어, 이미지 등록, 사용자 수정..등등의 여러 REST API) 모든 경우에 적용할 수 있게 장식자를 일반화 하려면 어떻게 해야하는가??? ( 현재는 baseWebApi가 post와 getAll이 있는 녀석들을 받아야 한다. )
공통의 기능을 상위 클래스 및 인터페이스로 일반화를 해보자.

Strategy pattern

전략 패턴은 특정 작업을 수행하는 다중 알고리즘, 즉 전략을 런타임 시 넣었다 뺐다 할 수 있는 모듈 단위로 나누기 위해 사용한다.
특정 작업을 수행하는 서로 다른 알고리즘(운수회사 교통편 예약)을 분리하고, 런타임 시점에 알고리즘, 즉 전략을 동적으로 지정할 수 있게 해주는 패턴
여기서 팩토리 패턴을 사용함으로써 테스트가 덜 복잡해지고 전략을 추가/삭제할 때도 실행 콘텍스트는(transportScheduler) 전혀 고칠 필요가 없다.

전략 시나리오

웹사이트에서 참가자는 자신이 선택한 택시 회사에 요청을 보내고 그 회사가 발급한 에약 확인번호를 돌려받는 식으로 콘퍼런스 행사장 교통편을 예약할 수 있다.
택시 회사에서는 웹사이트 대시보드를 보면서 예약 상황을 모니터링하고, 주최자 역시 회사별 이용 실적이 얼마나 되는지 확인할 수 있어야 한다.
운수회사 모듈 생성을 통틀어 관장하는 팩토리 함수를 하나 만드는게 좋을거 같다.
여기서 운수회사별 모듈이 바로 전략이다.

전략 code

transportScheduler = function(
  auditService /* 집계 서비스 */,
  transportCompanyFactory
) {
  "use strict";

  if (!auditService) {
    throw new Error(Conference.transportScheduler.messages.noAuditService);
  }

  if (!transportCompanyFactory) {
    throw new Error(Conference.transportScheduler.messages.noCompanyFactory);
  }

  return {
    scheduleTransportation: function scheduleTransportation(transportDetails) {
      if (!transportDetails) {
        throw new Error(Conference.transportScheduler.messages.noDetails);
      }
      var company;
      // 여기서 어떤 운수회사 모듈을 생성한다.
      company = transportCompanyFactory.create(transportDetails);

      // 여기서 운수회사는 schedulePickup 을 반드시 구현한다.
      return company
        .schedulePickup(transportDetails)
        .then(function successful(confirmation) {
          auditService.logReservation(transportDetails, confirmation);
          return confirmation;
        });
    },
  };
};

// 운수회사
redicabTransportCompany = function(httpService) {
  "use strict";

  var schedulePickupUrl = "http://redicab.com/schedulepickup";

  return {
    // RediCab사와 픽업 일정을 잡는다.
    // 이 회사 API로부터 채번된 확인 코드로 귀결되는 프라미스를 반환한다.
    schedulePickup: function schedulePicup(transportDetails) {
      var details = {
        passenger: transportDetails.passengerName,
        pickUp: "컨퍼런스 센터",
        pickUpTime: transportDetails.departureTime,
        dropOff: "공항",
        rateCode: "JavaScriptConference",
      };

      return httpService
        .post(schedulePickupUrl, details)
        .then(function resolve(confirmation) {
          return confirmation.confirmationCode;
        });
    },

    //픽업 정보를 전송할 url을 반환한다.
    getSchedulePickupUrl: function getSchedulePickupUrl() {
      return schedulePickupUrl;
    },
  };
};

Proxy pattern

프록시는 대리인이라는 뜻이다. 즉, 사용자가 원하는 행동을 하기 전에 한번 거쳐가는 단계라고 생각하면 된다.
좋은 프록시는 사용자의 요청을 캐싱하여 성능을 높일 수도 있고, 에러를 잡아낼 수도 있지만 나쁘게 사용한다면 사용자의 요청을 왜곡하여 다른 동작을 하도록 만들 수 있다.

주된용도

클라이언 사용 패턴에 따라 데이터를 미리가져온다.
실체에 클라이언트 요청이 과도하게 몰리지 않게 한다. ( ex. 디바운싱 프록시 : 수 밀리 초에 한번만 이벤트에 반응하도록 제한할 수 있다.)
클라이언트가 접근하면 안 되는 자원을 통제한다.
HTTP 요청 n 개를 하나로 묶어 n-1개 요청에 따른 고정 비용을 줄인다.

프록시 패턴 시나리오

콘퍼런스 참가자 명단에서 클릭하면 프로필 전체를 볼수있게 한다.
프로필 화면에는 사진이 적어도 하나 이상 등록되어 있어서 전체 프로필을 처음부터 죄다 끌어오고 싶지는 않다.
현재 페이지의 참가자 중 가장 접근 횟수가 많은 프로필만이라도 미리가져오는게 좋겠다.
시간이 지나면서 쌓인 프로필 클릭 횟수에 따라 누가 유명 인사인지 시스템이 알아서 학습하도록 놔두고 그 사람들 프로필만 선취하면 될거같다.

code

//attendeeProfileService(profileService) 함수로 참가자 배열(attendees)에서
//accessCount에 따라 가장 인기 있는 프로필부터 prefetchLimit개 만큼 선취하는 식으로
//참가자 프로필 접근을 관리한다.
Conference.attendeeProfileProxy = function(
  attendees,
  profileService,
  prefetchLimit
) {
  "use strict";

  var prefetched = {};

  function prefetch(attendeeId) {
    // 이놈이 진짜... getProfile 가져오는 놈...
    prefetched[attendeeId] = profileService.getProfile(attendeeId);
  }

  if (prefetchLimit > attendees.length) {
    prefetchLimit = attendees.length;
  }
  // 즉시 실행 함수로 감싸서 딱 한 번만 실행되도록
  // 그리고 새 변수 sortedAttendees가 외부 스코프에 의해 더렵혀지지 않게 한다...
  // 즉시 실행 함수도 prefetchAll 이라는 이름을 붙여 문서화 및 스택 추적 시 이정표로 삼는다..
  (function prefetchAll() {
    var ix,
      sortedAttendees = attendees.slice().sort(function byViews(a, b) {
        // 서버에서는 네트워크 효율 때문에 프로필 조회수가 업슨ㄴ 사람은 profileViews 프로퍼티를 전송하지 않는다.
        // 따라서 예외 처리를 해준다.
        return (b.profileViews || 0) - (a.profileViews || 0);
      });
    for (ix = 0; ix < prefetchLimit; ++ix) {
      prefetch(sortedAttendees[ix].attendeeId);
    }
  })();

  // 위에걸 한번 돌리고 나면... prefetched에 뭔가가 쌓인다.. 그게 뭐가 쌓이느냐.
  // 서버에서 내려주는 profileViews 값이 높은순위별로.. prefetchLimit 갯수만큼 쌓인다..
  // prefetced는 참가자의 id가 키 값이고 값은 진짜 getProfile ( 프로필 ) ..

  return {
    getProfile: function(attendeeId) {
      return prefetched[attendId] || profileService.getProfile(attendeeId);
    },
  };
};

chainable pattern

iterator pattern

mediator pattern (중재자 패턴)

중재자는 소통을 주도하고 이해 당사자를 이끌며, 각자의 이야기에 응답하고 다음단게로 나아간다.

중재자 패턴이란?

소프트웨어 설게에서 중재자 패턴은 문제를 회피하는 방법이다.
소프트웨어 시스템은 소통하는 코드를 줄일수록 오류 가능성이 적어진다.
서로 다른, 또는 유사한 일을 하는 협력자(colleague)들과 이들을 조직하여 전체 성과를 끌어내는 단일 중재자로 이루어진다.
가장 순수한 형태의 중재자는 별다른 비즈니스 로직 없이 협력자 사이의 움직임만 관장한다.

중재자 패턴 시나리오

노드망이 있고 여기에 봇(bot) 서너 개가 돌아다닌다.
플레이어(player) 2명은 이 봇을 빠른 속도로 모두 잡아 보드를 접수하면 게임은 끝난다.
협력자 각자의 역할은 다음과 같다.
- player: 연결된 다른 노드로 이동하면서 mediator에게 자신의 움직임을 알린다.
- bot: player와 같다.
- gameLogic: 게임 종료 시점을 결정하는 로직 등이 있다. '정규 공간'을 그리고 player와 bot을 배치한다. 이들을 브라우저에 표시하는 일은 svgDisplay의 몫이다.
- svgDisplay: svg 요소에 게임판을 그린다. 처음에 mediator에게 지령을 받고 게임판을 그리지만, 그 이후에 mediator와 다시 이야기를 주고받지는 않는다.
mediator의 역할
- gameLogic(player와 bot)과 svgDisplay를 인스턴스화하고 게임을 초기화한다.
- 방향키에 이벤트 리스너를 건다.
- player/bot이 자신의 움직임을 알리면, gameLogic/svgDisplay에게도 소식을 알리고 gameLogic이 종료를 선언하면 자신이 걸어둔 이벤트 리스너를 푼다.
- player가 bot을 잡게되면 직접 bot을 내쫒는게 아니라 mediator에게 귀띔만 한다. 그러면 mediator는 다시 gameLogic에 통보하고, gameLogic은 충돌 여부를 살펴보고 bot을 지운다.
- gameLogic이 화면을 직접 고치는 건 아니고 mediator에게 한 번 더 메시지로 알리면 svgDisplay가 bot을 삭제한다.

협력자 개발

player 객체는 게임판의 지리는 조금 알고 있지만, 게임이 언제 끝나는지, 다른 player는 몇 명인지, bot은 몇 개가 살아 돌아다니고 있는지 전혀 모른다. svg에 표시되고 있는 줄도 모른다.

var Game = Game || {};

Game.player = function player(mediator) {
  'use strict';

  var me;
  var node;
  var id = (Game.player.nextId === undefined? Game.player.nextId = 0 : ++Game.player.nextId); // 정적 변수 nextId
  var listenEvent = 'keydown';
  var elementWithKeydownAttached;
  // 첫 번째 플레이어는 1-4키를 쓴다(keycode: 49 - 52)
  // 두 번째 플레이어는 6-9키를 쓴다(keycode: 54 - 58)
  var keycodeForPath0 = id % 2 ? 54 : 49;

  function handleKeydown(e) {
    var pathIx = e.keycode - keycodeForPath0;
    if(keyIx >= 0 && pathIx < Game.pathIndex.count) {
      me.move(pathIx);
    }
  }

  var me = {
    getId: function() {
      return id;
    },
    setNode: function setNode(gameNode) {
      node = gameNode;
    },
    getNode: function getNode() {
      return node;
    },
    activate: function activate(elementForKeydown) {
      // 키가 눌렸을때의 해당 엘리먼트
      elementWithKeydownAttached = elementForKeydown;
      elementWithKeydownAttached.addEventListener(listenEvent, handleKeydown)
    },
    deactivate: function deactivate() {
      if(elementWithKeydownAttached) {
        elementWithKeydownAttached.removeEventListener(listenEvent, handleKeydown);
      }
    },
    move: function move(pathIndex) {
      // pathIndex로 주어진 경로를 따라 플레이어를 이동시켜본다.
      // 이동의 성공 여부를 true/false로 반환한다.
      if(node.getConnectedNode(pathIndex)) {
        me.setNode(node.getConnectedNode(pathIndex));
        mediator.onPlayerMoved(me);

        return true;
      }

      return false;
    }
  }

  return me;
}

중재자 인터페이스 분리

각 협력자들은 중재자의 특정 메서드를 호출한다. 이에 그에 맞는 중재자 인터페이스를 갖춰야 한다.
중재자 코드를 사용하는 커스터머들은 협력자들이고 협력자들에 맞춰서 중재자 구현을 짜는 것이 의존성 역전 원칙(Dependency Inversion Principle)이라 할 수 있다.
여기서는 중재자에게 규약을 정해서 협력자(커스터머)들이 사용하게 만들 수 있고 반대로, 협력자(커스터머)가 중재자 규약을 지니고 있고 중재자가 구현을 하도록 만들 수 있다.
전자의 경우에는 중재자가 변경된다면 규약까진 변경 될 순 있지만 그것을 사용하고 있는 협력자를 찾아서 전부 고쳐야 하는 문제가 있다.
후자의 경우에는 인터페이스를 사용하는 모듈마다(즉, 커스터머(협력자)) 규약을 적용해야 하므로 코드가 반복될 수 있는 문제가 있다.(DRY 원칙에 어긋)

중재자 개발

var Game = Game || {};

Game.mediator = function mediator() {
  'use strict';

  var logic;
  var display;
  var startTime;
  var svgElement = document.getElementById('gameSvg');

  function moveBotStartInLogicAndOnDisplay(bot) {
    logic.onMotMoveStart(bot);
    display.onBotMoveStart(bot);
  }

  var med = {
    startGame: function startGame() {
      logic.getPlayers().forEach(function (player) {
        player.activate(document.getElementById('gameInput'));
      });
      startTime = new Date();
    },
    // 플레이어가 이동하면 이 함수를 호출한다.
    onPlayerMoved: function onPlayerMoved(player) {
      logic.onPlayerMoved(player);
      display.onPlayerMoved(player);
    },
    // 봇이 이동하기 시작하면 이 함수를 호출한다.
    onBotMoveStart: function onBotMoveStart(bot) {
      moveBotStartInLogicAndOnDisplay(bot);
    },
    // 봇이 이동을 마치면 이 함수를 호출한다.
    onBotMoveEnd: function onBotMoveEnd(bot) {
      logic.onBotMoveEnd(bot);
    },
    // 봇이 잡히면 게임 로직이 이 함수를 호출한다.
    onBotHit: function onBotHit(bot) {
      bot.setNode(undefined);
      moveBotStartInLogicAndOnDisplay(bot);
    },
    // 게임 로직이 이 함수를 호출하여 게임을 끝낸다.
    endGame: function endGame() {
      var millisecondsToWin = new Date() - startTime;

      logic.getPlayers().forEach(function (player) {
        player.deactivate();
      });

      // 누가 이겼는지 디스플레이가 표시하기 전에
      // setTimeOut을 써서 마지막 봇을 삭제할 시간을 준다.
      setTimeout(function() {
        display.endGame(millisecondsToWin);
      }, 500)
    }
  }

  // mediator가 인스턴스화되면 두 협력자 gameLogic과 svgDisplay를 생성한다.
  // 그런 다음 gameLogic이 player와 bot을 만든다.
  var logic = Game.gameLogic(med, 6, 7);
  var display = Game.svgDisplay(med, svgElement, logic);

  return med;
}

player 협력자 코드는 다음과 같이 실행된다.

activate 메서드는 주어진 방향키를 누르면 알맞은 player의 move 메서드를 호출할 이벤트 리스너를 추가한다.
새 노드로 정상 이동하면 player.move가 mediator.onPlayerMoved 메서드를 호출한다.
이 메서드는 player의 이동 사실을 gameLogic과 svgDisplay에게 알린다.
마지막으로 gameLogic이 게임 종료를 선포한 후 mediator.endGame이 이벤트 리스너를 풀리기 전까지 2,3번 단계를 반복한다.

mediator의 주된 관심사는 자신이 몰라도 될 객체들 사이의 움직임을 조정하는 일이다.

observer pattern (관찰자 패턴)

한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성 하는 패턴
데이터의 변경이 발생했을 경우 상대 클래스나 객체에 의존하지 않으면서 데이터 변경을 통보하고자 할 때 유용
통보 해야할 대상 객체의 관리를 Subject 클래스와 그 대상들이 꼭 구현을 해야할 observer 인터페이스로 일반화 한다.
쉽게 여기서 통보 해야할 대상 객체는 구독자 라고 하고 그 구독자들은 update 함수를 구현해야할 약속을 이행하기 위한 observer 인터페이스를 갖는다. 또한 대상 객체의 관리를 하는 Subject는 신문사라고 생각 할 수 있다.

관찰차 패턴이란?

관찰할 객체 (대상자)
대상자를 지켜보는 객체 (관찰자)

대상자는 관찰자에게 다음 세 기능을 반드시 제공한다.

관찰자가 알림을 받을 수 있게 자신을 등록하는 기능
관찰자가 알림을 그만 받도록 자신을 등록 해지하는 기능
대상자가 관찰자에게 업데이트를 알리는 기능
관찰자는 대상자가 변경 사실을 자신에게 알려줄 때 호출할 메서드를 건내준다.

관찰자 패턴 시나리오

컨퍼런스 주최자는 참가자 등록 현황을 브라우저 새로 고침 없이 다음과 같이 두 가지 형태로 조회하고 싶다.

총 등록자 인원수
최근 등록을 마친 10인 명단

여기서는 신규 등록자를 폴링하는 전용 모듈을 따로 두고 사용자에게 정보를 보여주는 모듈 2개를 업데이트하는 식으로 개발한다. 폴링 모듈이 대상자고 화면 표시 모듈 2개가 관찰자가 된다.

관찰자 패턴 대상자 코드

// 대상자 코드
var Conference = Conference || {};

Conference.recentRegisterationsService = function (registrationsService) {
  'use strict';

  var registrationsObservers = [];
  var service = {
    // 관찰자 추가
    addObserver: function addObserver(observer) {
      // ...
      // observer 는 객체
    },
    // 관찰자 목록에서 관찰자를 삭제한다.
    removeObserver: function removeObserver() {
      var index = registrationsObservers.indexOf(observer);
      if(index >= 0) {
        registrationsObservers.splice(index,1)
      }
    },
    // 관찰자 모두 삭제
    clearObservers: function clearObservers() {
      registrationsObservers = [];
    },
    // 주어진 관찰자가 등록되어 있으면 true, 그렇지 않으면 false 반환
    hasObserver: function hasObserver(observer) {
      return registrationsObservers.indexOf(observer) >= 0;
    },
    // 등록된 관찰자들이 각자 제공한 update 메서드 실행
    updateObserver: function updateObserver(newAttendee) {
      registrationsObservers.forEach(function executeObserver(observer) {
        observer.update(newAttendee);
      })
    },
    // 폴링을 멈춘다. 한번 멈춘 다음에는 다시 시작하지 않는다.
    stopPolling: function stopPolling() {
      if(pollingProcess) {
        clearInterval(pollingProcess);
        pollingProcess = false;
      }
    }, 
  }

  // 서버를 호출, 최종 조회 시점 이후로 등록한 참가자를 조회하여
  // 참가자 배열의 프라미스를 반환한다.
  var getNewAttendees = function getNewAttendees() {
    return new Promise(function (resolve, reject) {
      // ...
      resolve([])
    })
  }

  // 바로 polling 시작
  var pollingProcess = setInterval(function pollForNewAttendees() {
    getNewAttendees().then(function processNewAttendees(newAttendees) {
      newAttendees.forEach(function updateWithNewAttendee(newAttendee) {
        // recentRegisterationsService는 자신을 지켜보는 관찰자 모두 attendee 객체를 인자로 받는 update 함수를 표출한다고 전제한다.
        service.updateObservers(newAttendee);
      })
    })
  }, 15000)

  return service;
}

관찰자 패턴의 관찰자 테스트

totalAttendeeCount 인스턴스가 자신을 recentRegistrationsService 인스턴스의 관찰자로 등록한다.
getCount 메서드는 모듈 함수에 준, 초기 인원수를 반환한다.
update 메서드를 실행하면 getCount가 반환한 값을 하나 늘린다.

관찰자 패턴의 관찰자 코드

var Conference = Conference || {};

// recentRegistrationsService 대상자
Conference.totalAttendeeCount = function(initialCount, recentRegistrationsService) { 
  'use strict';

  var currentCount = initialCount;
  var registrations = recentRegistrationsService;
  var render = function render() {
    // 현재 인원수를 DOM에 렌더링한다.
  }

  var module = {
    // UI에 표시된 총 참가자 인원수를 반환한다.
    getCount: function getCount() {},
    // 총 참가자 인원수를 늘린다.
    update: function update(newAttendee) {
      currentCount++;
      render();
    }
  }

  // 모듈을 recentRegistrationsService의 관찰자로 추가한다.
  registrations.addObserver(module);

  return module;
}

pubSub pattern

builder pattern

Javascript OOP Inherit

Sun, 02 Aug 2020 10:00:03 GMT

상속

ECMAScript에서는 구현 상속만 지원하며 구현 상속은 대개 프로토타입 체인을 통해 이루어집니다.

포로토타입 체인

프로토타입 체인의 기본 아이디어는 프로토 타입 개념을 이용해 두 가지 참조 타입 사이에서 프로퍼티와 메서드를 상속한다는 것입니다.
모든 생성자에는 생성자 자신을 가리키는 프로토타입 객체(prototype)가 있으며 인스턴스는 프로토타입을 가리키는 내부 포인터(__proto__)가 있습니다. - 그렇다면 프로토타입이 사실 다른 타입의 인스턴스라면 어떨까요? 이런 경우에는 프로토타입(A) 자체에 다른 프로토타입(B)을 가리키는 포인터가 있을 것이며, B에는 또 다른 생성자를 가리키는 포인터가 있을 겁니다.

function SuperType() {
  this.property = true;
}

SuperType.prototype.getSuperValue = function() {
  return this.property;
};

function SubType() {
  this.subproperty = false;
}

// inherit from SuperType
SubType.prototype = new SuperType();

// 새 프로토타입은 SuperType의 인스턴스이므로 SuperType 인스턴스가 가질 프로퍼티와 메서드 외에 SuperType의 프로토타입을 가리키는 포인터도 가집니다.
SubType.prototype.getSubValue = function() {
  return this.subproperty;
};

var instance = new SubType();
console.log(instance.getSuperValue()); //true

SubType의 기본 프로토타입 대신 새 프로토타입(new SuperType())이 할당되었습니다.
새 프로토타입은 SuperType의 인스턴스이므로 SuperType 인스턴스가 가질 프로퍼티와 메서드 외에 SuperType의 프로토타입을 가리키는 포인터도 가집니다.
즉, instance 변수는 SubType.prototype을 가리키고 Subtype.prototype은 Super.prototype을 가리킵니다.
getSuperValue() 메서드는 SuperType.prototype 객체에 남지만 property는 SubType.prototype에 존재함을 눈여겨 보십시오.
이렇게 되는 것은 getSuperValue()이 프로토타입 메서드이며 property는 인스턴스 프로퍼티이기 때문입니다. SubType.prototype은 SuperType의 인스턴스 이므로 property는 SubType.prototype에 저장됩니다.
SubType.prototype의 constructor 프로퍼티를 덮어썼으므로 instance.construcor가 SuperType을 가리키는 점도 살펴보십시오.
instance.getSuperValue()를 호출하면 3단계로 검색합니다. 1) 인스턴스에서, 2) SubType.prototype에서 3) SuperType.prototype에서 검색하며 3단계에서 메서드를 찾습니다.

기본 프로토타입

모든 참조 타입은 기본적으로 프로토타입 체닝르 통해 Object를 상속합니다.
함수의 기본 프로토타입은 Object의 인스턴스이므로 함수의 내부 프로토타입 포인터는 Object.prototype을 가리킵니다.

function Supertype() {}
function Object() {}

Object.prototype.constructor = Object;
Supertype.prototype.__proto__ === Object.prototype;

프로토타입과 인스턴스 사이의 관계

프로토타입과 인스턴스 사이의 관계는 두가지 방법으로 알아볼 수 있습니다.
- 첫번째 방법은 instanceof 연산자 입니다. instanceof 연산자는 다음과 같이 인스턴스 생성자가 프로토타입 체인에 존재할때 true를 반환합니다.

console.log(instance instanceof Object); //true
console.log(instance instanceof SuperType); //true
console.log(instance instanceof SubType); //true

두번째 방법은 isPrototypeOf() 메서드입니다. 체인에 존재하는 각 프로토타입은 모두 isPrototypeOf() 메서드를 호출할 수 있는데 이 메서드는 다음과 같이 체인에 존재하는 인스턴스에서 true를 반환합니다.

console.log(Object.prototype.isPrototypeOf(instance)); //true
console.log(SuperType.prototype.isPrototypeOf(instance)); //true
console.log(SubType.prototype.isPrototypeOf(instance)); //true

메서드

하위타입(subtype)에서 상위 타입(supertype)의 메서드를 오버라이드(메서드 덮어쓰기)하거나 상위 타입에 존재하지 않는 메서드를 정의해야 할 때가 많습니다. 이렇게 하려면 반드시 프로토타입이 할당된 다음 필요한 메서드를 프로토타입에 추가해야 합니다.
아래 예제에서 중요한 점은 두 메서드가 모두 프로토타입이 SuperType의 인스턴스로 할당된 다음 정의되었다는 점.

function SuperType() {
  this.property = true;
}

SuperType.prototype.getSuperValue = function() {
  return this.property;
};

function SubType() {
  this.subproperty = false;
}

//inherit from SuperType
SubType.prototype = new SuperType();

//new method
SubType.prototype.getSubValue = function() {
  return this.subproperty;
};

//override existing method
SubType.prototype.getSuperValue = function() {
  return false;
};

var instance = new SubType();
console.log(instance.getSuperValue()); //false

첫번째 메서드인 getSubValue()는 SubType에 추가한 메서드입니다. 두번째 메서드인 getSuperVlaue()는 프로토타입 체인에 이미 존재하지만 instance에서 기존 메서드를 가렸습니다.
중요한점은 객체 리터럴을 써서 프로토타입 메서드를 만들면 체인을 덮어쓰는 결과가 되므로 프로토타입과 체인과 함께 사용할 수는 없습니다.

function SuperType() {
  this.property = true;
}
SuperType.prototype.getSuperValue = function() {
  return this.property;
};
function SubType() {
  this.subproperty = false;
}
//inherit from SuperType
SubType.prototype = new SuperType();

// 메서드를 추가하려는 시도 앞줄을 무효화 합니다.
SubType.prototype = {
  getSubValue: function() {
    return this.subproperty;
  },
  someOtherMethod: function() {
    return false;
  },
};
var instance = new SubType();
console.log(instance.getSuperValue()); //error!

이렇게 하면 이제 프로토타입에는 SuperType의 인스턴스가 아니라 Object의 인스턴스가 들어있으므로 프로토타입 체인이 끊어져서 SubType과 SuperType 사이에는 아무 관계도 없습니다.

프로토타입 체인의 문제

프로토타입 체인은 강력한 상속 방법이지만 문제도 있습니다. 주요문제는 참조값을 포함한 프로토타입과 관련이 있습니다.
프로토타입 프로퍼티에 들어있는 참조 값이 모든 인스턴스에서 공유된다는 사실을 상기하십시오.
이 때문에 프로퍼티는 일반적으로 프로토타입 대신 생성자에 정의합니다. 프로토타입으로 상속을 구현하면 프로토타입이 다른 타입의 인스턴스가 되므로 처음에 인스턴스 프로퍼티였던 것들이 프로토타입 프로퍼티로 바뀝니다. (즉, 공유를 안하려고 한 속성(프로퍼티)들이 프로토타입 체인을 이용함으로써 공유하게 된다. )

function SuperType() {
  this.colors = ["red", "blue", "green"];
}
// 공유를 안하려고 만들었던 color배열..
function SubType() {}

//inherit from SuperType
SubType.prototype = new SuperType();
// 서브타입의 프로토타입에 새로운 생성자 정의
// 객체가 만들어지고 SuperType()에 있던 color값은 새로운 객체 안에 속하게 되고
// 해당 객체를 SubType 프로토타입에 반환.
// SubType 프로토타입은 SubType의 인스턴스에 모두 공유하는 성질.
// 즉, 공유를 안하려고 만든 color배열을 SubType인스턴스에 모두 공유하는 상황이 생김

var instance1 = new SubType();
instance1.colors.push("black");
console.log(instance1.colors); //"red,blue,green,black"

var instance2 = new SubType();
console.log(instance2.colors); //"red,blue,green,black"

결국 SubType의 모든 인스턴스에서 color 프로퍼티를 공유하게 되어 instance1.colors를 수정하면 instance2.colors 에도 반영이 됩니다. - 두번째 문제는 하위 타입 인스턴스를 만들 때 상위 타입생성자에 매개변수를 전달할 방법은 없다.

생성자 훔치기

기본 아이디어는 매우 단순합니다. 하위타입 생성자 안에서 상위 타입 생성자를 호출하는 겁니다. 함수는 단순히 코드를 특정 컨텍스트에서 실행하는 객체일 뿐임을 염두에 두면 다음과 같이 새로 생성한 객체에서 apply()와 call() 메서드를 통해 생성자를 실행할 수 있음이 이해될것입니다.

function SuperType() {
  this.colors = ["red", "blue", "green"];
}

function SubType() {
  //inherit from SuperType
  SuperType.call(this);
}

var instance1 = new SubType();
instance1.colors.push("black");
console.log(instance1.colors); //"red,blue,green,black"

var instance2 = new SubType();
console.log(instance2.colors); //"red,blue,green"

이 코드는 SuperType() 함수에 들어있는 객체 초기화 코드 전체를 SubType 객체에서 실행하는 효과가 있습니다. 결과적으로 모든 인스턴스가 자신만의 colors 프로퍼티를 갖게 됩니다.

매개변수 전달

생성자 훔치기 패턴은 하위 타입의 생성자 안에서 상위 타입의 생성자에 매개변수를 전달할 수 있는데 이는 생성자 훔치기 패턴이 프로토타입 체인보다 나은점 중 하나입니다.

function SuperType(name) {
  this.name = name;
}

function SubType() {
  //inherit from SuperType passing in an argument
  SuperType.call(this, "Nicholas");

  //instance property
  this.age = 29;
}

var instance = new SubType();
console.log(instance.name); //"Nicholas";
console.log(instance.age); //29

이 코드에서 SuperType 생성자는 매개변수로 name 하나를 받고 단순히 프로퍼티에 할당하기만 합니다. SubType생성자 내에서 SuperType 생성자를 호출할때 값을 전달할 수 있는데, 이는 SubType인스턴스의 name 프로퍼티를 지정하는 결과가 됩니다.

생성자 훔치기 패턴의 문제

생성자 훔치기 패턴만 사용하면 커스텀 타입에 생성자 패턴을 쓸때와 같은 문제가 발생됩니다. 메서드를 생성자 내부에서만 정의해야 하므로 함수 재사용이 불가능해집니다. 게다가 상위 타입의 프로토타입에 정의된 메서드는 하위타입에서 접근할 수 없는 문제도 있습니다.

조합상속

조합상속은 프로토타입 체인과 생성자 훔치기 패턴을 조합해 두 패턴의 장점만을 취하려는 접근법입니다. 기본 아이디어는 프로토타입 체인을 써서 프로토타입에 존재하는 프로퍼티와 메서드를 상속하고 생성자 훔치기 패턴으로 인스턴스 프로퍼티를 상속하는 것입니다. 이렇게 하면 프로토타입에 메서드를 정의해서 함수를 재사용할 수 있고 각 인스턴스가 고유한 프로퍼티를 가질 수도 있습니다.

function SuperType(name) {
  this.name = name;
  this.colors = ["red", "blue", "green"];
}

SuperType.prototype.sayName = function() {
  console.log(this.name);
};

function SubType(name, age) {
  SuperType.call(this, name);
  this.age = age;
}

SubType.prototype = new SuperType();
SubType.prototype.sayAge = function() {
  console.log(this.age);
};

var instance1 = new SubType("Nicholas", 29);
instance1.colors.push("black");
console.log(instance1.colors); //"red,blue,green,black"
instance1.sayName(); //"Nicholas";
instance1.sayAge(); //29

var instance2 = new SubType("Greg", 27);
console.log(instance2.colors); //"red,blue,green"
instance2.sayName(); //"Greg";
instance2.sayAge(); //27

프로토타입 체인과 생성자 훔치기 패턴의 단점을 모두 해결한 조함상속은 자바스크립트에서 가장 자주 쓰이는 상속 패턴입니다. 조합상속은 instanceOf()와 isPrototypeOf()에서도 올바른 결과를 반환합니다.

프로토타입 상속

이 방법은 프로토타입을 써서 새 객체를 생성할 때 반드시 커스텀 타입을 정의할 필요는 없다는 데서 출발합니다. 크록포드가 소개한 함수는 다음과 같습니다.

function object(o) {
  function F() {}
  F.prototype = o;
  return new F();
}

object() 함수는 임시 생성자를 만들어 주어진 객체(매개변수 o)를 생성자의 프로토타입으로 할당한 다음 임시 생성자의 인스턴스를 반환합니다. 요약하면 object()는 주어진 객체의 사본 역할을 합니다.

var person = {
  name: "Nicholas",
  friends: ["Shelby", "Court", "Van"],
};

var anotherPerson = object(person);
anotherPerson.name = "Greg";
anotherPerson.friends.push("Rob");

var yetAnotherPerson = object(person);
yetAnotherPerson.name = "Linda";
yetAnotherPerson.friends.push("Barbie");

console.log(person.friends); // "Shelby,Court,Van,Rob,Barbie"

이 방법에서는 일단 다른 객체의 기반이 될 객체를 만듭니다. 기반 객체를 object()에 넘긴다음 결과 객체를 적절히 수정해야 합니다. 이 예제에서는 person 객체가 기반 객체이므로 object()함수에 넘겨서 새 객체를 반환받았습니다. 새 객체의 프로토타입은 person입니다.
ECMAScript 5판은 프로토타입 상속의 개념을 공식적으로 수용하여 Object.create() 메서드를 추가했습니다. 이 메서드는 매개변수를 두개 받는데 하나는 다른객체의 프로토타입이 될 객체이며, 옵션인 다른 하나는 새 객체에 추가할 프로퍼티를 담은 객체입니다. 매개변수를 하나 쓰면 Object.creat()는 object() 메서드와 똑같이 동작합니다.

var person = {
  name: "Nicholas",
  friends: ["Shelby", "Court", "Van"],
};

var anotherPerson = Object.create(person);
anotherPerson.name = "Greg";
anotherPerson.friends.push("Rob");

var yetAnotherPerson = Object.create(person);
yetAnotherPerson.name = "Linda";
yetAnotherPerson.friends.push("Barbie");

console.log(person.friends); // "Shelby,Court,Van,Rob,Barbie"

Object.create()의 두번째 매개변수는 Object.defineProperties() 의 두번째 매개변수와 같은 형식입니다. 즉 추가할 프로퍼티마다 서술자와 함께 정의하는 형태입니다. 이런식으로 추가한 프로퍼티는 모두 프로토타입 객체에 있는 같은 이름의 프로퍼티를 가립니다.

var person = {
  name: "Nicholas",
  friends: ["Shelby", "Court", "Van"],
};

var anotherPerson = Object.create(person, {
  name: {
    value: "Greg",
  },
});

console.log(anotherPerson.name); // "Greg"

프로토타입 상속으로 만든 객체는 다른 객체와 비슷하게 동작하지만 생성자를 다 따로 만들 필요는 없다는 점에서 매우 유용합니다.
프로토타입 패턴과 마찬가지로 참조 값을 포함하는 프로퍼티들은 모두 그 값을 공유함을 유념하십시오.

기생 상속

기생상속이란 개념은 프로토타입 상속과 밀접히 연관된, 인기있는 패턴이다.
기본 아이디어는 기생 생성자나 팩터리 패턴과 비슷합니다. 상속을 담당할 함수를 만들고, 어떤 식으로든 객체를 확장해서 반환한다는 겁니다. 기생 상속 패턴은 다음과 같습니다.

function createAnother(original) {
  var clone = object(original);

  clone.sayHi = function() {
    alert("hi");
  };

  return clone;
}

기반 객체 original을 object() 함수에 넘긴 결과를 clone에 할당합니다. 다음으로 clone 객체에 sayHi()라는 메서드를 추가합니다. 마지막으로 객체를 반환합니다. 다음과 같이 활용합니다.

var person = {
  name: "Nicholas",
  friend: ["Shelby", "Court", "Van"],
};

var anotherPerson = creatAnother(person);
anotherPerson.sayHi(); // "hi"

기생 상속 패턴은 객체를 주로 고려할 때 사용할 패턴이지 커스텀 타입과 생성자에 어울리는 패턴은 아닙니다.
기생 상속에 꼭 object() 메서드가 필요한 건 아닙니다. 객체를 반환하는 함수는 모두 이 패턴에 쓸 수 있습니다.

기생 조합 상속

조합 상속은 자바스크립트에서 가장 자주 쓰이는 상속 패턴이지만 비효율적인 면도 있습니다.
이 패턴에서 가장 비효율적인 부분은 상위 타입 생성자가 항상 두 번 호출된다는 점입니다. 한 번은 하위 타입의 프로토타입을 생성하기 위해, 다른 한번은 하위 타입 생성자 내부에서 입니다.
하위 타입의 프로토타입은 상위 타입객체의 인스턴스 프로퍼티를 모두 상속하는데, 하위 타입생성자가 실행되는 순간 이를 모두 덮어쓰므로 별 의미가 없습니다.

// 조합 상속 예제
function SuperType(name) {
  this.name = name;
  this.colors = ["red", "blue", "green"];
}

SuperType.prototype.sayName = function() {
  console.log(this.name);
};

function SubType(name, age) {
  SuperType.call(this, name); // SuperType()을 두 번째 호출 (1)
  this.age = age;
}

SubType.prototpye = new SuperType(); //SuperType()을 처음 호출
SubType.prototype.constructor = SubType;
SubType.prototype.sayAge = function() {
  alert(this.age);
};

(1) 표시한 부분은 SuperType 생성자가 실행되는 부분이다. 이 코드가 실행되면 SubTpye.prototype 에는 name과 colors 두 가지 프로퍼티가 남습니다. 이 둘은 SuperType의 인스턴스 포로퍼티였지만 이제는 SubType의 프로토타입에 존재합니다. SubType 생성자를 호출하면 SuperType 생성자 역시 호출되면서 인스턴스 프로퍼티 name과 color를 새 객체에 만드는데 이들은 프로토타입에 존재하는 프로퍼티를 가립니다.
이런 문제를 해결 할 수 있는 기본적인 아이디어는 하위타입의 프로토타입을 할당하기 위해 상위 타입의 생성자를 호출할 필요는 없습니다. 필요한건 상위 타입의 프로토타입 뿐입니다. 간단히 말해 기생 상속을 써서 상위 타입의 프로토타입으로부터 상속한 다음 결과를 하위 타입의 프로토타입에 할당합니다. 기생 조합 상속의 기본 패턴은 다음과 같습니다.

function inheritPrototype(subType, superType) {
  var prototype = object(superType.prototype); //create object
  prototype.constructor = subType; //augment object
  subType.prototype = prototype; //assign object
}

함수 내부에서 일어나는 첫 단계는 상위 타입의 프로토타입을 복제하는 겁니다.
다음에는 constructor 프로퍼티를 prototype에 할당해서 프로토타입을 덮어쓸 때 기본 constructor 프로퍼티가 사라지는 현상에 대비합니다.
마지막으로 하위 타입의 프로토타입에 새로 생성한 객체를 할당합니다.

function object(o) {
  function F() {}
  F.prototype = o;
  return new F();
}

function inheritPrototype(subType, superType) {
  var prototype = object(superType.prototype); //create object
  prototype.constructor = subType; //augment object
  subType.prototype = prototype; //assign object
}

function SuperType(name) {
  this.name = name;
  this.colors = ["red", "blue", "green"];
}

SuperType.prototype.sayName = function() {
  console.log(this.name);
};

function SubType(name, age) {
  SuperType.call(this, name);
  this.age = age;
}

inheritPrototype(SubType, SuperType);

SubType.prototype.sayAge = function() {
  console.log(this.age);
};

var instance1 = new SubType("Nicholas", 29);
instance1.colors.push("black");
console.log(instance1.colors); //"red,blue,green,black"
instance1.sayName(); //"Nicholas";
instance1.sayAge(); //29

var instance2 = new SubType("Greg", 27);
console.log(instance2.colors); //"red,blue,green"
instance2.sayName(); //"Greg";
instance2.sayAge(); //27

해당 참조 타입의 인스턴스가 가져야할 프로퍼티와 메서드를 담고 있는 객체 SuperType.prototype 를 가지고 객체를 새롭게 하나 만들어서 subType.prototype을 할당합니다.
인스턴스 프로토타입에는 SuperType.prototype을 넣어서 결국 subType.prototype이 SuperType.prototype을 가리키게 만드는 기법입니다.
이 예제는 SuperType 생성자를 단 한 번만 호출하므로 SubType.prototype 에 불필요하고 사용하지 않는 프로퍼티를 만들지 않는점에서 효과적입니다. 기생 조합 상속은 참조 타입에서 가장 효율적인 상속 패러다임으로 평가 받습니다.
프로토타입 체인이 온전히 유지되므로 instanceof 와 isPrototypeOf() 메서드도 정상 작동합니다.

Javascript OOP Object

Sat, 01 Aug 2020 10:00:03 GMT

이 내용은 프론트엔드 개발자를 위한 자바스크립트 프로그래밍을 읽고 정리한 내용입니다.

객체에 대한 이해

객체를 만드는 방법은 간단한 방법은 Object 인스턴스를 만들고 여기에 프로퍼티와 메서드를 추가하는 방법입니다.
객체를 만드는 가장 많이 쓰이는 패턴은 객체 리터럴 패턴이 더 많이 쓰입니다.

var person = {
  name: "merlin",
  age: 29,
  sayName: function() {
    console.log(this.name);
  },
};

프로퍼티 타입

프로퍼티에는 데이터 프로퍼티와 접근자 프로퍼티 두 가지 타입이 있습니다.

데이터 프로퍼티

데이터 프로퍼티에는 그 행동을 설명하는 네가지 속성이 있습니다.
- Configurable : 당 프로퍼티가 delete를 통해 삭제하거나, 프로퍼티의 속성을 바꾸거나, 접근자 프로퍼티로 변환할 수 있음을 나타냅니다. 이전 예제처럼 객체에 직접 정의한 모든 프로퍼티에서 이 속성은 기본적으로 true 입니다.
- Enumerable : for-in 루프에서 해당 프로퍼티를 반환함을 나타냅니다.
- Writable : 프로퍼티의 값을 바꿀 수 있음을 나타냅니다.
- Value : 프로퍼티의 실제 데이터 값을 포함합니다. 프로퍼티의 값을 읽는 위치이며 새로운 값을 쓰는 위치 입니다. 이 속성의 기본 값은 undefined 입니다.
기본 프로퍼티 속성을 바꾸려면 ECMAScript 5판의 Object.defineProperty() 메서드를 사용해야 합니다.
위 메서드는 객체, 프로퍼티 이름, 서술자(descriptor) 객체 세 가지를 매개변수로 받습니다.
서술자 객체에는 configurable, enumerable, writeable, value 네 가지 프로퍼티가 있습니다.

// name 을 읽기 전용 프로퍼티를 만들고 그 값을 "Nicholas" 로 지정합니다.
// 이 프로퍼티 값은 바꿀 수 없으며, 새로운 값을 할당하려 시도하면 스트릭트 모드가 아닐 때는 무시되고
// 스트릭트 모드에서는 에러가 발생합니다.
var person = {};

Object.defineProperty(person, "name", {
  writable: false,
  value: "Nicholas",
});

console.log(person.name);
person.name = "Michael";
console.log(person.name);

같은 프로퍼티에서 Object.defineProperty()를 여러 번 호출할 수는 있지만, 일단 configurable을 false로 지정하면 제한이 생깁니다.
Object.defineProperty()를 호출할때 configurable, enumerable, writable 의 값을 따로 명시하지 않는다면 기본 값은 false입니다.
IE8에서는 제대로 구현되지 않았으므로 이 브라우저에서는 사용하지 않아야 합니다.

접근자 프로퍼티

접근자 프로퍼티에는 데이터 값이 들어 있지 않고 대신 getter함수와 setter 함수로 구성됩니다. 프로퍼티의 값을 getter/setter 메서드로 대체할 수 있다.
접근자 프로퍼티를 읽을 때는 getter 함수가 호출되며 유효한 값을 반환할 책임은 이 함수에 있습니다. 접근자 프로퍼티에 쓰기 작업을 할 때는 새로운 값과 함께 함수를 호출하며 이 함수가 데이터를 어떻게 사용할지 결정합니다.
접근자 프로퍼티에는 네가지 속성이 있습니다.
- Configurable : 해당 프로퍼티가 delete를 통해 삭제하거나, 프로퍼티의 속성을 바꾸거나, 접근자 프로퍼티로 변환할 수 있음을 나타냅니다. 이전 예제처럼 객체에 직접 정의한 모든 프로퍼티에서 이 속성은 기본적으로 true 입니다.
- Enumerable : for-in 루프에서 해당 프로퍼티를 반환함을 나타냅니다.
- Get : 프로퍼티를 읽을 때 호출할 함수입니다. 기본값은 undefined입니다.
- Set : 프로퍼티를 바꿀 때 호출할 함수입니다. 기본값은 undefined입니다.

var book = {
  _year: 2004,
  edition: 1,
};

Object.defineProperty(book, "year", {
  get: function() {
    return this._year;
  },

  set: function(newValue) {
    if (newValue > 2004) {
      this._year = newValue;
      this.edition += newValue - 2004;
    }
  },
});

book.year = 2005;
console.log(book.edition); //2

getter 함수만 지정하면 해당 프로퍼티는 읽기 전용이 됩니다.
setter만 지정된 프로퍼티를 읽으려 하면 스트릭트 모드가 아닐때는 undefined를 반환하며 스트릭트 모드에서는 에러가 발생합니다.

다중 프로퍼티 정의

객체에서 프로퍼티 여러 개를 동시에 수정해야 할 가능성이 높으므로 ECMAScript 5판에서는 Object.defineProperties() 메서드를 제공합니다.
매개변수는 프로퍼티를 추가하거나 수정할 객체, 그리고 프로퍼티 이름이 추가 및 수정할 프로퍼티 이름과 대응하는 객체 두 가지 입니다.

var book = {};

Object.defineProperties(book, {
  _year: {
    value: 2004,
  },
  edition: {
    value: 1,
  },
  year: {
    get: function() {
      return this._year;
    },

    set: function(newValue) {
      if (newValue > 2004) {
        this._year = newValue;
        this.edition += newValue - 2004;
      }
    },
  },
});

book.year = 2005;
console.log(book.edition); //2

프로퍼티 속성 읽기

ECMAScript 5의 Object.getOwnPropertyDescriptor() 메서드를 이용해 원하는 프로퍼티의 서술자(descriptor) 객체의 프로퍼티를 읽을 수 있습니다.
Object.getOwnPropertyDescriptor() 메서드는 읽어올 프로퍼티가 포함된 객체, 서술자를 가져올 프로퍼티 이름 두가지 매개변수를 받습니다.

// 위 코드 book 객체가 있다고 가정했을때.

var descriptor = Object.getOwnPropertyDescriptor(book, "_year");
console.log(descriptor.value); //2004
console.log(descriptor.configurable); //false
console.log(typeof descriptor.get); //"undefined"

var descriptor = Object.getOwnPropertyDescriptor(book, "year");
console.log(descriptor.value); //undefined
console.log(descriptor.enumerable); //false
console.log(typeof descriptor.get); //"function"

객체 생성

팩터리 패턴

팩터리 패턴은 특정 객체를 생성하는 과정을 추상화(구체적으로 만드는 구상화의 반대말입니다. 같은 일을 하는 코드에서 공통점을 모아 함수를 만드는 것이 추상화의 좋은 예입니다.)하는 것으로, 소프트웨어 공학에서는 잘 알려진 디자인 패턴입니다.

function createPerson(name, age, job) {
  var o = new Object();
  o.name = name;
  o.age = age;
  o.job = job;
  o.sayName = function() {
    console.log(this.name);
  };

  return o;
}

var person1 = createPerson("Nicholas", 29, "Software Engineer");
var person2 = createPerson("Greg", 27, "Doctor");

person1.sayName(); //"Nicholas"
person2.sayName(); //"Greg"

다양한 매개변수를 가지고 이 함수를 몇 번이든 호출해도 항상 프로퍼티 세 개와 메서드 한개를 가진 객체를 반환합니다.
비슷한 객체를 여러 개 만들 때의 코드 중복 문제는 해결할 수 있지만 생성한 객체가 어떤 타입인지 알 수 없다는 문제는 해결되지 않습니다. (생성된 객체의 constructor 로 어떤 생성자를 이용했는지 알 수가 없다는 뜻.)

생성자 패턴

특정한 타입의 객체를 만드는데 쓰입니다.
커스텀 생성자를 만들어서 원하는 타입의 객체에 필요한 프로퍼티와 메서드를 직접 정의할 수 있습니다.

function Person(name, age, job) {
  this.name = name;
  this.age = age;
  this.job = job;

  this.sayName = function() {
    console.log(this.name);
  };
}

var person1 = new Person("Nicholas", 29, "Software Engineer");
var person2 = new Person("Greg", 27, "Doctor");

위 코드는 다음과 같은 특징이 있습니다.
- 명시적으로 객체를 생성하지 않습니다.
- 프로퍼티와 메서드는 this 객체에 직접적으로 할당 됩니다.
- return 문이 없습니다.
Person의 새 인스턴스를 만들 때는 new 연산자를 사용합니다. 생성자를 이런식으로 호출하면 내부적으로는 다음과 같은 과정이 이루어집니다.
- 객체를 생성합니다.
- 생성자의 this 값에 새 객체를 할당합니다. 따라서 this가 새 객체를 가리킵니다.
- 생성자 내부 코드를 실행합니다.(객체에 프로퍼티를 추가합니다.)
- 새 객체를 반환합니다.
constructor 프로퍼티로 객체의 타입을 알아보는 것 보다 instanceof 연산자로 확인하는게 더 안전한 것으로 간주 됩니다.
생성자를 직접 만들면 인스턴스 타입을 쉽게 식별할 수 있는데 이는 팩터리 패턴에 비해 장점입니다.

함수로서의 생성자

생성자는 결국 함수일 뿐이며, 함수가 자동으로 생성자처럼 동작하게 만드는 특별한 문법 같은 것은 없습니다.
new 연산자와 함께 호출한 함수는 생성자처럼 동작하고 new 연산자 없이 호출한 함수는 일반적인 함수에서 예상하는 것과 똑같이 동작합니다.
함수를 호출할 때 객체의 메서드로 호출하거나 call()/apply()를 통해 호출해서 this의 값을 명시적으로 지정하지 않는다면 this 객체는 항상 Global 객체에 묶인다는 점을 기억해야 합니다.

생성자의 문제점

주요 문제는 인스턴스마다 메서드가 생성된다는 점입니다.
ECMAScript 에서 함수는 객체이므로 함수를 정의할 때마다 새로운 객체 인스턴스가 생성되는 것이나 마찬가지 입니다.

프로토타입 패턴

모든 함수는 prototype 프로퍼티를 가집니다.
prototype 프로퍼티는 해당 참조 타입의 인스턴스가 가져야할 프로퍼티와 메서드를 담고 있는 객체 입니다.
프로토타입의 프로퍼티와 메서드는 객체 인스턴스 전체에서 공유 된다는 점이 프로토타입의 장점입니다.

function Person() {}

Person.prototype.name = "Nicholas";
Person.prototype.age = 29;
Person.prototype.job = "Software Engineer";
Person.prototype.sayName = function() {
  console.log(this.name);
};

var person1 = new Person();
person1.sayName(); //"Nicholas"
var person2 = new Person();
person2.sayName(); //"Nicholas"

프로토타입은 어떻게 동작하는가

기본적으로 모든 프로토타입은 자동으로 constructor 프로퍼티를 갖는데 이 프로퍼티는 해당 프로토타입이 프로퍼티로서 소속된 함수(생성자 함수)를 가리킵니다. (Person.prototype.constructor === Person)
생성자를 호출해서 인스턴스를 생성할 떄마다 해당 인스턴스 내부에는 생성자의 프로토타입을 가리키는 포인터가 생성됩니다. (person.__proto__)

function Person() {}

Person.prototype.constructor = Person;

const person1 = new Person();
const person2 = new Person();

person1.__proto__ = Person.prototype;
person2.__proto__ = Person.prototype;

__proto__ 는 구현 환경에 따라 접근 불가능할 수도 있지만 객체 사이에 프로토 타입 연결이 존재하는지 isPrototypeOf() 메서드를 통해 알 수 있습니다.
ESCMAScript 5판에는 __proto__ 을 값을 반환하는 Object.getPrototypeOf() 라는 메서드가 추가 되었습니다.
객체에서 프로퍼티를 읽으려 할 때마다 해당 프로퍼티 이름으로 찾으려고 검색 합니다.
검색은 객체 인스턴스 자체에서 시작합니다. 인스턴스에서 프로퍼티 이름을 찾으면 그 값을 반환하지만 프로퍼티를 찾지 못하면 포인터를 프로토타입으로 올려서 검색을 계속합니다. 프로퍼티를 프로토타입에서 찾으면 그 값을 반환합니다.
프로토타입 프로퍼티와 같은 이름의 프로퍼티를 인스턴스에 추가하면 해당 프로퍼티는 인스턴스에 추가되며 프로토타입까지 올라가지 않습니다.
일단 객체 인스턴스에 프로퍼티를 추가하면 해당 프로퍼티는 프로토 타입에 존재하는 같은 이름의 프로퍼티를 가립니다.
인스턴스에 프로퍼티가 있으면 프로토타입에 존재하는 같은 이름의 프로퍼티에 대한 접근은 차단됩니다. 하지만 delete 연산자는 인스턴스 프로퍼티를 완전히 삭제하며 다음과 같이 prototype 프로퍼티에 다시 접근할 수 있습니다.
hasOwnProperty() 메서드는 프로퍼티가 인스턴스에 존재하는지 프로토타입에 존재하는지 확인합니다. 이 메서드는 Object로부터 상속한 것인데 해당 프로퍼티가 객체 인스턴스에 존재할 때만 true를 반환합니다.

프로토타입과 in 연산자

in 연산자에는 두 가지 쓰임이 있습니다.
- 하나는 그 자체로서 사용하는 경우
- for-in 루프에서 사용하는 경우
그 자체로서 사용하는 경우 in 연산자는 주어진 이름의 프로퍼티를 객체에서 접근할 수 있을 때, 다시말해 해당 프로퍼티가 인스턴스에 존재하든 프로토타입에 존재하든 모두 true를 반환합니다.

var person1 = new Person();
var person2 = new Person();

console.log(person1.hasOwnProperty("name")); //false
console.log("name" in person1); //true

person1.name = "Greg";
console.log(person1.name); //"Greg"  from instance
console.log(person1.hasOwnProperty("name")); //true
console.log("name" in person1); //true

console.log(person2.name); //"Nicholas"  from prototype
console.log(person2.hasOwnProperty("name")); //false
console.log("name" in person2); //true

delete person1.name;
console.log(person1.name); //"Nicholas" - from the prototype
console.log(person1.hasOwnProperty("name")); //false
console.log("name" in person1); //true

for-in 루프를 사용할 때는 객체에서 접근할 수 있고 나열(enumerate)가능한 프로퍼티를 반환하는데, 여기에는 인스턴스 프로퍼티와 프로토타입 프로퍼티가 모두 포함됩니다.
인스턴스 프로퍼티 중 나열 불가능한 prototype 프로퍼티(Enumerable이 false로 지정된 프로퍼티)를 가리고 있는 프로퍼티 역시 (인스턴스 프로퍼티로 재 지정한 프로퍼티들) for-in 루프에서 반환되는데 , 개발자가 지정한 프로퍼티는 항상 나열 가능하도록 한 규칙때문이다. ( IE8 및 이전버전에서는 적용 안됨 )
ECMAScript 5판의 Object.keys() 메서드를 통해 객체 인스턴스에서 나열 가능한 프로퍼티의 전체 목록을 얻을 수 있습니다.

function Person() {}

Person.prototype.name = "Nicholas";
Person.prototype.age = 29;
Person.prototype.job = "Software Engineer";
Person.prototype.sayName = function() {
  console.log(this.name);
};

var keys = Object.keys(Person.prototype);
console.log(keys); //"name,age,job,sayName"

var p1 = new Person();
p1.name = "Rob";
p1.age = 31;
var p1keys = Object.keys(p1);
console.log(p1keys); // "name,age"

나열 가능 여부와 관계없이 인스턴스 프로퍼티 전체 목록을 얻으려면 Object.getOwnPropertyNames() 메서드를 같은 방법으로 사용합니다.

function Person() {}

Person.prototype.name = "Nicholas";
Person.prototype.age = 29;
Person.prototype.job = "Software Engineer";
Person.prototype.sayName = function() {
  console.log(this.name);
};

var keys = Object.getOwnPropertyNames(Person.prototype);
console.log(keys); //"constructor,name,age,job,sayName"

프로토타입의 대체 문법

프로토타입에 기능을 더 가독성 있게 캡슐화하는 패턴이 더 널리 쓰입니다.

function Person() {}

Person.prototype = {
  name: "Nicholas",
  age: 29,
  job: "Software Engineer",
  sayName: function() {
    console.log(this.name);
  },
};

var friend = new Person();

console.log(friend instanceof Object); //true
console.log(friend instanceof Person); //true
console.log(friend.constructor == Person); //false
console.log(friend.constructor == Object); //true

요약하면 이 문법은 기본 prototype 객체를 완전히 덮어쓰는데, 결과적으로 constructor 프로퍼티는 함수 자체가 아니라 완전히 새로운 객체의 생성자 (Object 생성자) 와 같습니다.
constructor의 값이 중요하다면 다음과 같이 적절한 값을 지정하자.

function Person() {}

var friend = new Person();

Person.prototype = {
  constructor: Person,
  name: "Nicholas",
  age: 29,
  job: "Software Engineer",
  sayName: function() {
    console.log(this.name);
  },
};

이런식으로 생성자를 재설정하면 프로퍼티의 [[Enumerable]] 속성이 true로 지정됩니다. 네이티브 constructor 프로퍼티는 기본적으로 나열 불가능한 프로퍼티이므로 ECMAScript 5판을 구현한 자바스크립트 엔진이라면 Object.defineProperty()를 쓰는 편이 좋습니다.

Object.defineProperty(Person.prototype, "constructor", {
  enumerable: false,
  value: Person,
});

프로토타입의 동적 성질

프로토 타입에서 값을 찾는 작업은 적시(런타임) 검색이므로 프로토 타입이 바뀌면 그 내용이 즉시 인스턴스에도 반영이 된다. 심지어는 프로토 타입이 바뀌기 전에 빠져나온 인스턴스도 바뀐 내용을 반영합니다.
프로퍼티와 메서드를 언제든 프로토타입에 추가할 수 있고 이들을 즉시 객체 인스턴스에서 사용할 수 있긴 하지만, 전체 프로토타입을 덮어썼을 때에는 다르게 동작할 수 있습니다.
인스턴스는 프로토타입을 가리키는 포인터를 가질 뿐 생성자와 연결된 것이 아닙니다.
생성자의 프로토타입을 바꾸면 그 이후에 생성한 인스턴스는 새로운 프로토타입을 참조하지만, 그 이전에 생성한 인스턴스는 바꾸기 전의 프로토타입을 참조합니다.

function Person() {}

// friend 의 프로토타입은 바꾸기 전의 프로토 타입을 참조한다.
var friend = new Person();

Person.prototype = {
  constructor: Person,
  name: "Nicholas",
  age: 29,
  job: "Software Engineer",
  sayName: function() {
    console.log(this.name);
  },
};

friend.sayName(); //error

네이티브 객체 프로토타입

네이티브 참조 타입(Object, Array, String 등)의 메서드 역시 생성자의 프로토타입에 정의되어 있습니다. 예를 들어 sort() 메서드는 Array.prototype에 존재하고 substring() 메서드는 String.prototype에 정의되어 있습니다.
네이티브 객체의 프로토타입을 통해 기본 메서드를 참조할 수 있고 새 메서드를 정의할 수도 있습니다.

프로토타입의 문제점

모든 인스턴스가 기본적으로 같은 프로퍼티를 값을 갖게 됩니다.
인스턴스 프로퍼티에 값을 할당하면 prototype 프로퍼티를 가릴 수 있습니다.
프로퍼티가 참조 값을 포함한 경우 입니다.

function Person() {}

Person.prototype = {
  constructor: Person,
  name: "Nicholas",
  age: 29,
  job: "Software Engineer",
  friends: ["Shelby", "Court"],
  sayName: function() {
    console.log(this.name);
  },
};

const person1 = new Person();
const person2 = new Person();

person1.friends.push("Van");

console.log(person1.friends); // "Shelby", "Court", "Van"
console.log(person2.friends); // "Shelby", "Court", "Van"
console.log(person1.friends === person2.friends); // true

일반적으로 인스턴스 프로퍼티는 해당 인스턴스만의 특징으로 쓰기 마련입니다. 이 때문에 프로토타입 패턴을 있는 그대로만 사용하는 경우는 드뭅니다.

생성자 패턴과 프로토타입 패턴의 조합

생성자 패턴으로 인스턴스 프로퍼티를 정의하고 프로토타입 패턴으로 메서드와 공유 프로퍼티를 정의하는 방법 이런 접근법을 통하면 모든 인스턴스는 자신만의 인스턴스 프로퍼티를 가질 수 있고, 참조 방식을 통해 메서드는 공유하므로 메모리를 절약할 수 있습니다.

function Person(name, age, job) {
  this.name = name;
  this.age = age;
  this.job = job;
  this.friends = ["Shelby", "Court"];
}

Person.prototype = {
  constructor: Person,
  sayName: function() {
    console.log(this.name);
  },
};

var person1 = new Person("Nicholas", 29, "Software Engineer");
var person2 = new Person("Greg", 27, "Doctor");

person1.friends.push("Van");

console.log(person1.friends); //"Shelby,Court,Van"
console.log(person2.friends); //"Shelby,Court"
console.log(person1.friends === person2.friends); //false
console.log(person1.sayName === person2.sayName); //true

동적 프로토타입 패턴

동적 프로토타입 패턴은 모든 정보를 생성자 내부에 캡슐화 하여 이런 혼란을 해결하면서도, 필요한 경우에는 프로토타입을 생성자 내부에서 초기화하여 생성자와 프로토타입을 모두 쓰는 장점은 취하려는 접근법 입니다.

function Person(name, age, job) {
  // properties
  this.name = name;
  this.age = age;
  this.job = job;

  // methods
  if (typeof this.sayName !== "function") {
    Person.prototype.sayName = function() {
      console.log(this.name);
    };

    Person.prototype.sayJob = function() {
      console.log(this.job);
    };
  }
}

var friend1 = new Person("Nicholas", 29, "Software Engineer");
// friend2 가 생성될 당시에는 이미 prototype에 sayName과 sayJob 메서드가 존재하기에 추가적으로 생성되지 않는다.
var friend2 = new Person("Greg", 30, "Jounalist");
friend1.sayName(); // Nicholas
friend2.sayJob(); // Jounalist

sayName() 메서드가 존재하지 않는다면 추가하는 역할입니다. 이 코드 블록은 생성자가 첫 번째로 호출된 다음에만 실행됩니다. 그 다음 프로토타입이 초기화되며 그 이상 어떤 변경도 필요 없습니다.

기생 생성자 패턴

기생 생성자 패턴은 보통 다른 패턴이 실패할 때 폴백으로 씁니다. 이 패턴의 아이디어는 일반적인 생성자처럼 보이지만 사실 다른 객체를 생성하고 반환하는 동작을 래퍼 생성자로 감싸는 겁니다.

function Person(name, age, job) {
  var o = new Object();
  o.name = name;
  o.age = age;
  o.job = job;
  o.sayName = function() {
    console.log(this.name);
  };

  return o;
}

var friend = new Person("Nicholas", 29, "Software Engineer");
friend.sayName(); //"Nicholas"

이 예제에서는 Person 생성자가 새 객체를 생성한 다음 프로퍼티와 메서드를 초기화 하여 반환합니다. 생성자가 값을 반환하지 않을때는 기본적으로 새 객체 인스턴스(Person객체의 인스턴스인 this)을 반환합니다. 생성자 마지막에 return 문을 추가함으로써 생성자를 호출했을 때 반환되는 값을 오버라이드 할 수 있습니다.
이 패턴은 new 연산자를 써서 함수를 생성자로 호출하는 점을 제외하면 팩터리 패턴과 완전히 같습니다.
이 패턴을 쓰면 다른 방법으로는 불가능한 객체 생성자를 만들 수 있습니다. 예를 들면 메서드를 추가한 특별한 배열을 만들고 싶다고 한다면 Array 생성자에 직접 접근할 수는 없지만 이 패턴을 사용하면 이런 제한을 우회할 수 있습니다.

function SpecialArray() {
  //create the array
  var values = new Array();

  //add the values
  values.push.apply(values, arguments);

  //assign the method
  values.toPipedString = function() {
    return this.join("|"); // join 메서드는 Array 메서드
  };

  //return it
  return values;
}

var colors = new SpecialArray("red", "blue", "green");
console.log(colors.toPipedString()); // "red|blue|green"
console.log(colors instanceof SpecialArray); // false

이를 모두 실행하면 SpecialArray 생성자에 배열의 초기 값을 넘겨 호출할 수 있고, 생성자가 반환하는 배열에서는 toPipedString() 메서드를 사용할 수 있습니다.
반환된 객체와 생성자 또는 생성자의 프로토타입 사이에 아무 연결고리가 없다는 점입니다. 반환된 객체는 생성자와 아무 상관도 없다는 듯 존재합니다. 따라서 instancof 연산자로는 이 객체의 타입을 알 수 없습니다.

방탄 생성자 패턴

자바스크립트에는 공용 프로퍼티가 없고 메서드가 this를 참조하지 않는 객체를 가리키는 '방탄(durable)객체' 라는 용어가 있습니다.
방탄 객체는 this나 new의 사용을 금지하는 보안환경, 매시업 애플리케이션 등에서 데이터를 써드파티 보호하는데 가장 잘 어울립니다.
'방탄 생성자'는 기생 생성자 패턴과 비슷한 패턴으로 만드는 생성자인데 차이점은 두가지가 있습니다.
- 첫째, 생성된 객체의 인스턴스 메서드가 this를 참조하지 않습니다.
- 둘째, 생성자를 new 연산자를 통해 호출하는 경우가 결코 없습니다.

function Person(name, age, job) {
  //반환할 객체를 생성합니다.
  var o = new Object();

  // 옵션: 변수와 함수는 여기서 정의합니다.

  // 메서드를 등록합니다.
  o.sayName = function() {
    alert(name); // name에 접근할 수 없다.
  };

  return o;
}

var friend = Person("Nicholas", 29, "sftware Engineer");

friend.sayName();

이 패턴에서 눈여결 볼 부분은 반환된 객체의 name 값에 접근할 방법이 없다는 겁니다. sayName()메서드를 통해 그 값을 알 수는 있지만 그 외에는 방법이 전혀 없습니다.
friend 변수 역시 방탄 객체이며 객체에 등록된 메서드를 호출하지 않고서는 이 객체가 간직하는 데이터에 접근할 방법이 전혀 없습니다.
써드파티 코드에서 이 객체에 메서드나 데이터를 추가할 수는 있지만, 객체를 생성할 때 생성자에 넘겼던 원래 데이터에는 접근할 수 없습니다.
기생 생성자 패턴과 마찬가지로 방탄 생성자와 방탄 객체 인스턴스 사이의 연결은 존재하지 않으므로 instanceof는 동작하지 않습니다.

typescript embient

Thu, 18 Jun 2020 10:00:03 GMT

동기

타입스크립트를 학습하다가 타입 정의 파일에서의 declear 의 용도가 궁금해져서 몇가지 테스트 후 정리 해봅니다.

배경

namespace

일명 내부 모듈로 전역 이름 공간과 분리된 네임스페이스 단위의 이름 공간입니다.
네임스페이스는 여러 파일에 걸쳐 하나의 이름 공간을 공유합니다.
컴파일이 진행이 되면 지정된 네임스페이스 이름으로 전역 변수가 하나 생깁니다. 이 전역 변수에는 객체가 할당 됩니다. 이는 곧 전역 스코프에 속하지만 전역 스코프와 독립된 이름 공간을 지닌 다는 이야기가 됩니다.

namespace Hello {
  function pring() {}
}

"use strict";
var Hello;
(function(Hello) {
  function pring() {}
})(Hello || (Hello = {}));

네임스페이스는 export 를 이용해서 외부 모듈로도 선언이 가능합니다. 이렇게 모듈로 선언된 네임스페이스는 import 문을 이용해 JS로 컴파일 뒤에도 명시적으로 모듈 호출을 할 수 있습니다.

export namespace Hello {
  function pring() {}
}

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Hello = void 0;
var Hello;
(function(Hello) {
  function pring() {}
})((Hello = exports.Hello || (exports.Hello = {})));

export

일명 외부 모듈로 모듈 파일마다 이름 공간이 정해집니다.
외부 모듈의 이름 공간은 파일 내부로 제한됩니다.

타입 정의 파일

일반 자바스크립트 라이브러리에는 타입 정보나 구조 정보가 없기 때문에 타입스크립트 컴파일러가 자바스크립트 라이브러리의 API를 인식할 수 있게 하려면 타입 정의 파일을 정의해야 합니다.
자바스크립트는 타입 정보를 포함하지 못하므로 타입 정의 파일을 별도로 정의해야 합니다.
코드 어시스트 역할을 수행합니다. 개발 에디터에서 코드 어시스트를 통해 타입 정보를 표시합니다.
컴파일 에러 표시 역할을 수행합니다. 컴파일 에러가 발생할 때보다 자세한 에러 로그를 출력합니다.

앰비언트 선언

자바스크립트 라이브러리는 API 형태로 외부로 공개된 모듈을 포함합니다.
외부로 공개된 모듈은 보통 export 로 선언되어 있습니다.
이런 export 로 공개된 모듈은 declare 키워드를 통해 타입 정의 파일에서 선언 됩니다.
declare 선언은 실제 구현 내용은 포함하지 않고 단지 정의만 포함합니다.
타입스크립트 컴파일러에게 JS에 대한 구현'환경' 에 대한 정보를 준다라는 정도로 이해할 수 있습니다.

앰비언트 선언시 코드 어시스트는 어떻게 동작할까

export 문 없이 그냥 declare

// typeTest.d.ts
declare module test {
  export const name = "merlin";
}

위와 같이 작성된 타입 정의 파일이 있다면 타입스크립트 컴파일러는 다음과 같이 적으면 코드 어시스트를 실행시켜 줍니다.

test.name; // const name = "merlin"

export 문과 함께 작성된 declare

// typeTest.d.ts
export declare module test {
  export const name = "merlin";
}

위와 같이 작성된 타입 정의 파일이 있다면 다른 파일에서 import 시 코드 어시스트를 실행시켜 줍니다.

import { test } from "./typeTest";
test.name;

모듈 이름을 "" 로 감싸서 표현 했을 때

// typeTest.d.ts
declare module "ho" {
  export const name = "merlin";
}

위와 같이 "ho" 로 모듈 이름을 작성하면 다른 파일에서 import 모듈시 "ho" 모듈이 있는 것으로 간주하고 코드 어시스트를 실행 해줍니다. 실제로 ho.js 파일엔 아무것도 없어도 일단 어시스트는 돌아 갑니다.

import { name } from "ho";
test.name;

타입스크립트 컴파일시 타입 정의 파일도 만든다면

export default 시

// test.ts
export default function merlin() {}

// test.d.ts
export default function merlin(): void;

export 시

// test.ts
export function merlin() {}

// test.d.ts
export declare function merlin(): void;

아무것도 없을 시

// test.ts
function merlin() {}

// test.d.ts
declare function merlin(): void;

혼용시

// test.ts
export function merlin() {}
namespace merlin2 {}
const merlin3 = "merlin3";

// test.d.ts
export declare function merlin(): void;

정리

자바스크립트 파일에서 export 로 외부 모듈로 사용될 시 API로 사용자에게 노출이 되는 부분들은 declare 라는 키워드를 사용해서 타입 정의가 이뤄집니다.
자바스크립트 파일에서 export 문이 없이 일반 파일이라면 전역 스코프에 속하는 변수, 함수 등등을 declare 라는 키워드를 사용해서 타입 정의가 이뤄집니다.
만약 export 문과 일반 함수, 변수 등이 혼용되어 있을 경우에는 모듈로 간주 export 문으로 외부로 공개된 API 만 declare 키워드를 사용해서 타입 정의가 이뤄집니다.
export default 를 사용해서 외부로 노출하는 API는 별도의 declear 대신 default 문으로 타입 정의가 이뤄집니다.

node stream 에 관하여

Fri, 05 Jun 2020 10:00:03 GMT

gulp 플러그인을 만들기 위한 사전 작업으로 node의 stream 공부한걸 정리 해보았습니다. 잘못 된 부분이 있을시 피드백 부탁드립니다.

Stream

스트리밍 데이터 작업을 위한 인터페이스 입니다. 즉, 한곳에서 다른 곳으로 데이터가 흐를 수 있게 만들어주는 통로라고 생각하면 됩니다.

node.js 에는 스트림 타입이 있습니다.

Writable: streams to which data can be written (for example, fs.createWriteStream()).
Readable: streams from which data can be read (for example, fs.createReadStream()).
Duplex: streams that are both Readable and Writable (for example, net.Socket).
Transform: Duplex streams that can modify or transform the data as it is written and read (for example, zlib.createDeflate()).

Object mode

Node.js API로 작성된 모든 스트림은 문자열 및 버퍼 (또는 Uint8Array) 오브젝트에서만 독점적으로 작동합니다. 그러나 스트림 구현이 다른 유형의 JavaScript 값과 함께 작동 할 수 있습니다 (스트림을 특수 목적으로하는 null 제외). 이러한 스트림은 "개체 모드"에서 작동하는 것으로 간주됩니다.

스트림이 작성 될 때 objectMode 옵션을 사용하여 스트림 인스턴스가 오브젝트 모드로 전환됩니다. 기존 스트림을 객체 모드로 전환하는 것은 안전하지 않습니다.

Readable Stream

readable 스트림은 2가지 작업 모드를 지원합니다. 기본적으로는 paused 모드를 default 모드로 하고 있습니다. 이 둘의 모드는 언제든 바뀔 수 있습니다.

flowing : flowing 모드는 push 모드라고 합니다.
paused : paused 모드는 pull 모드라고 합니다.

flowing 모드에서는 기본 시스템에서 데이터를 자동으로 읽고 EventEmitter 인터페이스를 통해 이벤트를 사용하여 가능한 한 빨리 응용 프로그램에 제공합니다.

pause 모드에서는 stream.read() 메소드를 명시 적으로 호출하여 스트림에서 데이터 청크를 읽습니다.

그리고 writable 스트림에 연결 됩니다.

push 모드의 장점은 consumer 가 데이터를 가져오는 코드를 컨트롤 하지 않고 데이터 소비하는 관점에서만 생각하면 된다는 것입니다. 단점은 source 측이 데이터 생산 속도가 consumer 데이터 처리 속도보다 빠를 때 문제가 생깁니다.

paused 모드의 장점은 consumer 의 데이터 처리 속도에 맞춰서 source 데이터를 가져올 수 있다는 것이지만 단점은 consumer 가 source 데이터 생산 동안 기다려야 하고 반대로 consumer 가 데이터를 처리 하고 있는 동안엔 source 데이터를 가져올 수 없으므로 waiting 시간이 많아 진다는 것입니다.

위 같은 장단점을 보완하기 위해선 버퍼가 필요합니다.

Buffer

버퍼는 consumer 와 source 데이터의 처리 속도의 차이로 인해 생겨난 것입니다. 버퍼가 없는 상황에서 실제로 consumer 는 source 데이터 처리 속도 직접적으로 제어 하긴 힘듭니다.

따라서 스트림에 버퍼를 하나 두어 source 에 빠른 데이터 처리에 임시로 저장 해두는 공간을 마련해 둡니다. consumer 쪽은 source 속도와 상관없이 버퍼에 있는 데이터를 가져다 쓰면 되는 것입니다.

이때, soucre 속도 보다 consumer 속도가 빠르게 되면 buffering ( 데이터 수집중.. ) 이라는 현상이 발생하는 것입니다.

source — push (일단 던지고) —> buffer에 쌓이고 —> pull(내가 원할 때 받고) —> consumer

source 데이터가 push를 지속적으로 하면 buffer는 무한정 늘어 날 가능성이 있다. 이때를 대비해서 backpressure 기법을 사용한다. ( highWaterMark 속성을 사용해서 버퍼의 데이터 양을 조절 )

buffer가 꽉 찼을 때는 pause를 통해 source가 데이터 생산을 잠시 중단하고, 버퍼가 drain 되었을 때( 다시 쓸 준비가 되었을 때 ) 는 resume 을 통해 source가 데이터 생산을 재개하게 만들어 준다.

nodejs는 외부 자원(http, fs) 에서 쏟아지는 데이터 양(push : 일방적으로 보내는)을 조절하기 위해 다음과 같은 일을 pipe 에서 진행 해줍니다.

consumer 가 원할 때 source 데이터를 push 해준다. ( 즉, consumer가 데이터를 달라고 요청 )
쓰는 스트림의 버퍼 양에 따라서 source 데이터를 pause/resume 해준다.
resume 되면 flowing 읽기 모드
pause 되면 pause 읽기 모드

참고

React testing library 사용기 (ing)

Sat, 23 May 2020 10:00:03 GMT

동기

atomic 으로 디자인된 컴포넌트와 react testing library 를 사용하면서 느낀점을 정리합니다. 느낀점을 정리한 것이라고 꼭 이렇게 해야한다는 것은 아닙니다.

테스팅을 진행해야 할때 가져야할 생각을 정리 합니다.

컴포넌트 내에서 상세한 구현의 방법은 잊어야 합니다. 유저는 본인이 원하는 기능의 대한 실제 구현 방법을 생각하지 않습니다. 유저는 행하는 행위에 대해서 원하는 결과 값 또는 결과 행위에 대해서만 바랄 뿐입니다.
컴포넌트를 생각하지 않고 실제 화면에 그려지는 DOM 또는 컨텐츠, 텍스트를 생각합니다.
기획서가 있다면 페이지 별로 상세 기능을 뽑아 보고 그 페이지를 다시 organisms 단위로 나눠서 테스트 케이스를 짜면 될 듯 싶습니다.
atomic 특징 상 organisms 단위에서는 통합테스트를 생각하고 그 이하로 부모가 모를 만한 로직을 지니고 있다면 자식들에 한해서 unit test를 진행합니다.
organisms 단위에서 개선된 children 컴포넌트로 바꿨다거나 class 컴포넌트에서 function 컴포넌트로 바뀌었다거나 했어도 테스트는 유지 가능해야 합니다.

경험

organisms 단위에서 테스팅을 진행 했을 경우 실제 고민 했던 것을 적어 봅니다.

일반 컴포넌트 일 때 무엇을 테스팅 해야 하는가?

props의 형태에 따라 달라 지는 렌더링을 테스트 합니다.

렌더링 테스트를 진행 할 때는 텍스트가 있는지 없는지 위주로 테스트를 진행 합니다.

describe("<TotalStatusInfo />", () => {
  it('데이터 제공 기준일을 받으면 "데이터 제공 기준일" 타이틀과 함께 해당 날짜를 보여줍니다', () => {
    const mockModifyTime: ModifyTime = {
      start_date: "2020-04-12",
      end_date: "2020-05-12",
    };

    const { getByText } = render(
      <TotalStatusInfo modifyTime={mockModifyTime}></TotalStatusInfo>
    );
    getByText("(데이터 제공 기준일 : 2020-04-12 ~ 2020-05-12)");
  });
});

어떤 특정한 함수가 props 로 넘어 온다면 해당 함수를 실행 시킬 액션이 있을 것입니다. 이때 두 가지로 확인이 가능 합니다.

해당 컴포넌트가 비지니스 로직을 구현해야 하는 컴포넌트 라면 액션을 fire 해서 UI 의 변화를 감지한다. 이를 통해 비지니스 로직을 구현합니다.

해당 컴포넌트가 비지니스 로직을 구현하는 컴포넌트가 아닌 적절한 자식 컴포넌트에 넘겨주는 역할을 담당한다면 해당 함수가 필요한 인자와 같이 호출 되는지도 확인을 합니다. 이때는 mock 함수를 활용합니다. jest.fn() 이를 통해 적절한 컴포넌트에 넘겨주는 지 확인합니다.

test("FilterSection의 onClick props를 버튼 들에게 넘겨 버튼 클릭시 버튼 ID를 인자로 넘기면서 호출합니다.", () => {
  const onClick = jest.fn();
  const { getByText } = setup({
    title: sampleTitle,
    filterButtonList: sampleFilterButtonList,
    onClick,
  });
  const aidButton = getByText("aid");
  fireEvent.click(aidButton);

  expect(onClick).toBeCalledWith("aid");
});

자식 컴포넌트에서 useContext를 사용한 컴포넌트가 있으면 어떻게 테스팅을 진행 해야 하는가?

organisms 컴포넌트의 자식 컴포넌트에서 useContext를 사용을 했다면 organisms 컴포넌트만 render시 에러가 나게 됩니다.

그래서 해당 ContextProvider 컴포넌트를 감싸서 render를 진행해야 합니다.

// 중복 설정을 피하기 위해서 setup 함수를 만들어서 각 test 마다 필요한 설정을 활용합니다.
const setup = (props: UfoStatusWidgetGroupProps) => {
  const utils = render(
    <ModalContextProvider>
      <UfoStatusWidgetGroup {...props}></UfoStatusWidgetGroup>
    </ModalContextProvider>
  );

  return {
    ...utils,
  };
};

test("UfoStatusWidgetGroup props에 statusGroupData 넣었을시 각각의 수치가 렌더링 된다.", () => {
  const { getByText } = setup({
    statusGroupData,
    isLoading: false,
    error: null,
  });

  getByText("10,000");
  getByText("1,203,405");
  getByText("32.89");
});

rxjs ajax 를 사용한 컴포넌트는 어떻게 테스팅을 진행 해야 하는가?

가장 많이 고민을 했던 부분입니다.

기존 axios 를 사용 했다면 node_modules를 mocking 하는 방법과 axios-mock-adapter 를 선택 할 수 있겠습니다만, 저는 rxjs 에 내장되어 있는 ajax 를 사용했기 때문에 rxjs 의 ajax를 mocking 하는 방법을 찾아 보기로 했습니다.

그 결과 찾을 수 없었습니다. ( 혹시 아시는 분은 알려주시면 감사 하겠습니다. ) 가장 마지막까지 시도 했던 방법은 jest.mock() 함수로 ajax를 mocking 하는 방법 이였습니다. jest.doMock() 함수를 써봐도 잘 되진 않았습니다.

jest.mock('rxjs/ajax', () => {
  return {
    __esModule: true,
    ajax: jest.fn(() => [])
  }
})

위 코드 ajax: jest.fn(() => []) 에서 사실 return 해야 하는 타입은 Observable<AjaxResponse> 가 되어야 했습니다. 타입이 안맞아서 에러가 떨어집니다. dynamic import 를 활용해서 다음과 같이 Observable 까진 생각해 볼 수 있었습니다만, AjaxResponse 타입의 Mock을 어떻게 구현을 해야 할지 몰랐습니다. dynamic import 를 활용하는 것은 jest.mock은 babel-jest 로 인해서 자동으로 import 문 위로 hoist 되기 때문에 활용 한 것입니다.

jest.mock('rxjs/ajax', async () => { // mock 할때 async 함수를 넣으면 안된다.
  // const {of} = import('ajax')
  // or
  // const {AjaxResponse} = import('rxjs/ajax')
  return {
    __esModule: true,
    // ajax: jest.fn(() => of([])) // Observble 타입까진 만들 수 있는데 AjaxResponse 타입은 ??
    ajax: jest.fn(() => of(new AjaxResponse(??)))
  }
})

그래서 생각한 방법은 rxjs/ajax 를 mocking 하는 것이 아닌 xhr 을 mocking 하는 것입니다.

import mock from "xhr-mock"; 를 활용하는 방법 이였습니다.

describe("<TagOccupancyCard />", () => {
  // replace the real XHR object with the mock XHR object before each test
  beforeEach(() => mock.setup());

  // put the real XHR object back and clear the mocks after each test
  afterEach(() => mock.teardown());

  const setup = (props: TagOccupancyCardProps) => {
    const utils = render(
      <ModalContextProvider>
        <TagOccupancyCard {...props}></TagOccupancyCard>
      </ModalContextProvider>
    );
    return {
      ...utils,
    };
  };

  test("API Test", async () => {
    mock.get(`${DOMAIN}/Test`, {
      status: 200,
      reason: "Created",
      body: JSON.stringify([
        {
          id: "UFO",
          value: 100,
          tag_ratio: 0,
          partname: "호잇",
          fullname: "호잇",
        },
        {
          parent: "UFO",
          id: "P10",
          value: 47.18,
          tag_ratio: 0,
          partname: "아잇",
          fullname: "아잇",
        },
      ]),
    });

    const { getByText } = setup({
      currentFilterData: {
        name: "adid",
        isDisable: false,
        isNew: false,
        id: "adid",
        isActive: true,
      },
    });

    await wait(() => getByText("호잇"));
    await wait(() => getByText("아잇"));
  });
});

따로 rxjs/ajax 를 mocking 해주는 라이브러리는 못 찾았습니다.

생각해 보면 좀 더 원시적인 xhr를 mocking 해서 rxjs를 쓰던 axios를 쓰던 관계 없이 테스트가 통과 했었어야 하지 않았나 싶습니다.

highchart.js 를 활용해서 차트를 그리는 컴포넌트 테스트 중에 highchart.js error 26 이 오류로 나온다면

highchart.js 26 번 에러를 찾아보면 이런 글이 나옵니다.

https://www.highcharts.com/errors/26/

WebGL not supported, and no fallback module included

이게 왜 뜨는지 다음과 같이 검색했지만 소득이 없었습니다.

jest highchart error 26
jsdom webgl

등 여러 검색 결과에도 찾을 수 없었습니다. 결국 node_modules로 왜 26번 에러가 뜨는지 확인해 본 결과 hightchart 의 boost 모듈에서 에러가 발생하는 것을 알 수 있었습니다. 차트를 그릴 때, 다음과 같은 옵션을 썼다면

{
  boost: {
    useGPUTranslations: true,
  },
}

아래와 같은 에러를 찾아 볼 수 있습니다.

Debugger attached.
  console.log
    Highcharts error #26: www.highcharts.com/errors/26/

      at defaultHandler (node_modules/highcharts/highcharts.src.js:469:21)

에러를 안뜨게 하는 방법은 못찾았지만 생각해보면 브라우저 환경에서 정확히 테스트를 하는 것이 아니기 때문에 무시하기로 했습니다.

정리

앞으로 계속 테스트를 작성해 나가면서 정리하고 몇 가지 규칙을 세워두면 TDD 문화를 정착 해 나갈 수 있지 않을까 생각합니다. 계속 업데이트 됩니다.

React testing library의 전략

Thu, 21 May 2020 10:00:03 GMT

동기

React에 TDD를 적용을 하기로 마음을 먹고 testing library를 써보기로 했습니다. 과연 Enzyme 과는 어떤면이 다르고, 컴포넌트를 어떻게 테스팅을 진행 해야 할까를 고민하던 중 Kent C. Dodds 의 블로그 몇개를 읽고 난 생각과 번역을 적어 보려고 합니다. 출처는 맨 아래 참고에 올려 두겠습니다.

고민

testing library 를 사용하다 보면 컴포넌트의 부모 컴포넌트에서 자식 컴포넌트가 테스팅 해야 할 것들도 작성하는 듯한 느낌을 받았습니다. ( 이게 사실 testing library에서 원했던 것일 수 있습니다. ) 자식 컴포넌트도 테스트를 작성하게 된다면 테스트 들이 너무 중복되진 않을까?? 하는 질문에서 다음과 같은 stack overflow를 발견합니다.

https://github.com/testing-library/react-testing-library/issues/167

Testing Library 의 목표는 다음과 같이 나와있습니다.

As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

unit-vs-integration-vs-e2e-tests

프론트 엔드 테스팅에는 다음과 같은 전략이 있습니다.

End to End 테스트

사용자처럼 앱을 클릭하고 올바르게 작동하는지 확인하는 도우미 로봇입니다. "기능 테스트" 또는 E2E 라고도합니다. 이 방법은 전체 어플리케이션을 실행하면서 일반 사용자 처럼 앱과 상호 작용 합니다. 일반적으로 테스트 양이 많아 비용이 크고 느리며 또한 많은 실패 지점이 생겨서 테스트가 중단 될 가능성이 높아져 테스트를 분석하고 수정하는데 더 많은 시간이 필요합니다.

통합 테스트

여러 장치가 조화롭게 작동하는지 확인하는 테스트. 대부분의 통합 테스트는 전체 앱을 렌더링 하지 않습니다. 하지만 앱에서 사용하는 모든 제공자(컴포넌트)들을 render 할 수 있습니다. 통합 테스트는 기본 개념은 가능한 한 mock을 만들지 않는 것입니다. 보통 사용자의 행위 및 보이는 것에 대해서 테스트를 진행하게 됩니다. ( 버튼이 클릭이 되고, 텍스트가 보이고 UI 가 보이고 에 대한 테스트 입니다. ) 어떤 HTML이 쓰였는지 그런것에 대한건 중요치 않습니다.

단위 테스트

분리 된 개별 부품이 예상대로 작동하는지 확인하십시오. 순수 함수일 때 유닛 테스트 하기 가장 좋습니다. 비용이 적고, 테스트 하기 빠릅니다. 만약 비용과 속도 측면에서 절충안을 찾는다면 100% 단위 테스트로 진행할 것입니다. 일반적으로 종속성이 없는 작은 항목을 테스트 하거나 해당 종속성을 mock해서 테스트를 진행합니다.

우리가 테스트를 작성하는 이유

테스트를 작성하는 가장 큰 가장 중요한 이유는 자신감입니다. 미래를 위해 작성한 코드가 현재 프로덕션에서 실행중인 앱을 중단시키지 않을 것이라고 확신하고 싶습니다. 그래서 내가 무엇을하든, 내가 작성하는 테스트 종류가 최대한 자신감을 갖게하고 테스트 할 때 해당 테스팅의 타협점(과연 어디까지 이 테스트 코드로 보장을 할 것인가?)을 인식 해야합니다.

테스팅의 타협에는 다음과 같은 종류가 있습니다. 비용, 시간, 신뢰성(확신)

비용

E2E 테스트로 갈 수록 비용은 비싸집니다. 지속적인 통합 환경에서 테스팅을 진행할때 실제 비용이 들기도 하지만 엔지니어가 각 테스트 를 작성하고 유지 관리하는데 들어가는 시간 또한 들어갑니다. 또한 더 많은 실패 지점이 생겨 테스트가 중단 될 가능성이 높아져 테스트를 분석하고 수정하는 데 더 많은 시간이 필요합니다.

속도

E2E 테스트로 갈 수록 속도는 느려집니다. 테스트 실행 코드가 많기 때문입니다. 단위 테스트는 전통적으로 테스트가 작습니다. 이는 디펜던시들이 없거나 mock 디펜던시(수천 줄의 라인을 단 몇줄로 줄여줍니다.)를 이용하기 때문입니다.

신뢰성(확신)

유닛 테스트에서는 간단한 문제에 대한 신뢰성이 있는가 반면 E2E를 통한 테스트는 큰 문제에 대한 신뢰성이 있습니다.

테스트들이 소프트웨어 사용 방식과 유사 할수록 더 많은 확신을 줄 수 있습니다.

각 테스트들의 특성을 알아본다면 다음과 같을 것입니다. 단위 테스트는 호출 한 종속성에 대해 호출할 때 적절하게 호출되는지는 확인 할 수 없습니다. ( 어떻게 호출되는지 확인할 순 있지만, 정확히 호출이 되어지는지 확신할 순 없습니다. ) UI 통합 테스트는 백엔드와 데이터가 제대로 주고 받는지 확인할 수 없고 에러에 대해서 정확하게 응답하는지 확인 할 수가 없습니다. End to End 테스트는 꽤 유용하지만, 전형적으로 실제 production 환경이 아닌 곳에서 테스트를 진행해서 실제 환경을 위한 신뢰성을 절충합니다.

여기서 E2E 테스트를 진행 한다면 "신뢰 계수" 라고 불리는 것이 올라갑니다. 즉, 어플리케이션이 성공적으로 움직인다는 것을 그만큼 보장하기 때문입니다. 하지만 비용과 시간을 더 들 것입니다. 단위 테스트를 진행 할 경우에는 테스트 코드 라인은 줄어 들 수 있지만 어플리케이션 코드 라인 만큼 커버하기 위해 테스트는 더 작성해야 합니다. 또 사실 낮은 레벨의 테스트에서는 몇몇 테스트는 불가능 합니다. 특히 정적 분석 도구(Typescript 같은)는 비지니스 로직에 대한 자신감을 줄 수 없습니다.

다른 사례를 봅시다. 폼과 URL 생성기를 통합한 엣지 케이스(예측 가능한 일정한 범위를 넘는 경우)를 위해 특정 필드에 입력한 값과 submit 버튼을 클릭 했을때를 E2E 테스트로 확인하는 것은 많은 양의 시간을 application 이 잘 돌아갈 수 있게 하는 것에 시간을 쏟을 것입니다.

이럴땐 통합 테스트가 더 잘 어울릴 수 있습니다. 실제 사용하는 컴포넌트를 렌더링할 수 있고 유닛 테스트에서 에지 케이스를 더 잘 커버할 수 있는지 확인하기 위해 설정 기능에서 상당한 양의 작업을 수행할 수 있습니다.

만약에 단위 테스트를 사용하여 숫자 대신 문자열로 add 함수를 호출 할 때 발생하는 상황을 확인하려고하면 TypeScript와 같은 정적 유형 검사 도구를 사용하는 것이 훨씬 좋습니다.

결론

E2E 테스트는 많은 양의 테스트로 인해 어떤 코드로 인해 실패를 했는지 추적하기가 어려워지지만, 그 의미는 곧 그 테스트가 자신감을 좀 더 올려줄 수 있다는 의미가 됩니다. 테스트를 작성할 시간이 충분하지 않은 경우에 특히 유용합니다. 차라리 자신감을 가지고 테스트를 통해 문제를 발견하지 못한 것보다 실패 이유를 추적하는 데 어려움을 겪고 싶습니다.

사실 이런 테스트 전략의 차이점 보다는 나의 코드가 변하고자 할때 나의 코드가 비지니스 요구에 만족하고, 다양한 테스팅 전략을 사용해서 목표에 도달할 수 있는 자신감을 가질 수 있는지에 대해서 더 관심이 많아야 할 것 입니다.

얕은 렌더링을 사용하지 않는 이유

얕은 렌더링을 사용하면 컴포넌트의 구현을 리팩토링 했을 경우 나의 테스트는 깨지게 되고, 얕은 렌더링을 사용하면 나의 application을 깨지게 했지만, 테스트는 여전히 돌아가게 됩니다. 얕은 렌더링은 실제로 DOM element와 상호작용하지 않습니다. 실제로 렌더링 되는건 없기 때문입니다. 또한 실제로 커스텀 컴포넌트에 의해 리턴된 엘리먼트는 얻을수가 없습니다.

왜 우리는 얕은 렌더링을 사용할까

리액트 컴포넌트의 메서드를 호출하기 위해.
각 컴포넌트의 children 모드를 렌더링하는게 낭비처럼 보이기 때문.
실제 단위 테스트를 위해 사용합니다. 테스팅에 노출 되어있는 컴포넌트는 유닛 테스트 동안 에러가 발생될 수 있는 새로운 디펜던시가 도입이 되어도 여전히 의도한 대로 작동할 수 있습니다.

리액트 컴포넌트의 메서드를 호출하기 위해

이 경우에는 실제로 메서드를 이벤트에 바인딩 할때 오타가 나거나 해도 테스트는 깨지지 않습니다. 메서드를 가지고 테스트를 진행 했기 때문입니다. 또한 이전 버전과 호환이 되는 리펙토링으로 예를 들면 메서드 이름을 바꾸더라도 테스트가 중단 됩니다. 구현 세부 사항을 테스트 하기 때문에 이런 테스트들이 실패를 하게 됩니다. 요약하면 인스턴스나 상태 값을 테스트 한다는 것은 사용자가 알지도 못할 뿐더러 신경쓰지 못하기 때문에 테스트가 주는 자신감과 점점 멀어지게 됩니다.

낭비처럼 보이는 것에 대해서

속도에서는 크게 느껴지지 않을 정도의 차이가 납니다.

실제 단위 테스트를 위해서

일반적으로 얕은 렌더링은 다른 컴포넌트를 렌더링 하지 않습니다. 이 때문에 내부 다른 컴포넌트로 인한 애플리케이션이 중단 될 수있는 위험을 감지 하지 못한다는데 단점이 있을 수 있습니다. 테스트가 진행되는 컴포넌트는 의도한 대로 움직일 순 있지만 오류를 유발하는 새로운 종속성이 도입 됬을때 해당 테스트가 보장 될 수 없다는것을 의미합니다. 오류가 발생하는 하위 컴포넌트가 들어와도 테스트 컴포넌트가 테스트 의도 대로 움직인다면 테스트 시점에서 응용 프로그램이 제대로 작동하리라는 확신을 할 수 있습니까?

누가 어플리케이션이 제대로 동작하지 않는데 단위 테스트에 신경을 쓰겠습니까? 어플리케이션이 제대로 동작하지 않을때는 내가 사용하고 있는 서드 파티 컴포넌트가 나의 시스템 행위를 깨트렸는지를 확실히 알고 싶을 것입니다.

무거운 통합 테스트에 좀더 의존하는 것이 유닛 테스트를 더 적게 필요로 하고 컴포넌트에 대한 엣지 케이스에 대한 유닛 테스트만 필요로 하게 됩니다. 이러한 상황에서도 어떤 구성요소가 mock이 되었고 그것들이 모두 렌더링이 된다는 것을 확신할 때 유지 관리 가능한 테스트 베이스로 이어질 것입니다.

테스팅 작성시 중첩을 피하자

가장 Root describe에 변수들을 설정 해두고 각 중첩된 자식 describe 에 beforeEach 를 사용하면서 해당 변수에 그때 그때 마다 다른 테스트 변수들을 할당해서 테스트를 하지 맙시다. 이렇게 작성하게 되면 나중에 실제 테스트 코드를 살펴 볼때 변수를 추적하기 위해서 시간을 많이 소비 해야 합니다. 변수를 계속 재 할당하는 것은 안티 패턴에 속하고 피해야 할 것입니다. 변수를 계속 재 할당하는 것이 아닌 공통 설정을 할 수 있는 방법을 찾아 봅시다.
잘못된 추상화를 방지하기 위해서 가장 쉬운 방법은 각 테스트 마다 인라인 방식으로 넣는 것 일 겁니다. 중복되는 코드가 보일지 몰라도 이 테스트들을 살펴 보기에는 더 명확할 것입니다. 각 테스트에서 진행되는 작업을 이해하기가 더 편리합니다.
Apply AHA (Avoid Hasty Abstractions) 급한 추상화를 피해서 작성 해야 합니다. 잘못된 추상화보다 중복을 먼저 선호하고 변화하는 것에 대해서 최적화를 해야 합니다. 하지만 중복되는 코드에 대해서 줄이고 싶다면 테스트 간에 코드를 공유할 수 있어야 합니다. 다시 beforeEach 카드를 집어 든다면 다시 변수를 재 할당해야 하는 수를 생각 해야 하기 때문에 선호 하지 않습니다. 이럴 때 함수를 사용 할 수 있습니다.

describe 로 테스트 파일이 커질 때 시각적으로 테스트를 그룹화 시킬 수는 있지만 테스트 파일이 커지는 것을 좋아하지 않습니다. 대신 파일별로 나눠서 그룹을 만드는 것을 더 선호합니다.

beforeEach/afterEach/etc 이밖의 유틸리티를 나쁘다고 하는 것은 아닙니다. 테스트 안에서 가변 변수의 사용을 주의 해야 한다는 것입니다.

테스트를 위해 글로벌한 환경을 일부 변경해야 하는 경우가 있습니다. 이럴땐 정리를 해야 하는 상황이 생깁니다. @testing-library/react@9 환경에서는 자동으로 테스트 하나가 끝나면 cleanup 을 진행합니다.

정리

E2E 방식으로 테스트를 진행하는 법이 사용자가 기능을 경험하는 방식이므로 선호되는 방법입니다. 만약 자식 컴포넌트에 부모 컴포넌트에서 넘겨주는 props 기능이 아닌 자체적으로 들고 있는 기능이 있다면 자식 컴포넌트에 별도로 테스트를 진행하는 것이 좋을 거 같습니다.

테스트를 작성할 때 세부적인 구현에 포커싱을 맞추지 않고 컴포넌트를 리펙토링 했을때 테스트가 깨지지 않게 하는 것이 목표로 삼아야 할 것입니다. 해당 컴포넌트의 구현에 대한 테스트가 아닌 기능에 대해서 테스트를 진행하는 것입니다. 즉, 테스트는 구현이 어떻게 상세로 되어 있는지 알 필요가 없는 것입니다. 또한 실제 사용자들이 겪을 만한 것들에 대해서 테스트를 진행하는 것이 테스트를 유지 관리하기가 더 편리 할 것으로 생각이 됩니다.

여기서 구현이라 하면 인터페이스의 메서드 이름대로 실제 동작하는 코드를 작성하는 것이라고 할 수 있고, 기능은 인터페이스의 메서드 이름 정도 생각하면 될 듯 싶습니다. 코드 하나 수정할 때마다 test case가 같이 수정이 되는 것이 아닌 오랫동안 유지 될 수 있는 test case를 만들려는 노력을 해야 할 거 같습니다.

참고

GraphQL Server

Sun, 03 May 2020 10:00:03 GMT

개요

Rest API의 호출 형식 말고도 GraphQL을 사용하면 더 코드가 직관적이고 적은 요청으로 원하는 데이터만 가져올 수 있다는 장점을 듣고 GrpahQL Server 학습을 듣고 정리를 해봅니다.

그럼 먼저 Rest API와 GraphQL의 장.단점 부터 알아봅시다.

Rest API 장점

메서드의 URI를 조합해서, 예측 가능하고 일정한 정보와 작업을 요청하는 것입니다. 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론 가능하다는 것입니다. 자원을 구조와 함께 나타내는 이런 형태의 구분자를 URI라고 합니다.

Rest API 단점

전송되는 데이터의 양 측면에서 소모가 클것입니다.

GraphQL 장점

내가 원하는 것만 골라서 요청할 수 있습니다. 필요한 정보를 얻기 위해서 Rest API는 여러번의 요청을 보내야할 수 도 있습니다. 하지만 GraphAPI는 다른 depth의 정보들이 한번에 다 와줄 수 있습니다.

백엔드 서버 하나에 Rest API 와 GraphAPI을 둘 다 구현해놓으면 사용자들이 골라서 사용할 수 있습니다.

GraphQL 단점

받아야 하는 항목이 많고 딱 정해진 데이터 들을 받아와야 할때에는 쿼리에 일일이 나열하는 것 보다 그냥 URL 한줄 호출하는게 더 심플 할때가 있습니다.

참고 : Schema 란 데이터의 구조나 표현법, 관계를 나타내는 말입니다.

구현

먼저 GraphQL 쿼리의 요청을 받고 그에 해당하는 응답을 내보내줄 서버가 필요합니다. 이 서버는 GraphQL Yoga 라는 것으로 만들어 볼 것이며, 이는 GraphQL 서버를 아주 빠르게 시작할 수 있게 도와줍니다.

서버 index

import { GraphQLServer } from "graphql-yoga";
import resolvers from "./graphql/apiResolver";

// Query는 네가 정보를 받을 때만 쓰입니다.
// Mutation은 네가 정보를 변형할 때 쓰입니다.

const server = new GraphQLServer({
  typeDefs: "graphql/apiSchema.graphql", // 스키마 정의
  resolvers, // resolvers 정의
});

server.start(() => console.log("Graphql Server Running hou!!!"));

스키마

스키마에서는 나의 데이터가 어떻게 보일지를 정의하는 공간입니다. 또는 데이터를 받거나 줄 정보에 대한 설명이라고 생각하면 됩니다.

type Movie {
  id: Int!
  title: String!
  rating: Float
  description_intro: String
  language: String
  medium_cover_image: String
  genres: [String]
}

type Query {
  movies(limit: Int, rating: Float): [Movie]!
  movie(id: Int!): Movie
  suggestions(id: Int!): [Movie]!
}

resolvers

스키마에서 너의 데이터가 어떻게 보일지를 정의하고 그 질문을 resolve에서 해결하는 함수를 만드는 것입니다. resolvers는 다른 API에 갈 수도 있고 Database에 갈 수도 있습니다.

실제로 이름 Query의 기능성을 프로그래밍 해야합니다. 이 Query 들을 어떤 방식으로 resolve(해결) 해야 한다. 라는 느낌입니다.

import { getMovies, getMovie, getSuggestions } from "./apidb";

const resolvers = {
  Query: {
    movies: (_, { rating, limit }) => getMovies(limit, rating),
    movie: (_, { id }) => getMovie(id),
    suggestions: (_, { id }) => getSuggestions(id),
  },
};

export default resolvers;

DB

여기서 DB는 API를 요청하는 공간으로 마련해 두었습니다.

import axios from "axios";
const BASE_URL = "https://yts-proxy.now.sh/";
const LIST_MOVIES_URL = `${BASE_URL}list_movies.json`;
const MOVIE_DETAILS_URL = `${BASE_URL}movie_details.json`;
const MOVIE_SUGGESTIONS_URL = `${BASE_URL}movie_suggestions.json`;

export const getMovies = async (limit, rating) => {
  const {
    data: {
      data: { movies },
    },
  } = await axios(LIST_MOVIES_URL, {
    params: {
      limit,
      minimum_rating: rating,
    },
  });
  return movies;
};

export const getMovie = async (id) => {
  const {
    data: {
      data: { movie },
    },
  } = await axios(MOVIE_DETAILS_URL, {
    params: {
      movie_id: id,
    },
  });
  return movie;
};

export const getSuggestions = async (id) => {
  const {
    data: {
      data: { movies },
    },
  } = await axios(MOVIE_SUGGESTIONS_URL, {
    params: {
      movie_id: id,
    },
  });
  return movies;
};

참고

[algorithms] advanced

Fri, 01 May 2020 10:00:03 GMT

동적 프로그래밍

동적 프로그래밍은 재귀와 상반되는 기법으로 알려져 있습니다. 재귀에서는 위에서 아래로 내려가면서 점차 작아지는 문제를 모두 해결하는 방식인 반면, 동적 프로그래밍에서는 아래에서 위로 해결하면서 결과를 모아 큰 전체 문제를 해결하는 방식입니다.
재귀 기법으로 해결할 수 있는 대부분의 프로그래밍 문제는 동적 프로그래밍으로도 해결할 수 있습니다.
재귀 기법의 느낌은 문제를 풀다가 새로운 문제를 만나면 "어? 잠깐만 기다려봐 다시 나 스스로에게 물어볼께" 라는 느낌?
재귀는 기본적으로 stack을 쌓아가면서 활용하게 되는데 또 다른 stack을 쌓아 올리기 전 상태를 현재 위치 stack에 저장해두고 stack을 쌓아 올리고 다시 돌아와서 저장해 두었던 값을 활용해서 또 다른 작업을 시도하려는 일련의 작업입니다.

피보나치 예제

피보나치는 이전의 두 숫자를 더해서 다음 숫자를 만들 수 있습니다. 재귀를 이용해서 다음과 같이 구현할 수 있습니다.

function recurFib(n) {
  if (n < 2) {
    return n;
  } else {
    // 위에서 아래로 내려가면서 문제를 해결
    return recurFib(n - 1) + recurFib(n - 2);
  }
}

이미 계산한 값을 컴파일러가 기억할 수 있다면 더 효율성을 높일 수 있습니다. 동적 프로그래밍에서는 가장 간단한 하위 문제부터 해결하면서 좀 더 복잡한 상위 문제로 나아갑니다.

function dynFib(n) {
  // 초기화
  const val = new Array(n).fill(0);

  if (n === 1 || n === 2) {
    return 1;
  } else if (n > 2) {
    val[1] = 1;
    val[2] = 1;
    for (let i = 3; i <= n; i++) {
      // 작은 수부터 차근차근 더해 갑니다.
      val[i] = val[i - 1] + val[i - 2];
    }
  }

  return val[n];
}

반복 기법을 이용해서도 피보나치를 계산 할 수 있다.

function iterFib(n) {
  let last = 1; // 첫번째
  let nextLast = 1; // 두번째
  let result = 1;

  for (let i = 3; i <= n; i++) {
    result = last + nextLast;
    last = nextLast;
    nextLast = result;
  }

  return result;
}

가장 긴 공통 문자열 찾기

두 개의 문자열에서 가장 긴 공통 문자열을 찾는 문제입니다.
이차원 배열을 이용해서 각 문자열을 비교하고 두 배열의 같은 위치에서 같은 문자를 발견하면 이차원 배열의 해당 행과 열에 위치한 요소를 1 증가시킵니다.
문자열을 비교하면서 얼마나 많은 글자가 일치했는지 변수에 저장합니다.
알고리즘이 끝나면 일치한 횟수를 저장한 변수와 인덱스 변수를 이용해 가장 긴 공통 문자열을 반환합니다.

function Isc(word1: string, word2: string) {
  const icsArr: number[][] = [];
  let max = 0;
  let index = 0;

  // 초기화
  for (let i = 0; i <= word1.length; i++) {
    icsArr[i] = [];
    for (let j = 0; j <= word2.length; j++) {
      icsArr[i][j] = 0;
    }
  }

  // 계산
  // i === 0 || j === 0 인 곳은 0으로 셋팅해준다
  for (let i = 1; i <= word1.length; i++) {
    for (let j = 1; j <= word2.length; j++) {
      if (word1[i - 1] === word2[j - 1]) {
        // 단어가 같으면 카운트를 해줍니다.
        // 이전 문자 비교 count에 + 1 을 해줍니다.
        icsArr[i][j] = icsArr[i - 1][j - 1] + 1;

        // 카운트 한 값이 max 보다 크다면 max 값을 업데이트 하고
        // 그 인덱스를 index에 저장해둔다
        if (max < icsArr[i][j]) {
          max = icsArr[i][j];
          index = i;
        }
      }
    }
  }

  // 출력
  if (max === 0) {
    return "";
  }

  if (max > 0) {
    let str = "";
    console.log(icsArr);
    // index - max : 연속된 max 값을 가지는 해당 index에 max를 빼면 시작 인덱스를 얻을 수 있다
    // Isc('abbcc', 'dbbcc') : 5(index) - 4(max)
    for (let i = index - max; i <= max; i++) {
      str += word1[i];
    }
    return str;
  }
}

console.log(Isc("abbcc", "dbbcc"));
//              a, b, b, c, c
// 0: (6)   [0, 0, 0, 0, 0, 0]
// 1: (6) d [0, 0, 0, 0, 0, 0]
// 2: (6) b [0, 0, 1, 1, 0, 0]
// 3: (6) b [0, 0, 1, 2, 0, 0]
// 4: (6) c [0, 0, 0, 0, 3, 1]
// 5: (6) c [0, 0, 0, 0, 1, 4]

배낭 문제: 재귀

우리가 금고 털이범이라고 가정 했을때 우리가 가지고 있는 배낭의 크기는 한정되어 있다. 이때, 금고 안에 물건은 크기나 값이 모두 다르다고 했을때, 값어치가 나가는 물건 위주로 배낭을 채워야 합니다.

여기 예제에서는 금고에 다섯 개의 물건이 있다고 합니다. 각 물건의 크기는 3,4,7,8,9 이고 각각의 값어치는 4,5,10,11,13 이라고 합니다. 배낭에는 16 크기의 물건을 담을 수 있다고 합니다. 이때, 배낭에 넣을 수 있는 가장 값어치 있는 물건을 구해보자.

function max(a, b) {
  return a > b ? a : b;
}

// capacity : 가방용량
// size: 보물의 무게가 든 배열
// value: 값어치든 배열
// n : 총 보물 남아 있는 갯수
function knapsack(capacity, size, value, n) {
  if ((n === 0) | (capacity === 0)) {
    // 보물 갯수나 가방 용량이 없으면 0 리턴
    return 0;
  }

  if (size[n - 1] > capacity) {
    // 가방의 남은 무게보다 보물의 무게가 크다면 다음 보물로 넘어간다.
    return knapsack(capacity, size, value, n - 1);
  } else {
    // 해당 보물을 가방에 담고 값어치가 높은지, 이 보물을 안담고 그 다음 보물들을 담는게 값어치가 높은치 비교한다.
    return max(
      value[n - 1] + knapsack(capacity - size[n - 1], size, value, n - 1),
      knapsack(capacity, size, value, n - 1)
    );
  }
}

const value = [4, 5, 10, 11, 13];
const size = [3, 4, 7, 8, 9];
const capacity = 16;
const n = 5;
console.log(kanpsack(capacity, size, value, n));

재귀는 맨 아래에서부터 걷어 올리는 느낌이다. 즉, 일단 다 풀어놨다가 오르면서 정리를 하는 느낌이다. 가장 첫번째 보석부터 size를 판별한 후 값어치를 더한 값어치와 그 보석을 넣지 않았을때(가방 무게가 그만큼 줄지 않아서 다른 보석을 넣을 가능성이 있음)의 값어치를 비교해서 큰 값을 가져옵니다. 위 코드는 다음과 움직인다.

knapsack(16, size, value, 5);
max(13 + knapsack(7, size, value, 4), knapsack(16, size, value, 4));
max(13 + knapsack(7, size, value, 3), knapsack(16, size, value, 4));
max(
  13 + max(10 + knapsack(0, size, value, 2), knapsack(7, size, value, 2)),
  knapsack(16, size, value, 4)
);
// (....)

보면 알다 시피 상당히 많은 재귀를 돌아야 하는 것을 알 수 있습니다.

배낭 문제: 동적 프로그래밍

동적 프로그래밍 기법에서는 최정 해법에 도달할 때까지 중간 결과를 저장할 임시 배열 저장소가 필요합니다.

function max(a, b) {
  return a > b ? a : b;
}

// capacity : 가방용량
// size: 보물의 무게가 든 배열
// value: 값어치든 배열
// n : 총 보물 남아 있는 갯수
function dKnapsack(capacity, size, value, n) {
  // 가방 무게와 보석의 갯수가 늘어날때마다 가장 값어치 있는 값을 저장하는 배열
  // 1차 배열 주얼리 갯수
  // 2차 배열 가방 용량
  const K = [];

  for (let i = 0; i <= n; i++) {
    K[i] = []; // 초기화
  }

  // jewelry: 주얼리 인덱스 (0번째 보석, 1번째 보석, ....)
  // bagCapacity: 가방 용량
  for (let jewelry = 0; jewelry <= n; jewelry++) {
    for (let bagCapacity = 0; bagCapacity <= capacity; bagCapacity++) {
      if (jewelry === 0 || bagCapacity === 0) {
        K[jewelry][bagCapacity] = 0;
      } else if (size[jewelry - 1] <= bagCapacity) {
        // 해당 보석의 사이즈가 가방 무게보다 작거나 같으면 보석을 가방에 담아보자.
        // 해당 보석을 가방에 담는다고 했을때 값어치 리스트에서 값어치를 가져오고 ( value[jewelry - 1] )
        // 해당 보석을 담기 전 가방의 값어치 K[이전 주얼리 인덱스][가방용량 - 현재 주얼리 무게]를 ( K[jewelry - 1][bagCapacity - size[jewelry - 1]] )
        // 앞의 두가지를 더한 값어치를 이전 보석까지 담은 최선의 값어치( K[jewelry - 1][bagCapacity] )와 비교한다.
        // 해당 결과 저장
        K[jewelry][bagCapacity] = max(
          value[jewelry - 1] + K[jewelry - 1][bagCapacity - size[jewelry - 1]],
          K[jewelry - 1][bagCapacity]
        );
      } else {
        // 해당 보석의 사이즈가 가방 무게보다 나간다면 담지 못하므로 같은 가방의 무게에 이전 보석까지 담은게 최선의 값어치가 된다.
        K[jewelry][bagCapacity] = K[jewelry - 1][bagCapacity];
      }
    }
  }
  console.log(K);
  return K[n][capacity];
}

const value = [4, 5, 10, 11, 13]; // 보석 값어치
const size = [3, 4, 7, 8, 9]; // 보석 사이즈
const capacity = 16;
const n = 5; // 보석 갯수
dKnapsack(capacity, size, value, n);

// 가로는 bagCapacity:   0   1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
// 0            : (17) [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
// 1 (jewelry 0): (17) [0, 0, 0, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4]
// 2 (jewelry 1): (17) [0, 0, 0, 4, 5, 5, 5, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
// 3 (jewelry 2): (17) [0, 0, 0, 4, 5, 5, 5, 10, 10, 10, 14, 15, 15, 15, 19, 19, 19]
// 4 (jewelry 3): (17) [0, 0, 0, 4, 5, 5, 5, 10, 11, 11, 14, 15, 16, 16, 19, 21, 21]
// 5 (jewelry 4): (17) [0, 0, 0, 4, 5, 5, 5, 10, 11, 13, 14, 15, 17, 18, 19, 21, 23]

최적의 정답이 이차원 배열의 마지막 셀에 저장되어 있습니다. 이 기법에서는 어떤 항목을 선택해야 할지를 알려주진 않지만, 크기가 16이 돼야 한다는 조건과 값이 23이 돼야 한다는 조건을 이용해 세 번째 항목과 다섯 번째 항목을 선택할 수 있다는 결론에 도달할 수 있습니다.

탐욕 알고리즘

문제를 해결하는 좋은 해결책을 찾아가는 기법입니다. (이 선택이 나중 선택에 어떤 영향을 줄 것인지 전혀 고려하지 않음)
탐욕 알고리즘에는 '최상'의 해법을 선택하다 보면 결구 끄것이 전체 문제를 해결하는 '최상'의 선택이 될 것이라는 전제가 깔려있습니다.

동전 거스름돈 문제

상점에서 어떤 물건을 샀는데 거스름돈이 63센트라고 가정해보자. 탐욕 알고리즘에 따르면 점원은 2개의 쿼터(quarter), 한개의 다임(dime), 세 개의 페니(penny)를 건넬 것입니다. 이것이 하프 달러(half dollar)를 사용하지 않고 63센트를 거슬러주는 최소한의 코인입니다. ( 1달러 : 100센트, 하프달러는 50센트: 더이상 발행 안함, 쿼터는 25센트, 다임은 10센트, 니켈은 5센트, 페니는 1센트 )

// 하프달러는 없다고 생각하자.
// 단위가 높은 화폐인 쿼터로 거스름돈을 완성하면서 coins 배열에 저장한다.
// 남은 거스름돈이 쿼터보다 작아지면 다음으로 작은 화폐 단위인 다임으로 이동해 가능한 많은 다임을 활용한다.
// 사용한 다임의 수도 coins 배열에 저장한다.
// 이와 같이 니켈, 페니를 이용해서 거스름돈을 만들어 냅니다.
const QUARTER = 0.25;
const DIME = 0.1;
const NICKEL = 0.05;
const PENNY = 0.01;
function makeChange(originAmt, coins) {
  // 쿼터로 나눴을때 originAmt가 크다는것은 originAmt가 0.25 값보다 크다는 것을 의미한다.
  if (originAmt % QUARTER < originAmt) {
    coins[3] = parseInt(originAmt / QUARTER); // 몫을 coins에 저장
    originAmt = originAmt % QUARTER;
  }

  if (originAmt % DIME < originAmt) {
    coins[2] = parseInt(originAmt / DIME); // 몫을 coins에 저장
    originAmt = originAmt % DIME;
  }

  if (originAmt % NICKEL < originAmt) {
    coins[1] = parseInt(originAmt / NICKEL); // 몫을 coins에 저장
    originAmt = originAmt % NICKEL;
  }
  coins[0] = parseInt(originAmt / PENNY);
}

const originAmt = 0.63;
const coins = [];
makeChange(originAmt, coins);
console.log(coins);

// [3, empty, 1, 2]
// 0.01 * 3 + 0.1 + 0.25 * 2 = 0.63

배낭 문제: 탐욕 알고리즘

배낭에 추가할 물건이 기본적으로 연속적일 때만 탐욕 알고리즘을 적용할 수 있습니다. 즉, 개별적으로 셀 수 없는 물건만 사용해야 합니다. 연속적인 물건을 이용하면 단위 부피를 단위 가격으로 나누어 물건의 값을 계산할 수 있습니다. 따라서 가장 값어치가 높은 물건부터 물건이 고갈되거나 배낭이 찰 때까지 먼저 넣은 다음 두 번째로 값어치가 높은 물건을 넣는 순의 전략을 이용할 수 있습니다. 예를 들어 TV 반 개를 배낭에 넣을 수 없기 때문에 탐욕 알고리즘에서는 셀 수 없는 연속적인 물건만 제대로 계산할 수 있습니다. 즉, 덩어리 진 것, 쪼갤 수 있는 것들이 탐욕 알고리즘을 적용할 수 있을 것입니다.

연속적인 물건을 담는 배낭 문제를 분수(fractional) 배낭 문제라고 합니다. 분수 배낭 문제의 알고리즘은 다음과 같이 풉니다.

배낭의 용량을 W 물건의 가치를 v, 물건의 무게는 w다.
항목의 값어치는 v/W 비율로 평가합니다.
값어치가 높은 물건부터 고려합니다.
가능한 한 많은 물건을 추가 합니다.

물건	A	B	C	D
값	50	140	60	60
무게	5	20	10	12
비율	10	7	6	5

가방 무게는 30 입니다.

// 이걸 하기 전에 무게와 값어치 배열을 비율에 따라 내림차순으로 정렬을 해야 합니다.
function ksack(values, weights, capacity) {
  let loadedWeight = 0; // 가방에 쌓이는 무게
  let index = 0;
  let loadedValue = 0; // 가방에 쌓인 값어치

  while (loadedWeight < capacity && index < values.length) {
    // 가방에 용량이 남았거나 물건 순회를 다했을 경우 탈출
    if (weights[index] <= capacity - loadedWeight) {
      // 물건의 무게가 남아있는 가방 무게보다 적게 나간다면 담자!!
      loadedValue = loadedValue + values[index];
      loadedWeight = loadedWeight + weights[index];
    } else {
      // 물건의 무게가 남아있는 가방 무게보다 더 무겁다면 그 물건을 쪼개서 꽉 채워보자.
      const ratio = (capacity - loadedWeight) / weights[index];
      loadedValue = loadedValue + ratio * values[index];
      loadedWeight = loadedWeight + weights[index];
    }
    index = index + 1;
  }

  return loadedValue;
}

const itmes = ["A", "B", "C", "D"];
const values = [50, 140, 60, 60];
const weight = [5, 20, 10, 12];
const capacity = 30;
console.log(ksack(values, weight, capacity));

여기서는 물건 A, B를 모두 담고 물건 C는 반만 담는 것이 최적의 답입니다.