답변.

싱글톤 패턴은 애플리케이션에서 단일 인스턴스만 존재하는 객체를 생성하는 인기 있는 기술입니다. 스위프트에서는 정적 속성과 스레드 안전성 지원 덕분에 패턴 구현이 간소화되었습니다.

질문의 역사:

Objective-C에서 싱글톤 구현은 스레드 안전성과 관련된 긴 코드가 필요했습니다. 스위프트에서는 정적 속성의 지연 초기화 덕분에 이 문제가 해결되었습니다.

문제점:

싱글톤은 애플리케이션 상태에 중앙 집중적으로 접근하는 데 자주 사용되나(예: 세션, 구성, 서비스), 잘못 사용하면 암묵적인 의존성과 코드의 테스트 가능성이 저하됩니다.

해결책:

스위프트에서는 정적 상수를 통해 패턴을 구현합니다. 이는 스레드 안전성과 단일성을 보장합니다:

코드 예:

final class Logger {
    static let shared = Logger()
    private init() {}

    func log(_ message: String) {
        print(message)
    }
}

Logger.shared.log("싱글톤 작업 예시")

주요 특징:

static let 사용은 스레드 안전성을 보장합니다 (한 번만 생성됨)
private init()은 직접 인스턴스를 생성할 수 없게 합니다
전역 범위를 가집니다

함정 질문들.

모든 애플리케이션 서비스에 대해 항상 싱글톤을 사용해야 할까요?

아니요. 싱글톤은 진정한 글로벌 상태(예: ApplicationSettings)에 적용되는 것이 올바르지만, 비즈니스 로직 서비스에는 잘못된 선택입니다: 긴밀한 결합 및 단위 테스트 문제를 야기할 수 있습니다.

static let이 스위프트에서 싱글톤의 스레드 안전한 초기화를 보장하나요?

네, 스위프트 1.2부터(static let의 아키텍처로 인해), static let은 본질적으로 스레드 안전합니다 - 스레드 경쟁이 있어도 한 번만 초기화됩니다.

싱글톤은 상속될 수 있나요?

아니요. 상속 문제를 피하기 위해 클래스를 final로 선언하는 것이 좋습니다 - 그렇지 않으면 서로 다른 상속 클래스의 두 인스턴스가 생성될 수 있으며, 이는 패턴의 기본 아이디어를 위반합니다.

일반적인 실수 및 안티 패턴

모든 것에 싱글톤을 사용하는 것, 이는 나쁜 아키텍처로 이어집니다
싱글톤에서 데이터 캡슐화를 위반하는 것
static let이 아닌 암묵적 초기화, 수동으로 싱글톤 생성

현실 사례

부정적인 케이스

네트워크 작업 서비스가 싱글톤으로 구현되어 있으며, 메소드들이 글로벌 상태를 사용합니다. 단위 테스트에서 암묵적인 의존성이 발생하여 서비스를 재사용할 수 없습니다.

장점:

간단한 통합, 빠른 연결

단점:

테스트 가능성이 없음, 유지보수가 어렵고, '마법' 의존성이 있음

긍정적인 케이스

싱글톤은 진정으로 글로벌한 개체 - 예를 들어 ApplicationConfig에만 사용됩니다. 모든 서비스는 명시적 인젝터를 통해 의존성을 받습니다.