이 패턴은 애플리케이션 전체에서 클래스의 단일 인스턴스를 유지 관리하고 접근하도록 하는 목표는 달성하지만, 결합도가 증가하게 됩니다. 애플리케이션 코드에서 인스턴스를 가져오려면 어떻게 싱글턴 클래스의 인스턴스를 얻어야 하는지를 잘 알고 있어야 합니다. 즉, 인터페이스를 사용한 코딩이 불가능합니다.

실제로 싱글턴 패턴은 두 개의 패턴이 하나로 합쳐진 것입니다. 이 패턴에서 첫 번째로 필수적인 내용은, 이 패턴은 클래스가 단일 인스턴스로 동작하도록 관리한다는 것입니다. 두 번째로 인터페이스를 완전히 사용할 수 없는 객체 룩업을 위한 패턴이라는 것입니다. 싱글턴 패턴을 사용하면 싱글턴 인스턴스를 필요로 하는 대부분의 객체가 싱글턴 객체에 직접 접근하기 때문에 임의로 구현을 변경하기 어렵습니다. 테스트할 때 싱글턴을 목(mock) 클래스로 대체할 수 없으므로 애플리케이션을 단위 테스트로 한다면 머리가 많이 아플 수도 있습니다.

다행스럽게도 스프링을 사용하면 싱글턴 디자인 패턴을 사용하지 않고도 싱글턴 인스턴스 생성 모델을 활용할 수 있습니다. 스프링의 모든 빈은 기본적으로 싱글턴 인스턴스로 생성되며, 스프링은 해당 빈에 대한 모든 요청을 동일한 인스턴스를 사용해 수행합니다. 물론 스프링에 싱글턴 인스턴스만 사용하도록 제한이 있는 것은 아닙니다. 모든 의존성을 주입받거나 getBean()을 호출해 빈의 인스턴스를 가져올 때마다 새로운 빈 인스턴스를 생성할 수도 있습니다. 스프링의 인스턴스 생성 방식은 애플리케이션 코드에는 아무런 영향을 주지 않으므로 스프링에서는 모든 인스턴스 생성 방식을 사용할 수 있다고 할 수 있습니다. 이것은 강력한 개념입니다. 만약에 싱글턴이 멀티 스레드 접근에 실제로 적합하지 않다고 생각된다면, 애플리케이션 코드에 영향을 주지 않으면서 싱글턴이 아닌 타입(프로토타입)으로 변경할 수 있습니다.