정의를 외웠는지가 아니라 전역 상태·테스트 격리·DI 환경에서의 위치까지 같이 보는지를 가르려는 질문이다.
싱글턴은 클래스 인스턴스를 하나로 강제하고 전역 접근점을 제공하는 패턴이다. 객체 생성을 막아 자원 공유와 접근 편의를 얻지만, 그 대가로 전역 상태가 생기고 호출부가 구체 타입에 직접 묶인다. 결국 "하나만 있어야 하는가"보다 "누구의 책임이고 어떻게 갈아끼울 수 있는가"가 더 중요한 결정이 된다.
싱글턴 객체에 들고 있던 캐시/플래그 때문에 테스트가 순서에 따라 깨졌던 경험이 있다면 격리 전략과 연결할 수 있다
직접 구현하던 싱글턴을 스프링 빈으로 옮기면서 `getInstance()` 호출을 걷어낸 경험을 결합도 이야기로 풀 수 있다
지연 초기화에서 동시성 버그를 만나 DCL이나 `enum`/Initialization-on-demand 홀더로 갈아치운 과정을 설계 판단 근거로 쓸 수 있다
전역으로 굳어진 클라이언트를 인터페이스로 분리해 테스트에서 페이크로 대체했던 경험을 의존성 역전 사례로 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.