우리는 shared, standard, defaults와 같은 어떤 클래스 뒤에 property로 따라오는 것들을 많이 볼 수 있다. 이러한 클래스들은 Singleton pattern을 활용해 만들었다. Singleton Pattern이 뭐길래 이 클래스들은 인스턴스 생성도 따로 안하고 쓰는걸까?
Singleton?
Singleton은 하나의 class에 하나의 instance를 만들어야 한다는 규칙을 적용한 디자인 패턴이다. Singleton을 사용해서 class의 전역적으로 접근 가능한 공유 instance를 제공할 수 있다. 위에서 언급한 URLSession.shared 같은 HTTP 용청을 수행하기 위한 네트워크 관리자나 앱 전체에서 공유되는 리소스 또는 서비스에 대한 통합 액세스 지점을 제공하는 방법으로 싱글톤을 사용한다.
static 타입 프로퍼티를 사용하여 간단한 싱글톤을 생성할 수 있다. 동시에 여러 스레드에서 접근해도 한 번만 지연 초기화되는 것이 보장된다.
class Singleton {
static let shared = Singleton()
}만약 초기화 이상의 추가적인 설정을 수행해야 한다면, 전역 상수에 클로저 호출 결과를 할당할 수 있다. \\ setup code 부분에 추가적인 설정을 작성하면 된다.
class Singleton {
static let shared: Singleton = {
let instance = Singleton()
// setup code
return instance
}()
}해당 init()을 통해 추가적인 instance 생성을 막고싶은 경우, init() 함수 접근 제어자를 private으로 지정해줄 수도 있다.
class Singeton {
//
private init() {}
}주의 사항
디자인 패턴의 경우 보통 각각의 장단점이 존재한다. Singleton pattern도 마찬가지다.
단위 테스트를 할 때, singleton 객체는 전역 상태이기 때문에 테스트 간의 상태 전이 문제가 발생할 수 있다. 이 문제는 테스트의 결과가 이전 테스트의 실행 결과에 영향을 받는 현상으로, 테스트의 신뢰성을 떨어뜨릴 수 있다.
Singleton 객체를 참조하기 위해 정적 메소드를 호출하는 경우, 애플리케이션의 전반적인 구조를 복잡하게 만들 수 있다. 다른 클래스에서 singleton 객체의 정적 메소드를 호출하면 전역 상태를 변경하는데 사용될 수 있다.
Singleton은 특정 상황에서는 매우 유용하지만, 사용하기 전에 그 장단점을 고려하고 적합한지 여부를 신중하게 판단해야 한다. Singleton 패턴을 사용할 때는 전역 상태를 최소화하고, 전역 상태를 변경하는 코드는 최소화하는 것이 좋다. 이를 통해 테스트 간의 상태 전이 문제를 방지하고 코드의 복잡성을 줄일 수 있다.
결론
singleton 패턴을 이용해 코드를 작성할 경우, 전역 상태와 전역 상태를 변경하는 코드르 최소화하는 것이 중요하다. 그리고 내가 싱글톤 패턴을 작성하지 않더라도, .default나 .shared와 같이 우리가 써야할 많은 코드들에 이미 구현되어있기때문에 알고있는 것도 상당히 유용할 것 같다. 단위 테스트를 해야할 때 좀더 유의해서 할 수 있고, 나아가서 이 코드의 구조를 좀더 쉽게 파악할 수 있기 때문이다.
싱글톤 패턴 관련하여 추가로 보면 좋은 글
