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

먼저 사전에 알아야할 간단한 지식을 말하면,

• 라이브러리
  : '공통'으로 사용될 수 있는 '특정한 기능들'을 '모듈화'한 것을 의미한다. 폴더명, 파일명 등에 규칙이 없고 프레임워크에 비해 자유롭다. '도구'인 '가위'를 사용해서 '내가 직접' 컨트롤하여 자르는 것을 상상하면 이해하기 쉽다.

• 프레임워크
  : '공통'으로 사용될 수 있는 '특정한 기능들'을 '모듈화'한 것을 의미한다. 폴더명, 파일명 등에 규칙이 있고 라이브러리에 비해서는 좀 더 엄격하다. '도구'인 '비행기'를 타고 이동하지만, '비행기'를 컨트롤 할 수는 없는 것을 생각하면 이해하기 쉽다.

디자인 패턴?

• 디자인 패턴 : 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것

싱글톤 패턴?

싱글톤 패턴(singleton pattern)은 '하나의 클래스'에 오직 '하나의 인스턴스'만 가지는 패턴이다. 원래는 하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있다. 보통 '데이터베이스 연결 모듈'에 많이 사용된다.

하나의 인스턴스를 만들어 놓고, 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있지만, 의존성이 높아진다는 단점도 공존한다.

자바스크립트의 싱글톤 패턴

const obj = {
	c: 3
}

const obj2 = {
	c: 3	
}

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

=> obj와 obj2는 다른 인스턴스를 가진다. 어느 정도는 싱글톤 패턴이라 볼 수 있긴하지만 보통은 아래와 같이 구성된다.

class Singleton {
	constructor(){
    	if(!Singleton.instance) {
        	Singleton.instance = this
        }
        return Singleton.instance
    }
    getInstance() {
    	return this.instance
    }
}

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

=> 위 코드를 보면, Singleton.instance라는 하나의 인스턴스를 가지는 Singleton 클래스를 구현한 것을 볼 수 있다. a와 b는 하나의 인스턴스를 가지게 된다.

데이터베이스 연결 모듈

싱글톤 패턴은 데이터베이스 연결 모듈에 많이 쓰인다고 했다. 아래와 같이 말이다.

const URL = 'mongodb://localhost:33333/chlgnlqls'
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를 생성한 것을 볼 수 있다.
위와 같은 방법으로 데이터베이스 연결에 관한 인스턴스 생성 비용을 아낄 수 있게 된다.

싱글톤 패턴 - Java

자바로는 '중첩 클래스'를 이용해 만드는 것이 가장 대중적인 방법이다. 이외에도 여러 방법이 있긴한다. 예시를 하나 들면 아래와 같다.

class Singleton {
	private static class singleInstanceHolder {
    	private static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
    	return singleInstanceHolder.INSTANCE;
    }
}

public class HelloWorld {
	public static void main(String[] args){
    	Singleton a = Singleton.getInstance();
        Singleton b = Singleton.getInstance();
        System.out.println(a.hashCode());
        System.out.println(b.hashCode());
        if (a == b) {
        	System.out.println(true);
            }
    }
}

싱글톤 패턴 - mongoose

실제로 싱글톤 패턴은 Node.js에서 MongoDB 데이터베이스를 연결할 때 쓰는 mongoose 모듈에서 볼 수 있다.

mongoose의 데이터베이스를 연결할 때 쓰는 connect()라는 함수는 싱글톤 인스턴스를 반환한다.
실제 코드를 보면 아래와 같다.

Mongoose.prototype.connect = function(uri, options, callback) {
	const _mongoose = this instanceof Mongoose ? this : mongoose;
    const conn = _mongoose.connection;
    
    return _mongoose._promiseOrCallback(callback, cb => {
    	conn.openUri(uri, options, err => {
        	if(err != null) {
            	return cb(err);
            }
            return cb(null, _mongoose);
        })
    })
}

싱글톤 패턴 - MySQL

Node.js에서 MySQL 데이터베이스를 연결할 때도 싱글톤이 쓰인다!

// 메인 모듈
const mysql  = require('mysql');
const pool = mysql.createPool({
	connectionLimit: 10,
    host: 'example.org',
    user: 'kundol',
    password: 'secret',
    database: '히빈쓰디비'
});
pool.connect();

// 모듈 A
pool.query(query, function (error, results, fields) {
	if(error) throw error;
    console.log('solution is : ', results[0].solution);
});

// 모듈 B
pool.query(query, function (error, results, fields) {
	if(error) throw error;
    console.log('solution is : ', results[0].solution);
});

위 코드를 보면, 메인 모듈에서 데이터베이스 연결에 관한 인스턴스를 정의하고 다른 모듈인 A or B에서 해당 인스턴스를 기반으로 쿼리를 보내는 형식으로 쓰이는 것을 볼 수 있다.

싱글톤 패턴의 단점

싱글톤 패턴으로는 TDD(Test Driven Development)를 할 때 어려움을 겪을 수 있다.
TDD는 단위 테스트를 주로 하는데, '단위 테스트'는 테스트가 서로 독립적이고, 테스트를 어떤 순서로든 진행할 수 있어야 한다.

하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이기에 각 테스트마다 '독립적인' 인스턴스를 만들기 어렵다.

의존성 주입

싱글톤 패턴은 사용하기 쉽고 실용적이라는 장점이 있는 반면, 모듈 간의 결합을 강하게 만들 수도 있는 단점이 있다. 이를 '의존성 주입(DI, Dependency Injection)'을 통해 모듈 간의 결합을 조금 느슨하게 만들어 해결할 수도 있다.

'의존성'이란, '종속성'이라고도 불리며, A가 B에 의존성이 있다는 것은, B의 변경 사항에 대해 A도 변해야 된다는 것을 말한다.

메인 모듈이 '직접' 다른 하위 모듈에 대한 의존성을 주기보다는, 중간에 '의존성 주입자'가 이 부분을 가로채 메인 모듈이 '간접적'으로 의존성을 주입하는 방식이다.

'디커플링 된다' 라고 표현하기도 한다.

의존성 주입 장점

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

의존성 주입의 단점

모듈들이 더 분리되어, 클래스 수가 늘어나 '복잡성이 증가'될 수 있고, 약간의 런타임 페널티가 생기기도 한다.

의존성 주입 원칙

1) '상위 모듈'은 '하위 모듈'에서 어떤한 것도 가져오지 않아야 한다.
2) 둘 다 '추상화'에 의존해야 한다.
3) 추상화는 세부 사항에 의존하지 말아야 한다.

위 의존성 주입 원칙을 지켜주면서 만들어야 한다!