[자바스크립트 패턴] ① 리터럴을 이용한 객체 생성 패턴

---

이 글은 PC 버전 TISTORY에 최적화 되어있습니다.

서론

 자바스크립트에 객체 정의 방법에는 리터럴 표기와 생성자 함수가 있다. 언어적으로 Object()나 Array() 같은 내장 생성자 함수를 지원하고 있는데, 이를 사용하는 것보다 리터럴 표기법을 사용하면 어떤점이 좋은지 다룬다. 이번 포스팅에서는 객체 리터럴 방식을 알아보도록 한다.

1. 객체 리터럴 방식

객체 리터럴을 이용한 객체 생성

   자바스크립트의 객체는 단순히 이름 : 값의 쌍이다. 값에는 원시 데이터 타입, 객체 심지어 함수까지 올 수 있으며 이 때의 함수는 메서드라고 부른다. 그러므로 사용자가 만든 객체는 언제든지 그 값이 바뀔 수 있다. 또한 네이티브 객체의 프로퍼티도 변경이 가능하다. 또한 객체 정의 후 프로퍼티 및 함수를 추가할 수 있다.

// 내장 네이티브 객체의 함수도 바꿀 수 있다.
Array.prototype.concat = function() {
    // 바꿀 내용
}

    프로그램 생명주기 중 언제든빈 객체를 정의 한 후 프로퍼티와 함수를 추가할 수 있으며 삭제할 수도 있다. (항상 빈 객체로 객체를 정의해야하는 것은 아니다. 자바스크립트 코딩 컨벤션에서 다뤘던 7.객체 정의 방법을 준수하여 생성 가능하다.)

// 빈 객체로 시작
var person = {};

// 객체 정의 후 프로퍼티 정의 가능
person.name = "evan";

// 함수도 후에 정의 가능
person.getName = function() {
    return person.name;
}

// 빈 객체말고도 속성, 기능이 추가된 객체를 정의할 수 있다.
var animal = {
    name: "fox",
    age: 12

    bark: function() {
        // 코드 구현
    }
};

---

  빈 객체라는 것은 실제로는 비어있지 않다. 간단하게 { }로 생성하더라도 기본적으로 Object.prototype을 상속받은 프로퍼티, 메서드를 가진다. 단순하게 빈 객체라는 것은 상속 받은 프로퍼티나 메서드를 제외하고 자기 자신의 프로퍼티, 메서드가 없는 것으로 이해하면 된다.

---

내장 네이티브를 통한 객체 생성

     결론부터 말하자면 내장 네이티브 생성자를 사용하지 말고 객체 리터럴을 사용해라. 두 방법으로 객체를 생성하는 방법을 먼저 보자.

// 리터럴 방식
var person = {
    name: "황혁진",
    age: 23
};

// 안티 패턴[각주:1]: 네이티브 생성자 함수 사용 
var person = new Object();
car.name = "황혁진";

    객체 리터럴 방식이 있다면 생성자 함수 방식을 쓸 필요 없지만 생성자 함수 방식이 가지는 기능이 무엇인지는 알아야한다.(이전 개발자가 작성한 레거시 코드^[각주:2]를 이해해야할 수 있기 때문이다.) 바로 인자를 넘길 수 있다는 것이다. 이것이 생성자 함수 방식의 문제이다. 인자에 따라서 원하는 결과와 다른 결과가 나올 수 있기 때문이다. 다시 말하지만 new Object 대신 객체 리터럴을 사용하라.

var o = new Object();
console.log(o.constructor); // function Object() { [native code] }

var o = new Object(1);
console.log(o.constructor); // function Number() { [native code] }
console.log(o.toString(10)); // 1

var o = new Object("혁진");
console.log(o.constructor); // function String() { [native code] }
console.log(o.length); // 2

var o = new Object(true); 
console.log(o.constructor); // function Boolean() { [native code] }

1. 소프트웨어 공학에서, 안티-패턴이란 흔히 사용되기도 하는 패턴이지만 실무적으로는 비효율적인 그리고/또는 생산적이지 못한 패턴을 말한다. [본문으로]
2. 테스트가 불가능하거나 어려운 코드 [본문으로]