[GoF 디자인 패턴] - 싱글톤 패턴

 

모든 코드는 Swift로 작성되었습니다.

 

문제 상황

데이터를 읽고 쓰는 역할을 하는 객체가 있고 코드의 여러 곳에서 이 객체를 사용한다고 가정해 보자. 각각의 코드 영역에서 이 객체의 인스턴스를 일일이 생성한다면 두 가지 문제점이 발생할 수 있다.

 

첫째, 모든 코드 영역에서 새로운 인스턴스를 계속 생성하기 때문에 메모리가 많이 사용된다.

둘째, 하나의 코드 영역에서의 작업 결과가 다른 코드 영역에 공유되지 못할 수 있다. 즉, A 코드 영역에서 데이터를 저장시켜 놨지만, B 코드 영역에서는 새로운 인스턴스를 생성했기 때문에 A 영역에서 저장시켰던 데이터에 접근할 수 없을 것이다.

 

싱글톤 패턴

싱글톤 패턴은 응용 프로그램 전체에 걸쳐 유일한 객체를 만들어 전역적으로 데이터 공유를 할 수 있게 해주는 디자인 패턴이다.

 

코드 예시

class DataStorage { // 싱글톤 객체
    static let shared = DataStorage() // 유일 객체에 접근할 수 있는 static 프로퍼티
    private var someData = 0

    private init() {} // 초기화문을 private으로 설정함으로써 유일 객체 보장

    func setData(data: Int) {
        someData = data
    }

    func getData() -> Int {
        return someData
    }
}

class A {
    func setData(data: Int) {
        DataStorage.shared.setData(data: data) 
    }
}

class B {
    func getData() {
        let data = DataStorage.shared.getData()
        print(data)
    }
}

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

a.setData(data: 2)
b.getData() // 2

 

 

장점

 

다양한 객체들에게 자신의 상태를 공유할 수 있다. 또한, 하나의 인스턴스만 생성해 재사용하므로 메모리 낭비를 방지할 수 있다.

 

 

단점

 

SOLID 원칙에 위배되는 사례가 많다. 우선 싱글톤 인스턴스 자체가 하나만 생성하기 때문에 여러 가지 책임을 지니게 되는 경우가 많아 단일 책임 원칙(SRP)을 위반하기도 하고, 싱글톤 인스턴스가 혼자 너무 많은 일을 하거나, 많은 데이터를 공유시키면 다른 클래스들 간의 결합도가 높아지게 되어 개방-폐쇄 원칙(OCP)에도 위배된다. 또한, 클라이언트 객체가 인터페이스같이 추상화된 객체가 아닌 구체 클래스를 의존하므로 의존관계 역전 원칙(DIP)에도 위배된다.

또한, 어디에서든 사용할 수 있다라는 장점이 단점이 되기도 하는데, 해당 싱글톤 객체와 관련된 작업에서 오류가 난다면 이에 대한 트러블슈팅이 어려워진다.

 

 

📌 Swift에서의 싱글톤 패턴

 

UserDefaults나 NotificationCenter, URLSession 코드를 작성하다 보면 standard, default 혹은 shared 프로퍼티를 확인해 볼 수 있다. 이 프로퍼티들은 Swift에서 제공하는 싱글톤 객체의 인스턴스를 의미하는 static 프로퍼티이다.

싱글톤 패턴의 문제점은 싱글톤 객체의 데이터 변화와 수정이 의존하고 있는 여러 객체들에게 영향을 끼친다는 것인데, 언어 자체에서 제공해 주는 싱글톤 객체의 경우 큰 문제는 발생하지 않는다. 하지만, 싱글톤 객체를 직접 만든다면 기능의 변동사항에 따라 수정이 자주 발생하지 않을 객체인지, 해당 객체가 가질 데이터의 변화가 영향력이 크진 않을지 고려해 볼 필요가 있다는 사실을 기억하자.