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

싱글톤 패턴 (Singleton Pattern)

• 하나의 클래스에 오직 하나의 인스턴스 만 가지는 패턴
• 데이터베이스 연결 모듈에 많이 사용
• 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용
• 인스턴스 생성 비용이 줄어듦
• 동시성(Concurrency) 문제를 고려해야 함

싱글톤 패턴을 사용하는 이유

• 최초 한 번만 인스턴스를 생성하여 고정된 메모리 영역을 사용하기 때문에, 메모리 낭비 방지
• 이미 생성된 인스턴스를 활용해 속도가 빠름
• 싱글통 인스턴스가 전역으로 사용되기 때문에, 다른 클래스 간에 데이터 공유가 쉬움
• 인스턴스가 절대적으로 한 개만 존재하는 것을 보증하고 싶은 경우에 사용

싱글톤 패턴의 단점

• 싱글톤 인스턴스가 혼자 너무 많은 일을 하거나, 많은 데이터를 공유시킬 경우에 다른 클래스들 간의 결합도가 높아져 개방-폐쇄 원칙이 위배
  • 객체 지향 설계 원칙 (SOLID)
  • 단일 책임 원칙 (Single Responsiblity Principle): 모든 클래스는 각각 하나의 책임만 가져야 하며, 클래스는 그 책임을 완전히 캡슐화해야 함
  • 개방-폐쇄 원칙 (Open Closed Principle): 기존의 코드를 변경하지 않으면서(Closed), 기능을 추가할 수 있도록(Open) 설계가 되어야 한다는 원칙
  • 리스코프 치환 원칙 (Liskov Substitution Principle): 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙
  • 인터페이스 분리 원칙 (Interface Segregation Principle): 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 함, 하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스가 나음
  •  의존 역전 원칙 (Dependency Inversion Principle): 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 것
• 객체 지향 설계 원칙에 어긋나기 때문에 수정이 어려워지고 유지보수 비용 증가
• 멀티 스레드 환경에서 동기화 처리를 하지 않으면 인스턴스가 2개가 생성되는 문제도 발생 가능
• 자원을 서로 공유하고 있기 때문에 독립적이지 않아 TDD(Test Driven Development)를 할 때 어려움
• 자식클래스를 만들 수 없다는 점과, 내부 상태를 변경하기 어렵다는 점 등
• 따라서, 반드시 싱글톤이 필요한 상황이 아니면 지양하는 것이 좋음

 

의존성 주입(DI, Dependency Injection)

• 모듈 간의 결합을 느슨하게 만들기 위해 사용하는 방법
  • 의존성(종속성): A가 B에 의존성이 있다는 것은 B의 변경사항에 대해 A 또한 변해야 된다는 것을 의미
• 메인 모듈(main module)이 직접 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자(dependency injector)가 대신 의존성 주입
• 메인모듈이 간접적으로 의존성 주입
• 메인모듈(상위 모듈)은 하위 모듈에 대한 의존성 감소 

의존성 주입의 장점

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

의존성 주입의 단점

• 모듈들이 더욱 분리되기 때문에 클래스 수가 증가해 복잡성 증가
• 런타임 페널티 발생

의존성 주입의 원칙

• 상위 모듈은 하위모듈에서 어떤 것도 가져오지 않아야 함
• 둘 다 추상화에 의존해야 하며, 추상화는 세부 사항에 의존하지 말아야 함