싱글톤, 비싱글톤 언제 써야 할까?

참고:  Pro Spring 2.5 3장

요즘 이 책을 재벌 작업을 하고 있는데 공부한지 오래되서 잊었거나 미쳐 보지 못했던 내용들이 등장하면 피로가 조금 줄어드는 느낌을 받곤 합니다.

그 중 하나가 바로 이 글의 제목과 관련된 내용이었습니다. 스프링을 가지고 웹 애플리케이션을 몇 번 만들어 봤지만 singleton 스코프 빼곤 별로 써본 기억이 나질 않을 정도인데 새삼 생각해보게 하는 내용들이 있었습니다.

싱글톤이 적절한 경우
– 상태가 없는 공유 객체
– 읽기 전용 상태를 가지고 있는 공유 객체
– 상태를 공유하는 공유 객체
– 쓰기가 가능한 상태를 약간 가지고 있으면서 매우 빈번하게 사용하는 객체

비싱글톤이 적절한 경우
– 쓰기가 가능한 상태를 가진 객체
– private 상태를 가지고 있는 객체

여기서 주목해야 할 것은 같은 쓰기 가능한 상태를 가진 객체인데 어느것은 싱글톤 어느 것은 비싱글톤이 적절하다는 부분인데 동기화 비용과 객체 생성 비용을 가지고 나누더군요.

자세한 내용은 프로 스프링 2.5 번역서를 참고하세요~ ㅋㅋㅋ

9 thoughts on “싱글톤, 비싱글톤 언제 써야 할까?”

  1. 싱글턴은 장점보다 단점이 훨씬 큰데,
    싱글턴을 쓰지 말자는게 아니라
    적절한 경우를 나열한 책이 있다니 사실에 움찔했습니다.

    적절하다고 예로든 경우에도 MonoState 패턴이 더 적절하다고 생각합니다.

    1. 스프링의 싱글톤 스코프와 디자인패턴에서 말하는 싱글톤 패턴을 같은 것이라고 오해하신 것 같군요.
      스프링은 기존 싱글톤 패턴의 문제를 극복하기 위해서 싱글론 레지스트리라는 방식으로 싱글톤 개념을 적용합니다. 이를 이용하면 싱글톤 패턴과 같은 방식을 사용하지 않은 단순한 자바 클래스를 싱글톤 “개념”으로 사용할 수 있습니다.

    2. 싱글톤 패턴의 문제라 함은?
      – 인터페이스를 사용하지 못 함.
      – 구현체 교체하기 힘듬
      – 따라서 테스트 하기도 힘듬.
      이런 것일듯..

    3. 싱글톤도 인터페이스 사용할 수 있습니다.
      그러니 구현체 교체도 힘들지 않구요.

      다만 싱글톤 자체를 상속하여
      Subtyping 하는것에 문제가 생겨서
      재사용성과 확장성을 보장하기 힘들다는것이
      문제가 아닐까 싶습니다.

Leave a Reply

Your email address will not be published. Required fields are marked *