싱글턴 패턴과 스프링 프레임워크

 

싱글턴 패턴

싱글턴 패턴이란 애플리케이션 내에서 하나의 클래스는 하나의 인스턴스만을 가지도록 강제하는 패턴이다.

하나의 클래스에서 하나의 인스턴스만을 가지므로 해당 인스턴스를 전역변수처럼 사용하여 접근하기 용이하고 인스턴스 개수를 조절할 수 있다.

 

구현

싱글턴 패턴은 생성자의 레벨을 private이나 protected로 두어 숨기고

static 메서드 (e.g. getInstance())를 통해서 인스턴스를 생성하는 식으로 구현될 수 있다. 

 

예시

추상 팩토리, 팩토리 메서드, 빌더, 프로토 타입과 같은 패턴에서 싱글턴 패턴을 사용할 수 있으며

Logging이 가장 대표적인 싱글턴 패턴을 사용하는 예시이다.

 

싱글턴 패턴은 안티 패턴이다.

싱글턴 패턴을 이용하여 인스턴스를 전역 상태(Global state)에서 제어할 수 있는 방법을 얻었지만 그에 따라 다음과 같은 여러 가지 문제점이 발생했다.

 

전역 상태를 가짐

전역 상태를 가지는 것 자체가 OOP 측면에서 바람직하지 않다. 어디서나 접근이 가능하고 어디서나 값이 변경될 수 있는 상태는 변경 가능 지점을 늘어나게 하고 멀티 스레드 환경에서 동시성 문제가 발생할 여지가 있다.

또한 어떤 문제가 발생하여 문제를 분석할 때 어디서나 접근하여 디펜던시를 주입할 수 있기때문에 이를 분석하는 것이 더 복잡하고 어려워지는 문제가 발생할 수 있다.

 

단일 책임 원칙 위배

싱글턴 자체의 책임을 수행할 뿐만 아니라 하나의 인스턴스만 생성됨을 제어하는 책임까지 수행하므로 SRP 원칙을 위배한다고 볼 수 있다.

e.g. static getInstance() 메서드를 통해 생성하는 경우.

 

유닛 테스트의 어려움

싱글턴 패턴은 유닛 테스트하기 쉽지 않다. 유닛 테스트를 진행하기 위해서는 루즈 커플링이 필요한데, 싱글턴은 static 메서드나 생성자를 통해 생성되기 때문에 그것의 생성을 제어할 수 없게 되고 타이트한 커플링을 통해 생성하게 되기 때문이다.

생성을 제어할 수 없으므로 mocking을 하는데에 있어서도 문제가 발생한다.

 

스프링 프레임워크

위와 같은 문제들을 계속 겪으면서 선대의 프로그래머들은 다음과 같은 생각을 하게 된다.

'그냥 인스턴스의 생성만을 담당하는 클래스가 하나 있으면 되는거 아닌가?'

 

이때 등장하는 것이 스프링 프레임워크이다. 

스프링 프레임워크의 IoC는 레지스트리 패턴으로 동작하여 클래스를 미리 등록해두고 필요할때 명시적으로 주입받는 식으로 사용하게 된다.

 

이와 같은 방식을 통해 전역 상태를 가지는 것으로 인한 변경 지점이 많아지는 문제점과 디펜던시 주입 문제를 해결할 수 있게 되었다.

또한 인스턴스 개수의 제어라는 Responsibility를 스프링 프레임워크가 넘겨받음으로써 SRP 문제도 해결이 되었고 

미리 생성된 클래스의 인스턴스를 주입받음으로써 커플링 문제와 mocking 문제도 해결되게 된다.

 

결론

traditional한 싱글턴 패턴과 그에 다른 한계점, 그리고 그것을 해결하기 위한 스프링 프레임워크의 탄생까지 알아보았다.

 

해당 개념의 공부를 통해 singleton == IoC라고 알고 있던 오개념을 바로잡을 수 있었다.

 

레퍼런스

https://stackoverflow.com/questions/16744424/whats-the-difference-between-singleton-and-registry-design-pattern

What's the difference between Singleton and Registry design pattern

 

https://en.wikipedia.org/wiki/Singleton_pattern#:~:text=In%20software%20engineering%2C%20the%20singleton,coordinate%20actions%20across%20the%20system.

Singleton pattern - Wikipedia