[스위프트 디자인패턴] 싱글톤 패턴(Singleton Pattern)

싱글톤 패턴(Singleton Pattern)

The singleton pattern ensures a class has only one instance and provides a global point of access to it.

오늘은 항상 논란의 중심에 있는 싱글톤 패턴에 대해서 정리해보겠습니다..! 싱글톤 패턴은 객체의 인스턴스가 한 번 만들어진 이후에는 해당 객체에 대한 새로운 인스턴스가 절대 만들어지지 않도록하는 디자인 패턴입니다. 그리고 모든 영역에서 해당 인스턴스에 접근이 가능하도록 합니다.

 

싱글톤 패턴의 원리

싱글톤 패턴의 핵심은 단 하나의 인스턴스만 처음에 생성하고, 새로운 인스턴스를 생성할 수 없도록 하는 것에 있습니다. 그럼 어떻게 할 수 있을까요?

먼저 새로운 인스턴스를 생성할 수 없게 해야하기 때문에 반드시 생성자를 외부로부터 숨겨야 합니다. 이건 private 접근제어자를 사용하면 쉽게 구현할 수 있겠죠.

import Foundation

class Singleton {
    private init() {}
}

이렇게 private으로 생성자를 숨기면, 외부에서 인스턴스를 생성하려고 할 때 다음과 같이 컴파일 에러가 발생합니다.

이제 외부에서 새로운 인스턴스는 절대 새로 생성할 수 없습니다. 대신 단 하나의 인스턴스를 생성할 수 있도록 해야하는데요, 이를 위해서 내부 생성자에 접근할 수 있도록 타입 프로퍼티를 이용할 수 있습니다.

class Singleton {
    static let shared = Singleton()
    
    private init() {}
}

타입 저장 프로퍼티는 lazy한 특성을 가지기 때문에 가장 처음 shared 변수를 호출할 때, 싱글톤 인스턴스가 생성되어서 shared에 저장되죠. 그리고 shared는 let 키워드와 함께 선언되었기 때문에 새로운 인스턴스를 할당할 수 없습니다. 따라서 저장된 싱글톤 인스턴스를 계속해서 사용하기 때문에 shared를 통해 항상 하나의 인스턴스에 접근하여 사용하게 됩니다.

class Singleton {
    static let shared = Singleton()
    var state = true
    
    private init() {}
}

class A {
    let singleton = Singleton.shared
    
    func printState() {
        print(singleton.state)
    }
    
    func updateState() {
        singleton.state.toggle()
    }
}

class B {
    let singleton = Singleton.shared
    
    func printState() {
        print(singleton.state)
    }
    
    func updateState() {
        singleton.state.toggle()
    }
}

let a = A()
let b = B()

a.printState() // true
b.printState() // true
a.updateState()
a.printState() // false
b.printState() // false

그럼 이렇게 하나의 인스턴스를 여러 객체에서 공유하면서 사용할 수 있게 됩니다.

 

싱글톤은 안티 패턴?

싱글톤 패턴은 자주 안티 패턴으로 불리는데요, 논란의 핵심은 단지 싱글톤 패턴이 하나의 인스턴스를 만들기 때문이 아니라 전역에서 싱글톤 인스턴스에 접근해 상태를 바꿀 수 있다는 점입니다. 프로그램 내부에 있는 모든 코드가 인스턴스의 상태를 변경할 수 있고, 이런 특징은 개발자가 인지하지 못하는 순간에 인스턴스의 상태가 변경될 수 있음을 의미합니다.

단 하나의 인스턴스를 만드는 부분도 문제가 없는게 아니에요. 만약 어떤 프로그램에서 하나의 객체만을 사용하다가 같은 기능을 하는 객체의 인스턴스가 구분되어서 필요하다면 어떨까요? 동일한 기능을 하는 새로운 객체를 정의하는 것은 말이 되지 않겠죠. 그렇다면 싱글톤으로 작성된 객체를 수정해주어야 하는데, 그럼 이 인스턴스에 접근하는 모든 영역의 코드를 수정해주어야 하는 상황이 발생합니다. 즉, 개발자가 이후에 싱글톤 인스턴스가 아니라 여러개의 인스턴스를 만들어야 하는 상황이 생긴다면 최악의 상황이 발생하게 되는 것이죠.

따라서, 해당 객체가 반드시 하나의 인스턴스만 가지는 것이 확실하다면 싱글톤 패턴을 선택해도 되겠지만, 일반적으로 100% 확신을 가질 수는 없기 때문에 싱글톤 패턴은 권장되지 않습니다. 싱글톤 패턴은 새로운 인스턴스를 만들 수 없도록 하니까요.

 

마무리

아마 디자인 패턴 포스트 중 가장 짧은 포스트가 되지 않을까 싶네요ㅎㅎ

싱글톤 패턴은 굉장히 편하다는 생각을 많이 하곤 해요. 상태도 어디서든 공유가 되고, 인스턴스를 이리저리 전달할 필요도 없구요. 하지만 이후에 프로그램이 언제든지 확장될 수 있다는 점에서 생각해보면, 조금은 복잡하고 번거롭더라도 인스턴스에 대한 접근을 스코프 단위로 제한하고 여러개의 인스턴스를 생성할 수 있게 하는 게 더 좋겠죠. 무조건 싱글톤을 배척해야한다는 것은 절대 아니지만 사용에 있어서 충분히 주의를 기울여야하는 디자인 패턴인 것 같습니다!

오늘도 읽어주셔서 감사합니다!