
싱글톤 패턴은 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴이다. 이 패턴은 주로 전역 상태를 관리하거나 자원의 중복을 방지하고 싶을 때 사용됩니다.
예를 들어 네트워크 매니저, 데이터 베이스 연결 객체 등은 애플리케이션 전체에서 하나의 인스턴스로만 존재해야합니다.
여러 인스턴스가 생성된다면 리소스를 낭비하거나, 데이터를 일관성 있게 유지하는 것이 어려울 수 있습니다.인스턴스의 유일성 보장
-클래스 인스턴스가 하나만 존재합니다.
전역 접근
-프로그램 어디서나 동일한 인스턴스를 접근할 수 있습니다.
지연 초기화
-필요할 때까지 인스턴스를 생성하지 않아 메모리 사용을 최적화하 수 있습니다.
전역 상태를 관리할 때
-사용자의 로그인 상태나 애플리케이션 설정 등 앱 전체에서 일관된 상태를 관리해야 할 때
공유 자원을 관리할 때
-네트워크 연결, 파일 입출력, 데이터베이스 접근 등 여러 클래스에서 동시에 접근하는 자원을 중앙에서 관리하고 싶을 때
비용이 큰 객체의 중복 생성을 방지할 때
-초기화 비용이 크거나 메모리 사용량이 큰 객체를 여러번 생성하는 것을 방지하고 싶을 때
public class Singleton {
// 1. 유일한 인스턴스
private static Singleton instance = new Singleton();
// 2. 생성자 private
private Singleton() {}
// 3. 인스턴스 반환 메서드
public static Singleton getInstance() {
return instance;
}
}
Singleton s1 = Singleton.getInstance();
Singleton s2 = Singleton.getInstance();
System.out.println(s1 == s2); // true (같은 객체)
싱글톤 패턴은 편리하지만 잘못 사용하면 유지보수와 테스트면에서 어려움을 초래할 수 있습니다.
의존성 주입의 어려움
-싱글톤 객체는 전역적으로 사용되기 때문에 테스트 시에 모킹을 사용하기 어렵습니다.
과도한 전역 상태 사용
-전역적으로 접근 가능한 객체가 많아지면 코드의 의존성이 높아지고 버그 발생 가능성이 증가합니다.
멀티스레드 환경에서의 안정성
-스레드 안전한 싱글톤 구현이 필요할 수 있습니다. static let은 기본적으로 스레드 안전성을 제공하므로 대부분의 경우 안전하지만 추가적인 고려가 필요할 수 있습니다.
