그리고 뭐? 아무도 말하지 않았기 때문에 : Toolbox . 전역 변수 가 필요한 경우 입니다.

다른 각도에서 문제를 살펴보면 싱글 톤 남용 을 피할 수 있습니다. 응용 프로그램에 클래스의 인스턴스가 하나만 필요하고 응용 프로그램이 시작시 해당 클래스를 구성한다고 가정 해 봅시다. 클래스 자체가 단일 클래스를 담당해야하는 이유는 무엇입니까? 응용 프로그램에 이러한 종류의 동작이 필요하기 때문에 응용 프로그램에서이 책임을 맡는 것이 상당히 논리적 인 것 같습니다. 구성 요소가 아닌 응용 프로그램은 싱글 톤이어야합니다. 그런 다음 응용 프로그램은 구성 요소의 인스턴스를 응용 프로그램 별 코드에서 사용할 수있게합니다. 응용 프로그램에서 이러한 구성 요소를 여러 개 사용하면 도구 상자라는 구성 요소로 집계 할 수 있습니다.

간단히 말해서, 응용 프로그램의 도구 상자는 자체 구성 또는 응용 프로그램의 시작 메커니즘으로 구성 할 수있는 단일 요소입니다 …

public class Toolbox {
     private static Toolbox _instance;

     public static Toolbox Instance {
         get {
             if (_instance == null) {
                 _instance = new Toolbox();
             }
             return _instance;
         }
     }

     protected Toolbox() {
         Initialize();
     }

     protected void Initialize() {
         // Your code here
     }

     private MyComponent _myComponent;

     public MyComponent MyComponent() {
         get {
             return _myComponent();
         }
     }
     ...

     // Optional: standard extension allowing
     // runtime registration of global objects.
     private Map components;

     public Object GetComponent (String componentName) {
         return components.Get(componentName);
     }

     public void RegisterComponent(String componentName, Object component)
     {
         components.Put(componentName, component);
     }

     public void DeregisterComponent(String componentName) {
         components.Remove(componentName);
     }

}

하지만 그거 알아? 싱글 톤입니다!

그리고 싱글 톤은 무엇입니까?

어쩌면 그것은 혼란이 시작되는 곳입니다.

나에게 싱글 톤 은 항상 단일 인스턴스 만 갖도록 강요 된 객체입니다. 인스턴스화 할 필요없이 언제 어디서나 액세스 할 수 있습니다. 이것이와 밀접한 관련이있는 이유 static입니다. 비교를 static위해 인스턴스가 아닌 것을 제외하고는 기본적으로 동일합니다. 우리는 그것을 자동으로 할당하기 때문에 인스턴스화 할 필요가 없습니다. 그리고 그것은 문제를 일으킬 수 있습니다.

내 경험상 staticSingleton을 간단히 교체하면 내가 사용 하고있는 중간 크기의 패치 워크 백 프로젝트에서 많은 문제가 해결되었습니다. 그것은 나쁜 디자인 프로젝트에 약간의 사용법이 있다는 것을 의미합니다. 너무 많이 있다고 생각 논의 경우 싱글 톤 패턴 입니다 유용 여부 그것은 실제로 있다면 정말 주장 할 수없는 나쁜 . 그러나 여전히 정적 방법보다 싱글 톤에 유리한 좋은 주장 이 여전히 있습니다 .

내가 확신하는 유일한 것은 싱글 톤에 대해 나쁜 것입니다. 좋은 습관을 무시하면서 싱글 톤을 사용할 때입니다. 그것은 실제로 다루기가 쉽지 않은 것입니다. 그러나 모든 패턴에 나쁜 관행을 적용 할 수 있습니다. 그리고, 나는 그것을 말하기에는 너무 일반적입니다 … 나는 그것에 너무 많은 것이 있다는 것을 의미합니다.

내가 틀리지 마!

간단히 말해,처럼 글로벌 바르 , 싱글은해야 여전히 항상 피할 수 . 특히 그들이 남용되기 때문에. 그러나 전역 변수를 항상 피할 수는 없으며 마지막 경우에 사용해야합니다.

어쨌든, 도구 상자 이외에 다른 많은 제안이 있으며 도구 상자와 마찬가지로 각 도구에는 응용 프로그램이 있습니다 …

