GOF 싱글 톤 패턴에 대한 실행 가능한 대안이 있습니까?

현실을 직시하자. 싱글 톤 패턴은 매우 논쟁 에 무리 프로그래머와 주제 모두 울타리의 측면. Singleton이 더 이상 영광스러운 전역 변수라고 느끼는 사람들과 패턴으로 맹세하고 그것을 끊임없이 사용하는 사람들이 있습니다. 그러나 나는 싱글 톤 논쟁 이 내 질문의 핵심에 놓여있는 것을 원하지 않습니다 . 누구나 줄다리기를하여 전투를 벌일 수 있으며 내가 관심을 갖는 모든 것을 누가이기는지 볼 수 있습니다. 제가 말하려는 것은 정답이 하나 있다고 믿지 않으며 의도적으로 당파 적 논쟁을 불러 일으키는 것도 아닙니다. 나는 질문을 할 때 단순히 단일 대안에 관심이 있습니다 .

GOF 싱글 톤 패턴에 대한 특정 대안이 있습니까?

예를 들어, 과거에 싱글 톤 패턴을 여러 번 사용했을 때 저는 단순히 하나 또는 여러 변수의 상태 / 값을 보존하는 데 관심이 있습니다. 그러나 변수의 상태 / 값은 단일 패턴을 사용하는 대신 정적 변수 를 사용하여 클래스의 각 인스턴스화 사이에 보존 될 수 있습니다 .

다른 아이디어가 있습니까?

편집 : "싱글 톤을 올바르게 사용하는 방법"에 대한 또 다른 게시물이되기를 원하지 않습니다. 다시 말하지만 나는 그것을 피할 방법을 찾고 있습니다. 재미로 알았지? 나는 당신의 최고의 영화 예고편 목소리로 순수하게 학문적 인 질문을하고있는 것 같습니다. "싱글 톤이없는 평행 우주에서 우리는 무엇을 할 수 있습니까?"

" Patterns I Hate "의 Alex Miller 는 다음을 인용합니다.

"싱글 톤이 답처럼 보일 때 다음과 같은 것이 더 현명한 경우가 많습니다.

1. 인터페이스 및 싱글 톤의 기본 구현 생성
2. 시스템의 "상단"에 기본 구현의 단일 인스턴스를 생성합니다. 이것은 Spring 구성 또는 코드에 있거나 시스템에 따라 다양한 방식으로 정의 될 수 있습니다.
3. 필요한 각 구성 요소에 단일 인스턴스 전달 (종속성 주입)

Singleton을 해결하는 적절한 방법을 이해하려면 Singleton (및 일반적으로 전역 상태)의 문제점을 이해해야합니다.

싱글 톤은 종속성을 숨 깁니다.

그게 왜 중요할까요?

종속성을 숨기면 커플 링 양을 추적하지 못하는 경향이 있기 때문입니다.

당신은

void purchaseLaptop(String creditCardNumber, int price){
  CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
  Cart.getInstance().addLaptop();
}

보다 간단합니다

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart, 
                    String creditCardNumber, int price){
  creditCardProcessor.debit(creditCardNumber, amount);
  cart.addLaptop();
}

하지만 적어도 두 번째 API는 메소드의 공동 작업자가 무엇인지 정확히 알려줍니다.

따라서 Singleton을 해결하는 방법은 정적 변수 또는 서비스 로케이터를 사용하는 것이 아니라 Singleton 클래스를 인스턴스로 변경하는 것입니다. IoC 프레임 워크를 사용하여이를 처리하거나 수동으로 수행 할 수 있지만 중요한 것은 전역 상태를 제거하고 종속성 및 공동 작업을 명시 적으로 만드는 것입니다.

내가 찾은 최고의 솔루션은 팩토리 패턴을 사용하여 클래스의 인스턴스를 구성하는 것입니다. 패턴을 사용하여 다음을 수행 할 수 있습니다 확신 을 사용하는 객체간에 공유되는 클래스의 하나의 인스턴스 만이 있음.

관리하기가 복잡 하겠지만이 블로그 게시물 "모든 싱글 톤이 사라진 곳은 어디입니까?" , 너무 자연스러워 보입니다. 그 외에도 단위 테스트를 분리하는 데 많은 도움이됩니다.

요약하면 무엇을해야합니까? 객체가 다른 객체에 종속 될 때마다 생성자를 통해서만 인스턴스를받습니다 (클래스에 새 키워드 없음).

class NeedyClass {

    private ExSingletonClass exSingleton;

    public NeedyClass(ExSingletonClass exSingleton){
        this.exSingleton = exSingleton;
    }

    // Here goes some code that uses the exSingleton object
}

그리고 공장.

class FactoryOfNeedy {

    private ExSingletonClass exSingleton;

