싱글톤 패턴 ( Singleton Pattern )

잊지않기위해 기록해보겠습니다. 

 

싱글톤 패턴 ( singleton pattern ) 

Singleton is a design pattern that tells us that we can create only one instance of a class and that instance can be accessed globally.

싱글톤은 클래스의 인스턴스를 하나만 생성할 수 있고 해당 인스턴스는 전역적으로 액세스할 수 있다는 것을 알려주는 디자인 패턴입니다.

그리고 저자분에 의하면 데이터베이스 연결 모듈에 많이 사용된다고 합니다. 싱글톤 패턴은 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듀들이 공유하기 때문에 비용이 줄어드는 장점이 있지만 의존성이 높아지게됩니다. 

 

Singleton design pattern exposes a single instance that can be used by multiple components

---

실제 mysql DB 연결 예제입니다. 

// 메인 모듈 
const mysql = require('mysql');
const pool = mysql.createPool({
    connectionLimit: 10,
    host: 'example.org',
    user: 'evan',
    password: 'test1234',
    database: 'sql_database'
});
 
pool.connect();
 
// 모듈 A
pool.query(query, function ( error, results, fields) {
    if(error) throw error;
    console.log('The solution is: ', results[0].solution);
});
 
// 모듈 B
pool.query(query, function ( error, results, fields) {
    if(error) throw error;
    console.log('The solution is: ', results[0].solution);
});

 

장점과 단점

장점 

클래스의 인스턴스가 하나만 생성되도록 합니다.
전역적으로 액세스할 수 있는 인스턴스에 대한 단일 액세스 포인트를 얻습니다.

 

단점

이는 단일 책임 원칙에 위배됩니다. 두 가지를 동시에 해결하려고 시도하기때문이죠.

다음 문제 해결하기 위해서는 클래스에 인스턴스가 하나만 있는지 확인하고 싱글톤 클래스 인스턴스에 전역 액세스 포인트를 할당합니다.

싱글톤 클래스에 대한 단위 테스트 케이스를 작성하는 것은 어렵습니다. 실행 순서에 따라 전역 상태에 존재하는 값이 변경될 수 있으므로 실행 순서가 중요하기 때문입니다.단위 테스트를 작성하는 동안 다른 컴포넌트나 모듈이 전역 상태 값/인스턴스를 변경할 수 있는 위험이 있습니다. 이러한 시나리오에서는 오류를 디버깅하기가 어려워집니다.

모듈의 결합을 느슨하게 해주는 의존성 주입 ( DI, Dependency Injection)을 통해 해결할 수 있다고합니다. 이는 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다 밑에처럼 DI Container처럼 해당 레이어가 이부분을 가로채서 메인 모듈이 간접적으로 의존성을 주입하는 방식입니다. 

이것이 좋은 이유는 
1. 모듈을 쉽게 교체할 수 있는 구조가 디어 테스팅이 쉽다.
2. 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어서 애플리케이션 의존성이 일관되어 추론이 쉬어진다.
3. 모듀 간의 관계들이 조금 더 명확해집니다. 

하지만 나쁜점도 있습니다. 클래스 수가 늘어났기 때문에 복잡성이 증가될 수 있고 약간의 런타임 패널티가 생깁니다. 
그리고 의존성 주입 원칙을 위반하면 안됩니다. 

High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
상위 모듈은 하위 모듈로부터 그 어떤것도 가져오면 안되며, 둘다 추상화에 의존해야합니다. 예로 인터페이스

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
추상화는 세부 사항에 의존하지 말아야하고, 세부사항은 추상화에 의존해서는 안됩니다. 

 

https://www.freecodecamp.org/news/singleton-design-pattern-with-javascript/

Singleton Design Pattern – How it Works in JavaScript with Example Code

https://en.wikipedia.org/wiki/Dependency_inversion_principle

Dependency inversion principle - Wikipedia