[기록] Singleton Pattern을 사용할 것인가에 대하여

[SH0123]

배경

Repository Pattern을 사용한 것에 대하여 위의 글과 같이 Repository Pattern 구현에 대해 고민을 하며 많은 글과 코드들을 살펴봤다. 이 과정에서 Repository 객체를 싱글톤으로 구현한 경우를 많이 볼 수 있었다. 싱글톤의 장, 단점을 파악하고 나도 싱글톤을 사용하면 좋은 상황인지 판단할 수 있도록 공부해봐야겠다는 생각을 했다.

고민사항

• 싱글톤의 단점이 무엇이고 그것을 극복할만한 장점이 있는가
• Thread-safe의 문제에 대해 생각해보자
• DB를 관리하는 객체의 경우 싱글톤이 좋다는 얘기를 들었는데 왜 그럴까?

내 생각

싱글톤 패턴의 단점에 관해

싱글톤 패턴의 단점은 싱글톤 객체에 접근하는 객체를 알 수 없다는 것, 추적하기 어렵다는 것, 단위 테스트가 어렵다는 것이다. 또한 상태를 가진 객체를 싱글톤으로 만드는 경우 전역적으로 접근하여 객체의 상태를 변경시킬 여지가 있는데 이는 위험하기 때문에 무상태 객체에서 싱글톤을 만드는 것이 권장된다.
하지만 작은 규모의 앱을 만들고 있는 시점에서 이러한 부분에 대해 직접 경험하지 못해 이해하기 어렵다.
그렇기에 코드의 규모를 키워나가며 이러한 단점을 직접 겪어보고 어떤 대안을 통해 해결해나갈 수 있을지 작성해보려 한다.

Thread-safe의 문제에 대해

Java로 싱글톤 패턴을 작성하는 경우 thread safety의 문제로 인해 다양한 방법을 이용해 thread-safety를 보장할 수 있는 싱글톤 코드를 작성해야한다. 하지만 swift의 static let은 thread-safety를 보장하기 때문에 사용하는데 있어서 문제가 되지 않는다.

DB 관리 객체의 경우 싱글톤이 좋은가?

데이터베이스 커넥션풀 객체를 만들 때 싱글톤을 많이 사용한다.
JDBC와 같은 경우 DB와 연결하기 위해 Connection 객체를 생성하는 작업의 비용이 매우 크기 때문에 싱글톤으로 만들어 메모리에 로드 시키고 여러 객체에서 사용한다. DB 커넥션 풀은 공통된 객체를 여러곳에서 사용하기에 싱글톤 패턴을 주로 사용한다. 현재 이미 coredata 접근 객체가 싱글톤이어서 문제 없지만 추후 DB를 변경하는 경우 해당 DB에 Connection 할 때 위의 장점들을 활용하기 위해 싱글톤으로 구현해보려한다.

Repository 객체를 만들 때 결합도를 낮춰 싱글톤의 단점을 보완해보자

Repository 객체가 다른 객체에 드러내는 interface와 Repository 내부에서만 사용하는 변경 가능성이 많은 구현부를 분리해보자.
이를 통해 싱글톤 객체를 리팩토링 할 때의 영향도를 객체 자체에 한정하고, 다른 객체까지로의 변경이 퍼져나가는 것을 제어해보자. 또한 객체 내부에 외부에서 접근 가능한 상태를 없애거나 최소화하여 외부 객체와의 공유 상태를 만들지 않도록 하자.

[SH0123]

Reference

Shared Instance vs Singleton

• 한글 번역본
• 영문 What's the difference between a singleton and a shared instance in Swift?

Singleton Pattern (with Swift)

• 싱글톤 패턴
• 싱글톤 패턴과 Thread-safe
• 스위프트에서의 싱글톤 동작 이해하기
• Swift globals and static members are atomic and lazily computed
• The Power of Two: Combining the Singleton and Repository Design Patterns to Improve Data Access
• Thread-safe singletons and their usage in Swift

Singleton Pattern pros and cons

• Are Singletons Bad
• 싱글톤 패턴의 단점과 대안
• 싱글톤 패턴과 문제점

static let의 atomicity와 thread_safe

• Thread-Safety in Swift 기록