    public FactoryOfNeedy() {
        this.exSingleton = new ExSingletonClass();
    }

    public NeedyClass buildNeedy() {
        return new NeedyClass(this.exSingleton);
    }
}

팩토리를 한 번만 인스턴스화하므로 exSingleton의 단일 인스턴스화가 있습니다. buildNeedy를 호출 할 때마다 NeedyClass의 새 인스턴스가 exSingleton과 함께 번들로 제공됩니다.

이게 도움이 되길 바란다. 실수가 있으면 지적 해주세요.

Spring이나 다른 IoC-Container는 그 점에서 상당히 좋은 일을합니다. 클래스는 앱 자체 외부에서 생성 및 관리되기 때문에 컨테이너는 간단한 클래스 싱글 톤을 만들고 필요한 곳에 삽입 할 수 있습니다.

패턴을 피하기 위해 길을 잃지 않아도됩니다. 패턴의 사용은 디자인 결정이거나 자연스러운 적합성입니다 (단지 제자리에 있음). 시스템을 설계 할 때 패턴을 사용하거나 사용하지 않도록 선택할 수 있습니다. 그러나 궁극적으로 디자인 선택이되는 것을 피하려고해서는 안됩니다.

저는 싱글 톤 패턴을 피하지 않습니다. 적절하고 내가 사용하거나 적절하지 않고 사용하지 않습니다. 그렇게 간단하다고 생각합니다.

Singleton의 적절성 (또는 부족)은 상황에 따라 다릅니다. 설계 결정을 내려야하며 그 결정의 결과를 이해하고 문서화해야합니다.

Monostate (Robert C. Martin의 Agile Software Development에 설명 됨)는 singleton의 대안입니다. 이 패턴에서 클래스의 데이터는 모두 정적이지만 getter / setter는 정적이 아닙니다.

예를 들면 :

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if(m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate는 singleton과 비슷한 동작을하지만 프로그래머가 singleton이 사용되고 있다는 사실을 반드시 인식하지 못하는 방식으로 작동합니다.

싱글 때 상황이 있기 때문에 패턴이 존재 하나의 객체가 일련의 서비스를 제공하기 위해 필요하다 .

이 경우에도 인스턴스를 나타내는 전역 정적 필드 / 속성 을 사용하여 싱글 톤을 만드는 접근 방식을 여전히 고려하고 있습니다. 정적 필드와 개체가 제공하는 서비스가 아닌 개체 간의 코드에 종속성을 생성하기 때문에 부적절합니다.

따라서 고전적인 싱글 톤 패턴 대신 serviced container 와 함께 서비스 'like'패턴을 사용하는 것이 좋습니다 . 여기서 정적 필드를 통해 싱글 톤을 사용하는 대신 필요한 서비스 유형을 요청하는 메서드를 통해 참조를 얻습니다.

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

단일 글로벌 대신

*pseudocode* singletonType.Instance

이런 식으로 객체의 유형을 싱글 톤에서 다른 것으로 변경하고 싶을 때 쉽게 할 수 있습니다. 또한 추가적인 이점으로 모든 메서드에 할당 된 개체 인스턴스를 전달할 필요가 없습니다.

또한 Inversion of Control을 참조하십시오 . 아이디어는 단일 항목을 소비자에게 직접 노출함으로써 개체가 제공하는 개체 서비스가 아닌 소비자와 개체 인스턴스간에 종속성을 생성한다는 것입니다.

제 의견은 싱글 톤 패턴의 사용을 가능한 한 숨기는 것입니다. 왜냐하면 항상 피할 수 없거나 바람직하지는 않기 때문입니다.

Singleton을 사용하여 단일 데이터 개체를 나타내는 경우 대신 데이터 개체를 메서드 매개 변수로 전달할 수 있습니다.

(하지만 처음에는 이것이 Singleton을 사용하는 잘못된 방법이라고 주장합니다)

문제가 상태를 유지하려는 것이라면 MumbleManager 클래스가 필요합니다. 시스템 작업을 시작하기 전에 클라이언트는 MumbleManager를 생성합니다. 여기서 Mumble은 시스템의 이름입니다. 이를 통해 상태가 유지됩니다. MumbleManager에는 상태를 보관하는 속성 모음이 포함될 가능성이 있습니다.

이러한 유형의 스타일은 매우 C와 비슷하고 객체처럼 느껴지지는 않습니다. 시스템을 정의하는 객체는 모두 동일한 MumbleManager에 대한 참조를 갖게 될 것입니다.

일반 개체와 팩토리 개체를 사용하십시오. 팩토리는 구성 정보 (예 : 포함) 및 동작으로 만 인스턴스 및 일반 개체 세부 정보를 관리합니다.

실제로 Singelton을 피하면서 처음부터 바로 디자인하면 정적 변수를 사용하여 Singleton을 사용하지 않는 문제를 해결할 필요가 없습니다. 정적 변수를 사용할 때 어느 정도 Singleton을 생성하고 있지만 유일한 차이점은 다른 객체 인스턴스를 생성한다는 것입니다. 그러나 내부적으로는 모두 Singleton을 사용하는 것처럼 작동합니다.

Singleton을 사용하는 곳이나 현재 Singleton이 사용되고 있고 사용을 피하려고하는 곳의 자세한 예를 들어 줄 수 있습니까? 이것은 사람들이 싱글 톤없이 상황을 처리 할 수있는 더 멋진 해결책을 찾는 데 도움이 될 수 있습니다.

BTW, 저는 개인적으로 Singletons에 문제가 없으며 다른 사람들이 Singleton에 대해 가지고있는 문제를 이해할 수 없습니다. 나는 그들에 대해 나쁜 것이 없습니다. 즉, 학대하지 않는 경우입니다. 모든 유용한 기술은 남용 될 수 있으며 남용 될 경우 부정적인 결과를 초래할 수 있습니다. 일반적으로 잘못 사용되는 또 다른 기술은 상속입니다. 아직도 어떤 사람들이 끔찍하게 남용하기 때문에 상속이 나쁘다고 말하는 사람은 아무도 없습니다.

개인적으로 싱글 톤처럼 동작하는 것을 구현하는 훨씬 더 현명한 방법은 완전히 정적 클래스 (정적 멤버, 정적 메서드, 정적 속성)를 사용하는 것입니다. 대부분의 경우 이런 방식으로 구현합니다 (사용자 관점에서 행동 차이는 생각할 수 없습니다)

싱글 톤을 감시하는 가장 좋은 장소는 클래스 디자인 수준이라고 생각합니다. 이 단계에서 클래스 간의 상호 작용을 매핑 할 수 있어야하며 응용 프로그램 수명 중 언제든지이 클래스의 인스턴스가 하나만 존재하는 것이 절대적으로 필요한지 확인해야합니다.

그렇다면 싱글 톤이 있습니다. 코딩하는 동안 편의상 싱글 톤을 던지는 경우 실제로 디자인을 다시 방문하고 해당 싱글 톤 코딩을 중지해야합니다. :)