다른 대안들

• 난 그냥 싱글에 대해 읽은 최고의 기사는 제안 서비스 로케이터를 대안으로. 나에게 그것은 기본적으로 ” 정적 도구 상자 “입니다. 다시 말해, 서비스 로케이터를 싱글 톤으로 만들면 도구 상자가 있습니다. 그것은 물론 싱글 톤을 피하겠다는 최초의 제안과 반대되지만, 싱글 톤의 문제를 강제하는 것은 패턴 자체가 아니라 그것이 어떻게 사용되는지에 달려 있습니다.

• 다른 사람들 은 공장 패턴 을 대안으로 제안 합니다. 그것은 동료로부터 들었던 첫 번째 대안이었고 우리는 전역 변수 로 사용하기 위해 신속하게 제거했습니다 . 물론 사용법도 있지만 싱글 톤도 마찬가지입니다.

위의 두 가지 대안 모두 좋은 대안입니다. 그러나 그것은 모두 당신의 사용법에 달려 있습니다.

이제 모든 비용으로 싱글 톤을 피해야한다는 것은 잘못된 것입니다 …

• Aaronaught 의 대답은 여러 가지 이유로 싱글 톤을 사용하지 말 것을 제안하고 있습니다 . 그러나 그것들은 패턴 자체에 직접적으로 영향을 미치지 않고, 악용되고 악용되는 방식에 대한 모든 이유입니다. 나는 그 점에 대한 모든 걱정에 동의합니다. 어떻게 할 수 없습니까? 오해의 소지가 있다고 생각합니다.

무능력 (추상화 또는 서브 클래스)은 실제로 존재하지만 무엇입니까? 그런 의미가 아닙니다. 더 없다 인터페이스 할 수없는 까지로, 내가 말할 수있는가 . 높은 커플 링 도있을 수 있지만 일반적으로 사용되는 방식 때문입니다. 필요하지 않습니다 . 실제로 커플 링 자체는 싱글 톤 패턴과 관련이 없습니다. 명확하게 설명하면 이미 테스트하기가 어렵습니다. 병렬화의 어려움은 언어와 플랫폼에 따라 다르므로 패턴에 문제가 없습니다.

실용적인 예

나는 종종 찬성하거나 싱글 톤에 대해 2가 사용되는 것을 본다. 웹 캐시 (내 경우) 및 로그 서비스 .

로깅은 일부 사람들이 주장 할 것이므로 완벽한 싱글 톤 예제입니다.

• 요청자는 요청을 로그에 보낼 잘 알려진 객체가 필요합니다. 이것은 글로벌 액세스 지점을 의미합니다.
• 로깅 서비스는 여러 리스너가 등록 할 수있는 단일 이벤트 소스이므로 하나의 인스턴스 만 있으면됩니다.
• 응용 프로그램마다 다른 출력 장치에 기록 할 수 있지만 리스너를 등록하는 방식은 항상 동일합니다. 모든 사용자 정의는 리스너를 통해 수행됩니다. 클라이언트는 텍스트의 로그 방법 또는 위치를 모르고 로깅을 요청할 수 있습니다. 따라서 모든 응용 프로그램은 로깅 서비스를 정확히 같은 방식으로 사용합니다.
• 모든 응용 프로그램은 로깅 서비스 인스턴스를 하나만 사용하여 벗어날 수 있어야합니다.
• 재사용 가능한 구성 요소를 포함하여 모든 객체가 로깅 요청자가 될 수 있으므로 특정 응용 프로그램에 연결해서는 안됩니다.

다른 사람들은 결국 로그 서비스가 실제로는 하나의 인스턴스가 아니라는 사실을 깨닫고 나면 로그 서비스를 확장하기가 어렵다고 주장합니다.

글쎄, 나는 두 주장이 모두 유효하다고 말한다. 여기서도 문제는 싱글 톤 패턴이 아닙니다. 리팩토링이 실행 가능한 위험이라면 아키텍처 결정과 가중치에 있습니다. 일반적으로 리팩토링이 마지막으로 필요한 수정 조치 인 경우 추가 문제입니다.

답변