singleton pattern (싱글톤 패턴)
하나의 클래스가 하나의 인스턴스만 가지는 패턴.
하나의 클래스를 이용해 여러번 인스턴스화를 시켜 여러 인스턴스를 가질 수 있지만,
그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스만 만드는 것입니다.
장점
- 인스턴스 생성 비용 감소
- 한 번 생성하여 여러 모듈이 공유해 사용하기 때문에 생성 비용이 줄어드는 장점이 있다.
단점
- 의존성 상승
- 여러 모듈이 같은 데이터를 공유해 사용하기 때문에 의존성이 상승하는 단점이 있다.
- DI(Dependency Injection, 의존성 주입)을 통해 결합도를 낮출 수 있다.
- 메인 모듈이 직접 하위 모듈에 의존성을 주지 않고, 중간에 의존성 주입자를 두어 메인 모듈이 간접적으로 의존성을 주입하는 방식 (Factory를 사용!)
- 원칙 : "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다. 또한, 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 한다."
- 장점 : 모듈간 관계가 명확해지므로 테스팅 및 마이그레이션에 용이
- 단점 : 모듈이 분리되 클래스 수가 증가하므로 복잡도가 증가할 수 있다. 런타임시 성능에도 불리하다.

- TDD(Test Driven Development)에서의 어려움
- 각 테스트가 독립적이어야 하지만, 하나의 인스턴스를 기반으로 구현하는 패턴이므로
'독립적인' 인스턴스를 만들기 어렵다.
- 각 테스트가 독립적이어야 하지만, 하나의 인스턴스를 기반으로 구현하는 패턴이므로
응용 분야 및 예제
- 데이터베이스 연결 모듈
- ex. 어떠한 프로그램의 캐시나 로그를 가지고 관리하는 객체가 있다. 매번 새롭게 생성해 사용할 경우, 같은 프로그램임에도 불구하고 다른 데이터를 가지게 된다. 즉, 싱글톤 객체가 필요한 경우이다.
예제 코드 (Kotlin)
class GeneralClass() | |
object Singleton1 | |
class Singleton2 private constructor() { // 외부에서 일반 생성자로 생성하지 못하도록 함 | |
companion object { | |
private val instance: Singleton2 = Singleton2() | |
fun getInstance() = instance | |
} | |
} | |
fun main(args: Array<String>) { | |
val generalClass_first: GeneralClass = GeneralClass() | |
val generalClass_second: GeneralClass = GeneralClass() | |
println(generalClass_first.hashCode()) | |
println(generalClass_second.hashCode()) | |
println("GeneralClass instances is equal: ${generalClass_first == generalClass_second}\n") | |
val singleton1_first: Singleton1 = Singleton1 | |
val singleton1_second: Singleton1 = Singleton1 | |
println(singleton1_first.hashCode()) | |
println(singleton1_second.hashCode()) | |
println("Singleton1 instances is equal: ${singleton1_first == singleton1_second}\n") | |
val singleton2_first: Singleton2 = Singleton2.getInstance() | |
val singleton2_second: Singleton2 = Singleton2.getInstance() | |
println(singleton2_first.hashCode()) | |
println(singleton2_second.hashCode()) | |
println("Singleton2 instances is equal: ${singleton2_first == singleton2_second}\n") | |
} | |
/* | |
531885035 | |
1418481495 | |
GeneralClass instances is equal: false | |
135721597 | |
135721597 | |
Singleton1 instances is equal: true | |
1826771953 | |
1826771953 | |
Singleton2 instances is equal: true | |
*/ |
* object : 클래스를 정의함과 동시에 객체를 생성하는 것
정의와 동시에 생성되므로 객체(인스턴스)가 한 번만 생성되도록 할 수 있음.
* companion object (동반 객체) : 클래스를 인스턴스화 하지 않고, 사용할 수 있도록 함
참고
[kotlin] Companion Object (1) - 자바의 static과 같은 것인가? - Bsidesoft co.
개요 코틀린(Kotlin)의 Companion object는 단순히 자바(Java)의 static 키워드를 대체하기 위해서 탄생했을까요? 이 갑작스러운 질문은 코틀린에서 왜 static을 안 쓰게 되었는지 이해하는 데 큰 도움이 될
www.bsidesoft.com
- 이렇게도 쓸 수 있다!
https://korean-otter.tistory.com/229
[android] Context를 가지는 객체를 singleton으로 관리하기
아래의 코드들을 실행시키기 위한 MainActivity.kt와 activity_main.xml 더보기 class MainActivity : AppCompatActivity() { private val settingSwitch: SwitchCompat by lazy { findViewById(R.id.notification_setting_switch) } private val settingTv
korean-otter.tistory.com
궁금증
- 응용분야에 데이터베이스라 적었는데, 데이터베이스에서는 왜 많이 사용되는지 이 부분은 잘 모르겠다...
'CS note > 디자인 패턴, 프로그래밍 패러다임' 카테고리의 다른 글
MVC pattern (Model View Controller) (0) | 2023.04.30 |
---|---|
strategy pattern (전략 패턴) (1) | 2023.01.27 |
factory pattern (팩토리 패턴) (0) | 2023.01.25 |
디자인 패턴 및 프로그래밍 패러다임 (0) | 2023.01.20 |
댓글