그리고 예, '경찰'은 '피하다'라기보다 여기서 의미하는 단어입니다. 싱글 톤은 피해야 할 것이 아닙니다 (goto 및 전역 변수가 피할 것이 아닌 것과 같은 방식으로). 대신 사용을 모니터링하고 원하는 작업을 효과적으로 수행 할 수있는 최상의 방법인지 확인해야합니다.

나는 상태가 전혀없는 "메소드 컨테이너"로 주로 싱글 톤을 사용합니다. 이러한 메서드를 많은 클래스와 공유해야하고 인스턴스화 및 초기화의 부담을 피하려면 컨텍스트 / 세션을 만들고 모든 클래스를 초기화합니다. 세션을 참조하는 모든 것은 포함 된 "싱글 톤"에도 액세스 할 수 있습니다.

강렬한 객체 지향 환경 (예 : Java)에서 프로그래밍하지 않았기 때문에 논의의 복잡함을 완전히 이해하지 못했습니다. 하지만 저는 PHP 4에서 싱글 톤을 구현했습니다. 자동으로 초기화되고 불완전하고 다소 손상된 프레임 워크에서 함수 호출을 위아래로 전달할 필요가없는 '블랙 박스'데이터베이스 핸들러를 만드는 방법으로 수행했습니다.

싱글 톤 패턴의 일부 링크를 읽었지만 다시 동일한 방식으로 구현할 것인지 완전히 확신 할 수 없습니다. 정말로 필요한 것은 공유 스토리지 (예 : 실제 데이터베이스 핸들)가있는 여러 개체였으며 이것이 제가 호출 한 결과입니다.

대부분의 패턴 및 알고리즘과 마찬가지로 싱글 톤을 사용하는 '그냥 멋지다'는 The Wrong Thing To Do입니다. 싱글 톤처럼 보이는 진정한 '블랙 박스'호출이 필요했습니다. 그리고 IMO는 질문을 해결하는 방법입니다. 패턴을 인식하고 더 넓은 범위와 인스턴스가 고유해야하는 수준을 살펴보십시오.

무슨 말이야, 그걸 피하는 내 기술이 뭐야?

이를 "피하려면"싱글 톤 패턴이 자연스럽게 잘 맞는 상황이 많이 발생하고 있으므로 이러한 상황을 완화하기 위해 몇 가지 조치를 취해야합니다.

그러나 없습니다. 싱글 톤 패턴을 피할 필요가 없습니다. 단순히 발생하지 않습니다.