[디자인 패턴] 싱글톤 패턴(Singleton Pattern)

하나의 클래스에 오직 하나의 인스턴스만을 가지는 패턴이다. 

자바스크립트에선 단순하게 리터럴 {} 만으로도 싱글톤 패턴을 만들 수 있다. 

const obj = {
	a:27
}

const obj2 = {
	a:27
}

console.log(obj==obj2) //false

리터럴로 객체를 생성하게 되면 다른 어떤 객체와도 같지 않기 때문에 같은 내용을 가지더라도 obj와 obj2는 서로 다른 인스턴스를 가진다.

하지만, 이렇게 구현하면 비공개 상태나 비공개 함수를 정의할 수 없기 때문에 다음과 같은 방식으로 싱글톤 패턴을 구성한다. 

Class Singleton {
	// constructor(생성자)
	// class 객체의 초기값 설정
    // class 내부에서는 한 개만 존재할 수 있고 2번 이상 사용하면 Syntax Error 발생
	constructor() {
    	// Singleton 클래스의 인스턴스가 존재하지 않으면, 인스턴스 생성
    	if (!Singleton.instance){
        	Singleton.instance = this;
        }
        // 존재한다면 바로 인스턴스 반환
        return Singleton.instance;
    }
}

const a = new Singleton();
const b = new Singleton();
console.log(a==b) //true

이러한 방식의 싱글톤 패턴을 데이터베이스 연결 모듈에 많이 쓰인다.

const URL='mongodb://localhost:27017/kundolapp'
const createConnection = url => ({
	"url" : url
})

class DB {
	constructor(url) {
    	if (!DB.instance) {
        	DB.instance = createConnection(url)
        }
        return DB.instance
    }
    connect() {
    	return this.instance
    }
}

const a = new DB(URL)
const b = new DB(URL)
console.log(a===b) // true

이와 같이 DB.instance라는 하나의 인스턴스를 기반으로 a,b를 생성할 수 있다.

보통 공통된 객체를 여러 개 생성해서 사용하는 데이터베이스 연결 모듈에서 데이터베이스 연결에 관한 인스턴스 생성 비용을 아낄 수 있다.

 

단점

TDD(Test Driven Development)를 할 때 걸림돌이 될 수 있다. TDD를 할 때, 단위 테스트를 하게 되는데 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 한다. 하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 독립적인 인스턴스를 만들기가 어렵다.

 

장점

고정된 메모리 영역을 가지고 하나의 인스턴스를 만들어서, 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어든다.

 

의존성 주입(Dependency Injection)

싱글톤 패턴은 모듈간의 결합을 강하게 만들 수 있다. 이를 완화하기 위해 '의존성 주입'을 이용한다.

*의존성(종속성) : A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A도 변해야 한다는 것을 의미함.

왼쪽 그림처럼 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다는 오른쪽 그림처럼 중간에 의존성 주입자(Dependency Injection)가 이 부분을 가로채서 메인 모듈이 간접적으로 의존성을 주입하는 방식이다.

이를 통해 메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 된다. (디커플링 된다)

 

의존성 주입의 예시 코드를 알아보자

class Weapon {
  public attack() {
    console.log('hit!');
  }
}

class Player {
  private weapon: Weapon;

  constructor() {
    this.weapon = new Weapon();
  }

  public attack() {
    this.weapon.attack();
  }
}

const me = new Player();
me.attack();

위 코드에서 보면 Player 클래스는 Weapon 클래스를 사용하고 있으므로 Weapon 클래스에 대해 의존성을 띄고 있다고 할 수 있다.

그런데 이 중에 Weapon 클래스가 아니라, Weapon 클래스를 상속받은 Whip 클래스를 사용하고 싶다면 Weapon을 의존하는 모든 클래스를 찾아 수정해줘야 한다. 

class Weapon {
  public attack() {
    console.log('hit!');
  }
}

class Whip extends Weapon {
  public attack() {
    console.log('whipwhip!');
  }
}

class Player {
  private weapon: Weapon;

  constructor() {
    this.weapon = new Whip();
  }

  public attack() {
    this.weapon.attack();
  }
}

const me = new Player();
me.attack();

이러한 경우, 의존성 주입을 하려면 의존하고 있는 코드 부분에서 클래스를 생성자로 받아오면 된다.

의존성 주입 예시

Player에서 생성자로 의존하고자 하는 Weapon 클래스를 상속받는 클래스를 넘겨준다.

const me = new Player(new Whip());

그러면 기존의 의존성을 가지는 Player 클래스를 수정할 필요없이 사용할 수 있게 된다. 

 

의존성 주입의 장점

• 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션(업데이트)하기 수월하다. 
• 구현할 때 추상화 계층을 넣고 이를 기반으로 구현하기 때문에 애플리케이션 의존성 방향이 일관되고 애플리케이션을 쉽게 추론할 수 있으며, 모듈 간의 관계가 더 명확해진다.

의존성 주입의 단점

• 모듈들이 더욱 분리되므로 클래스 수가 늘어나 복잡성이 증가할 수 있다.
• 약간의 런타임 패널티가 생기기도 한다.

의존성 주입 원칙

• 고수준 모듈은 저수준 모듈에 의존해서는 안되며, 둘 다 추상화에 의존해야 한다.
• 추상화는 세부 사항에 의존하지 않아야 한다.
• 즉, 상위 수준 모듈은 하위 수준 모듈 대신, 추상화된 인터페이스나 추상 클래스와 같은 추상화된 개념에 의존해야 합니다. 이는 구체적인 구현 세부 사항에 직접 의존하지 않고, 이를 추상화에 위임함으로써 시스템의 유연성과 확장성을 향상시키는데 도움이 된다.