오늘의 CS(디자인 패턴 - 싱글톤 패턴)

1. 디자인 패턴이란?

• 디자인 패턴은 프로그래밍에서 자주 발생하는 문제를 해결하기 위한 효과적인 방법이다. 이해하기 쉽게 말하자면, 레고 블록을 생각해보자. 레고 블록은 서로 다른 모양과 크기를 가지고 있다.. 이 블록들을 조합하면 다양한 물건이나 건물을 만들 수 있다. 디자인 패턴도 이렇게 프로그래밍 문제를 해결하는 데 도움이 되는 틀이다.
• 디자인 패턴은 많은 사람들이 이미 사용해본 아이디어들이기 때문에, 다른 사람들이 이해하기도 쉽고, 코드가 더 깔끔해진다. 예를 들어, 초등학생들이 수학 문제집을 풀 때, 같은 유형의 문제를 여러 번 풀면서 더 잘 이해하고 해결할 수 있다. 디자인 패턴도 비슷하다. 프로그래머들이 이 패턴을 사용하면, 비슷한 문제를 더 쉽게 해결할 수 있다.

1.1.1 싱글톤 패턴

• 싱글톤 패턴은 특별한 종류의 디자인 패턴이다. 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다. 이해하기 쉽게 설명하려면, 학교의 교장 선생님을 예로 들어보자. 학교에는 교장 선생님이 한 명만 있다. 교장 선생님은 학교의 중요한 역할을 담당한다. 만약 학교에 교장 선생님이 여러 명이라면, 일이 복잡해지고 혼란스럽다.
• 이런 상황을 프로그래밍 세계에서도 찾을 수 있다. 때로는 프로그램에서 어떤 기능이나 정보를 하나만 갖고 있어야 할 때가 있다. 이럴 때 싱글톤 패턴을 사용하면 된다. 싱글톤 패턴은 프로그램에서 특정한 것을 딱 한 개만 만들어서 사용하게 해주는 디자인 패턴이다. 이렇게 싱글톤 패턴을 사용하면 프로그램이 더 깔끔하고 혼란 없이 작동할 수 있다. 결국 학교에서 교장 선생님이 한 명인 것처럼, 프로그램에서도 어떤 것을 한 개만 사용할 때 싱글톤 패턴이 큰 도움이 된다.
• 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다. 하지만 의존성이 높아진다는 단점이 있다. 

const obj = {
   a: 3
};

const obj2 = {
   a: 3
};

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

• 위의 그림처럼 리터럴 {} 또는 new Object로 객체를 생성하게 되면 다른 어떤 객체와도 같지 않아서 이 자체만으로 싱글톤 패턴을 구현할 수 있다. 

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


}

const b = new Singleton();
const c = new Singleton();

// true
console.log(b === c)

• b와 c가 같은 객체를 가리키기 때문에 b === c가 true가 된다. 
• 위에 절차를 간략하게 설명하면 처음에 클래스에 instance 속성이 없으면 this를 instance에 할당한다. 
• 그렇게 되면 this는 새로 생성되는 Singleton 객체를 가리킨다
• Singleton.instance를 반환하게 되고 첫 번째 인스턴스를 생성할 때는 Singleton.instance가 this와 같은 새로 생성된 객체를 가리킨다.
• 그래서 b는 인스턴스에 아무값도 없으니 새로운 객체를 생성하고 instance에 할당한 다음에 
• const c에서 new SIngleton()를 실행하면 이미 값이 존재하니까 바로 Singleton.instance를 반환하고 결국 둘 다 동일한 객체를 가리키고 있으므로 b === c는 true가 된다.

 

싱글톤 패턴의 단점

• 싱글톤 패턴은 TDD(Test Driven Development)를 할 때 문제가 된다. 주로 TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 한다.
• 여기서 잠깐 TDD는 무엇일까?
  • TDD는 소프트웨어 개발 방법론 중 하나로, 테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 구현하는 방식 즉, 코드를 작성하기 전에 테스트를 먼저 만들고, 이 테스트를 통과할 수 있도록 코드를 작성한다. 쉽게 설명하면 위에서 디자인 패턴 설명할 때 예시로 쓴 레고를 가지고 설명하겠다
  • TDD는 세 가지 단계가 있다. 
    • 1. 계획 세우기(빨강): 먼저 모형을 만들기 전에 어떻게 만들 것인지 계획을 세운다. 이 계획은 마치 안전한 레고 블록 모형을 만들기 위한 "검사 목록"과 같다
    • 2. 블록 쌓기(초록): 계획한 대로 레고 블록을 하나씩 쌓아가면서 모형을 만든다. 이때 검사 목록에 있는 항목들이 제대로 되고 있는지 확인한다.
    • 3. 개선하기(리팩토링): 모형이 완성되면, 더 나은 모양이나 안정성을 위해서 블록을 바꾸거나 조정한다. 이때도 검사 목록을 확인해서 모형이 계속 안전한지 확인해야 한다. 
  • 장점
    • 코드의 신뢰성이 높아진다. 테스트를 먼저 작성하고 코드를 개발해서, 코드에 대한 검증이 철저히 이루어진다.
    • 이미 테스트 케이스가 존재해서 코드를 개선하거나 변경할 때 즉 리팩토링 할 때 안전하게 작업할 수 있다. 
    • 코드의 가독성과 유지 보수성이 좋아진다. 테스트 케이스가 잘 작성되어 있으면, 코드의 기능과 동작 방식을 이해하기 쉽다.

 

• 의존성 주입
  • 싱글톤 패턴은 사용하기 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있다. 이때 의존성 주입을 통해 모듈 간의 결합을 조금 더 느슨하게 만들 수 있다. 

 

• 의존성 주입이란?
  • 쉽게 말해 의존성 주입자라는 중간자를 세워서 메인 모듈이 어떤 정보를 직접 제공하는 것이 아니고 간접적으로 제공하고 중간자를 통해서 정보를 제공한다. 이렇게 하면 메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 되고 이를 전문 용어로 디커플링 된다고 한다.

 

• 의존성 주입의 장점
  • 프로그램이 더 유연해지고, 나중에 수정하기도 쉬워진다.
  • 모듈을 쉽게 교체할 수 있는 구조가 되어 테스팅하기도 쉽고 마이그레이션(이전)하기도 수월하다. 의존성 방향이 일관되고 모듈 간의 관계들이 좀 더 명확해지고 애플리케이션을 쉽게 추론할 수 있다. 

 

• 의존성 주입의 단점
  • 모듈들이 더욱더 분리되므로 클래스 수가 늘어나 코드의 복잡성이 증가할 수 있다. 싱글톤 객체를 전달하는 과정이 추가되기 때문에 코드가 길어지고, 이해하기 어려워질 수도 있다. 

 

• 의존성 주입 원칙
  • 객체지향 설계 원칙 중 하나로, 의존 관계를 맺는 클래스들 사이에서 유연한 구조를 만들기 위한 원칙이다. 두 가지 원칙이 존재한다.
    • 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다. 이때 추상화를 통해 의존성이 제공되어야 한다.  
    • 둘 다 추상화에 의존해야 한다. 구체적인 구현체에 의존하지 말고 추상 클래스와 같은 추상화에 의존해야 한다.