싱글 톤은 실제로 그렇게 나쁜 것인가? [복제]

기억해야 할 핵심은 디자인 패턴은 추상적 개념을 이해하는 데 도움이되는 도구 일뿐입니다. 일단 당신이 그 이해를 가지고 있다면, 책에서 "조리법"으로 당신 자신을 제한하는 것은 무의미하며, 목적에 가장 적합한 코드를 작성하는 능력에 상처를줍니다.

즉, GoF와 같은 책을 읽으면 문제에 대해 생각할 수있는 더 많은 방법을 제시 할 것이므로 시간을내어 무언가를 구현하면 문제에 접근 할 수있는 더 넓은 관점을 갖게 될 것입니다.

귀하의 경우, 싱글 톤을 사용하여 모든 경우에 의미가 있다면, 바로 앞에 가십시오. "일종의"종류의 제품이라면 그 제품을 다소 어색한 방식으로 구현해야합니다. 그런 다음 새로운 솔루션을 찾아야합니다. 완벽하지 않은 패턴을 강요하는 것은 원형 구멍에 사각형의 못을 치는 것과 같습니다.

"이 접근법은 효과적이었고 우리 상황에 매우 실용적이었습니다."라고 말하면 나는 잘하고 있다고 생각합니다.

다음은 좋은 책입니다.

네 권의 책- 고전적인 디자인 패턴의 책

헤드 퍼스트 디자인 패턴- 나는 이것을 대안으로 몇 사람들이 추천한다고 들었다.

• 정말 고마워요 !!! 이 모든 책자를 꼭 받아보고 그 책을 통해 작업 해 보겠습니다. " Gang of Four Book "에 대해 들었습니다. 어딘가에. - josef.van.niekerk
• GoF 책의 대부분은 훌륭하지만, 싱글 톤 주제에 관해서는, 나는 그들이 불법적 인 것을 흡연했을 것임을 진심으로 생각한다. 그 중 하나, 또는 OOP ( "이봐 요, 당신도 OOP에서 전역을 만들 수 있습니다! 우리는 단지 그것들을 싱글 톤이라고 부릅니다")을 통해 오래된 절차 형 프로그래머 (실제 전역을 원함)에게 양보했습니다. - jalf
• 그래, jalf가 말한 것에서 두 번째로, 싱글 톤을 글로벌 변수의 단지 oop 버전으로 사용하는 것에주의한다. - Simon P Stevens
• 싱글 톤은 항상 재 입력 할 수없는 코드의 부호이며, 대부분의 경우 그것은 테스트 할 수없는 코드의 표시이기도합니다. 유지 관리 측면이 중요하지 않을 때 시장 진출 시간을 단축하면서 정당화 될 수 있습니다. c ++에서 유효한 싱글 톤 유스 케이스로 간주되는 로거조차도 클래스가 소멸자에서 로깅되고 싱글 톤 로거가 이미 사라질 때 응용 프로그램이 중단 될 수 있습니다. - bobah

예, 싱글 톤은 좋지 않습니다. 그들은 당신이하는 모든 일이 95 %의 시간에 나쁜 두 가지 속성을 결합하기 때문에 나쁜 것입니다. (이것은 평균적으로 싱글 톤은 시간의 99.75 %가 나쁘다는 것을 의미합니다)))

GoF가 정의한 싱글 톤은 다음과 같은 데이터 구조입니다.

1. 개체에 대한 전역 액세스를 허용하고
2. 객체의 인스턴스 하나만 존재할 수 있음을 강요합니다.

첫 번째 것은 일반적으로 나쁜 것으로 간주됩니다. 우리는 전역을 좋아하지 않습니다. 두 번째는 좀 더 미묘하지만 일반적으로 이것이 합리적인 제한 인 경우는 거의 없습니다.억지로 시키다.

때로는 객체의 하나의 인스턴스 만 갖는 것이 타당합니다. 어떤 경우에는 하나만 만들도록 선택합니다. 그것을 시행하는 데 싱글 톤이 필요하지 않습니다.

그리고 보통 하나의 인스턴스만을 갖는 것이 "이해된다"고하더라도 대개 결국은 이해가되지 않습니다. 조만간에 하나 이상의 로거가 필요할 것입니다. 또는 하나 이상의 데이터베이스. 또는 각각의 단위 테스트에 대한 리소스를 다시 만들어야합니다. 즉, 원하는대로 단위 테스트를 만들 수 있어야합니다. 우리가 결과를 이해하기 전에 코드에서 유연성을 조기에 제거하고 있습니다.

싱글 톤은 의존성을 숨기고 결합을 증가시킵니다 (모든 클래스는 잠재적으로 싱글 톤에 의존 할 수 있습니다. 즉, 우리가 모든 싱글 톤을 재사용하지 않는 한 다른 프로젝트에서 클래스를 재사용 할 수 없음을 의미합니다.) 이러한 종속성은 함수 / 생성자 매개 변수 ), 우리는 그들을 알아 채지 못하며, 일반적으로 우리가 그것을 창조 할 때 생각하지 않습니다. 싱글 톤을 끌어 들이기가 너무 쉽습니다. 로컬 변수와 거의 모든 역할을합니다. 그래서 일단 거기에있게되면 많이 사용하는 경향이 있습니다. 그리고 그것은 그것들을 거의 제거하는 것을 거의 불가능하게 만듭니다. 아마도 스파게티 코드가 아닌 스파게티 의존성 그래프가 나타날 것입니다. 조만간 종속성은 싱글 톤이 서로에 따라 시작된다는 것을 의미하며, 초기화가 시도 될 때 순환 종속성을 얻습니다.

그들은 단위 테스트를 매우 어렵게 만듭니다. (싱글 톤 객체에서 함수를 호출하는 함수를 테스트하려면 어떻게해야합니까? 실제 싱글 톤 코드가 실행되는 것을 원하지 않지만 어떻게 방지 할 수 있습니까?

예, 싱글 톤은 좋지 않습니다.

때때로, 당신은 정말로 글로벌를 원합니다. 그런 다음 싱글 톤이 아닌 글로벌을 사용하십시오.

때로는 매우 드물게 클래스의 여러 인스턴스를 만드는 것이 오류 일 수 있습니다.양철통오류가 발생하지 않고 완료되지 않습니다. (내가 생각할 수있는 유일한 경우에 대해서만 고안된 것입니다. 하드웨어 장치를 대표 할 때입니다. 하나의 GPU 만 있으므로 코드의 객체에 매핑하면 하나의 인스턴스 만 존재할 수 있음을 의미합니다). 그러나 이러한 상황에서 자신을 발견하면 (여러 가지 인스턴스가 "하나 이상의 인스턴스에 대한 사용 사례를 생각할 수없는"심각한 상황이 아닌 심각한 오류를 일으키는 상황) 객체를 전역 적으로 표시하지 않고도 수행 할 수 있습니다.

이 두 가지 속성 각각양철통드문 경우이지만 유용 할 수 있습니다. 그러나 나는 하나의 사건을 생각할 수 없다.콤비네이션그들 중 좋은 것이 될 것입니다.

불행히도 많은 사람들이 "싱글 톤은 OOP 호환 전역입니다."라는 생각을 가지고 있습니다. 아니야, 그들은 그렇지 않아. 그들은 여전히 세계와 같은 문제를 겪고 있으며,게다가완전히 다른 무언가를 소개하는 것까지. 평범한 구식 세계에 비해 싱글 톤을 선호 할 이유는 전혀 없습니다.

• 싱글 톤을 적용하는 것이 중요한 아이디어 인 경우가 수없이 많습니다. 데이터베이스 연결 풀을 생각해보십시오. 이미 사용 가능한 연결이있을 때 연결을 열어 두 개의 별도 풀을 필요로하지 않습니다. - Kekoa
• 내 단위 테스트에서 두 개의 별도 풀을 사용해야하는 이유는 무엇입니까? 별도의 데이터베이스로 두 개의 별도 풀을 사용해야하는 이유는 무엇입니까? 서로 굶주 리지 않아도되는 두 가지 작업이있는 경우 왜 두 개의 별도 풀을 원하나요? 하나의 작업은 자체 풀에있는 모든 연결을 먹을 수도 있으므로 다른 것을 위해 일부를 예약하고 싶습니다. 하지만해야 할 것절대적으로 긍정적으로 오직 하나의 수영장을 원한다. 왜 그것을 시행하기 위해 싱글 톤이 필요합니까? 너는 종종우윤히새 연결 풀을 만드시겠습니까? 당연히 아니지. 너만 필요하다면, 그냥몹시 떠들어 대다하나. - jalf
• +1 더 좋았습니다. 정확히 동료 동료를 어떻게 느끼고 교육 시키는가. 많은 점들이 모노 스테이트 패턴과 글로벌 스태틱 메소드의 (ab) 사용에도 적용됩니다. - gix
• 문제 1은 코드 전체에 뿌린 후에는 수정하기가 어렵 기 때문에 실제 킬러입니다. - starblue
• @user 다른 측면은 동료의 상식이 아마도 당신만큼 좋을 것입니다. 하나의 인스턴스가 존재하도록하려는 객체를 작성했습니다. 그는 두 번째 사례를 만들었습니다. 너 누구야?그는 틀렸다.? 그는 예상하지 못한 두 번째 인스턴스를 만드는 것이 타당한 상황에 직면했습니다. 그것이 싱글 톤 이었다면 당신의 동료는 그가 생각한 것을 할 수 없었을 것입니다. 나의 주장은 "두 번째 사례가 존재해야 하는가?"이다. 수업이있을 때만 합리적으로 결정할 수있는 결정입니다.익숙한원래 디자인되었을 때가 아닙니다. - jalf

소프트웨어 개발자는 이상적인 코딩 스타일을 선호하는지 실용적인 코딩 스타일을 선호하는지에 따라 꽤 균등하게 두 개의 캠프로 나뉘는 것처럼 보입니다.

• 이상적 :못싱글 톤 패턴을 사용하십시오.
• 바쁜:기피싱글 톤 패턴.

개인적으로 나는 실용적인 접근 방식을 선호한다. 때로는 규칙을 어기는 것이 맞지만, 실제로하고있는 일을 실제로 이해하고 관련 위험을 기꺼이 받아들이는 경우에만 가능합니다. 특정 유스 케이스와 관련하여 아래 질문에 "예"라고 대답 할 수 있다면, 싱글 톤 패턴은 실질적인 이점을 얻을 수 있습니다.

• 싱글 톤은 앱 외부에 있습니까? 데이터베이스, 대기열 서비스 및 ESB는 모두 싱글 톤 패턴의 완벽하게 유효한 매크로 예제입니다.
• KISS : 전체 앱을 2-3 내부 싱글 톤으로 제한합니까?
• DRY : 이러한 싱글 톤은 본질적으로 전체적인 것이므로 앱의 거의 모든 객체에 대한 참조가 필요합니까? (예 : 로거 또는 구성 요소 조정자)?
• 귀하의 싱글 톤은 서로 및 / 또는 운영 환경에만 의존합니까?
• 메모리 관리 고려 사항을 포함하여 각 싱글 톤에 대해 적절한 시작 및 종료 시퀀스를 보장 했습니까? 예를 들어, "Grand Central"스타일 스레드 풀은 main ()에서 인스턴스 Run () 및 Shutdown () 메소드를 필요로하므로 작업 대상 객체가 유효한 상태에있을 때만 작업이 실행되도록 보장 할 수 있습니다.

• 싱글 톤 중독을 사회적으로 받아 들일 수있는 좋은 방법. "나는 그것들을 피한다, 나는 그것들을 의미가있는 곳에 만 사용한다". 아니, 아니야. 자신의 설명을 통해, 대체로 적은 양의 작업 만 필요할 때 언제 어디서나 사용할 수 있습니다. 그 구별은 "이상 주의적" 와 "실용주의"사이에 있지만, 누가사실은싱글 톤을 피하려고 노력한다.필요한 것내 데이터베이스 연결을위한 싱글 톤), 그리고말하다그들은 "피한다" 그 (것)들, 진짜로 다만 의미 할 때 " 나는 나가 그것을 생각한 " 할 것이다 적당한 일 " - jalf
• @ 요점은 열린 마음을 유지하고, 어떤 싱글 톤이 좋으며, 무엇이 좋지 않은지에 대해 교육을 받고, 바로 옆에있는 작업에 적합한 도구를 선택하는 것입니다. 필자의 철학은 개발자가 충분히 방어 할 수있는 한 모든 디자인 패턴을 사용할 수 있다는 것입니다. C #세계에서와 마찬가지로, 다음과 같은 것들을 사용하는 것이 냄새라고 생각합니다.unsafe과goto대다수의 경우에는 두 가지 모두 반핵 빈 (semi-frequent)으로 .NET 자체의 소스 코드에서 사용됩니다. 모든 옵션의 장단점을 알고 있지만 여전히 싱글 톤을 사용하기로 결정하면 완벽하게 정상적으로 작동합니다. - Abion47
• 개발자의 능력과 사고 방식에 대한 내 마음 속에 뭔가가못완료, 기간, 토론의 끝. 나에게 그것은 개발자가 특정 사고 방식에 빠져 있다고 말하면서 경쟁이 치열 해지고 진화하는 소프트웨어 개발의 세계를 따라갈 수있을만큼 유연하지 않을 것이라고 염려합니다. 유창한 기술과 규칙을 사용하여 개발 팀을 지배 한 사람들에 대한 이야기가 너무 많아서 고려하지 않은 채로 변경 사항에 대해 논의하지 않았습니다. - Abion47

싱글 톤은 프로그램을 죽이지 않고 프로그래머는 프로그램을 죽입니다.

어떤 프로그래밍 구조와 마찬가지로, 적절하게 사용될 때, 발에서 자신을 쏘지 않을 것입니다.

추천 도서는 괜찮지 만, 싱글 톤을 사용하도록 선택할 수있는 경험이있는 충분한 배경을 제공하지는 않습니다.

그 경험은 Singleton이 여러 인스턴스를 가질 필요가있을 때 Singleton이 나쁜 선택이라는 것을 알았을 때만 나타납니다. 갑자기 모든 곳에서 객체 참조를 주입하는 데 많은 어려움이 있습니다.

때로는 앞서 가서 객체 참조를 제자리에 두는 것이 더 좋지만, Singleton을 전혀 사용하지 않는다는 사실은 다른 디자인으로 리팩터링해야하는 경우 직면하게 될 문제의 범위를 식별하는 데 도움이됩니다. 제가 믿는 것은 아주 좋은 것입니다. 즉, 수업을 제대로하지 못하는 경우라도 수업에 변화의 효과를 볼 수있는 능력을 부여합니다.

우리는 기본적으로 같은 질문에 직면 해있는 프로젝트를 시작했습니다. 즉,모델에 액세스, 특히 루트 요소. 이 프로젝트는 플렉스 앱이 아니라 연극입니다! 웹 응용 프로그램,하지만 그건 중요하지 않습니다.

가있는단일 객체 고유시스템에 문제가 없습니다.그것을 액세스하는 방법. 따라서 싱글 톤에 대한 논쟁은의존성 주입(DI) 및 객체를 얻는 방법에 대해 설명합니다.

DI에 대한 주요 논거는 다음과 같습니다.

• 테스트 가능성 및 조롱
• 객체 인스턴스화를 사용에서 분리 (라이프 사이클 관리로 이어질 수 있음)
• 관심사의 분리

DI에 대한 가능한 접근법은 다음과 같습니다 (고전조파울러 출신) :

• 메서드 매개 변수에서 객체를 전달하는 방법
• 서비스 위치 지정자
• DI 프레임 워크

이 관점에서, 싱글 톤 패턴은 단지 서비스 로케이터의 일종이다.Model.getInstance().

그러나 미래의 변화에 직면 할 때 최대한의 유연성을 제공하기 위해서는 고유 한 객체에 대한 참조가 있어야합니다.돌아 다니다가능한 한 많이Model.getInstance()필요할 때만. 이렇게하면 더 깔끔한 코드도 생성됩니다.

• 참조를 전달하는 데 추가로 많은 배관 공사가 필요하지 않습니까? - kgriffs
• ... 특히 로깅과 같이 사실상 모든 단일 구성 요소 / 클래스가 사용할 것인가? - kgriffs

제 생각에는 싱글 톤 (Singleton)을 사용하면 디자인 결함을 직접 알 수 있습니다. 그 이유는 단순히 C ++에 내장 된 정상적인 객체 생성 및 파괴 메커니즘을 우회 할 수 있도록하기 위해서입니다. 객체가 다른 객체에 대한 참조를 필요로하는 경우, 객체는 작성시 객체에 대한 참조를 전달하거나 내부적으로 새 인스턴스를 생성해야합니다. 그러나 싱글 톤을 사용하면 생성 및 해체 사이클을 명백하게 모호하게 만듭니다. 관련 문제는 싱글 톤의 수명을 제어하는 것이 극히 어렵다는 것입니다. 결과적으로 일반 싱글 톤 구현을 포함하는 많은 패키지에는 clunky object lifetime manager 등이 포함됩니다. 때로는 이들이 싱글 톤을 관리하기 위해 존재하지 않는지 궁금합니다.

기본적으로 여러 위치에서 객체를 사용해야하는 경우 스택의 가장 높은 공통점에서 명시 적으로 만들어야하며 객체를 사용하는 모든 사용자에게 참조를 통해 전달되어야합니다. 때때로 사람들은 새로운 스레드에 여러 arg를 전달하는 데 문제가 있기 때문에 Singleton을 사용하지만이 경우에는 떨어지지 않고 명시 적으로 스레드 args를 정의한 다음 같은 방식으로 새 스레드에 전달합니다. 프로그램이 훨씬 더 깨끗하게 흐르고 정적 초기화 종속성 또는 잘못된 분해로 인한 불쾌한 놀라움이 없다는 것을 알 수 있습니다.

싱글 톤은 당연히 나쁘지 않습니다. 그들은 용도가 좋으며, 그중 일부는 아주 좋습니다. 싱글 톤은 경험이 부족한 개발자가 종종 배우는 첫 번째 디자인 패턴이기 때문에 남용되는 경향이 있으며 매우 간단하므로 그 의미에 대해 생각하지 않고 모든 곳에서 사용합니다.

싱글 톤을 사용하고 싶을 때마다 왜이 패턴을 사용하는지, 그리고이 패턴을 사용할 때의 이점과 부정적인 점을 고려하십시오.

싱글 톤은 효과적으로 '물건'(데이터 또는 메소드)의 전역 액세스 가능한 세트를 만들지 만 대부분의 사람들은 너무 많은 전역 변수를 사용하는 것이 좋은 아이디어는 아니라고 생각합니다. 클래스와 객체 지향의 모든 요점은 모든 것을 하나의 거대한 글로벌 공간에 집어 넣는 것보다 개별적인 영역으로 그룹화하는 것입니다.

싱글 톤보다 선호하는 경향이있는 '패턴'중 하나는 필요한 객체를 맨 위에서 아래로 전달하는 것입니다. 내 앱 초기화 단계에서 한 번 만들었고 액세스가 필요한 모든 개체를 통과시킵니다. 싱글 톤 패턴의 '단일 생성'부분을 모방하지만 '글로벌'부분은 없습니다.

싱글 톤의 핵심은 오직 1 개만 존재해야하는 객체를위한 것입니다. 당신은 클래스의 데이터 컨트롤 집합을 언급했다. 어쩌면 실제로, 앱이 2 세트의 데이터 컨트롤 클래스를 생성하기를 원할지도 모르는 상황이 있기 때문에 아마도 이것에 싱글 톤 (singleton)을 적용하는 것이 옳지 않다고 생각할 수도 있습니다. 대신, 당신이 app init에이 데이터 클래스를 생성하고 전달하면, 현재의 앱이 필요로하는 것과 같이 1 세트 만 생성하게 될 것이지만, 어떤 시점에서 두번째 세트가 필요하다면 가능성을 열어 두어야합니다 당신은 쉽게 그들을 만들 수 있습니다. 또한 데이터 컨트롤 클래스는 앱의 어디에서나 액세스 할 수있는 전역 변수가되어야합니다. 내 생각 엔 대신 하위 수준의 데이터 액세스 레이어에서만 액세스 할 수 있어야합니다.

어떤 사람들은 GOF 서적을 추천했습니다. 나는 훌륭한 책이지만, 먼저 일반적인 아키텍처에 관한 책을 먼저 찾아보고, 2 / 3 / n- 티어 디자인, 캡슐화, 추상화 및 이러한 종류의 원칙을 먼저 읽으려고합니다. 이것은 GOF가 말하는 패턴의 적절한 사용법을 이해할 수있는 좀 더 견고한 기반을 제공 할 것입니다.

[편집 : 싱글 톤 변형이 유용 할 수있는 다른 시간은 단일 액세스 포인트를 원할 때이지만 구현 세부 사항은 실제로 둘 이상이 될 수 있습니다. 호출자는 커버 아래에서 싱글 톤 객체에 대한 요청이 실제로 사용 가능한 여러 객체에 대해 처리되고 하나가 반환된다는 것을 알 필요가 없습니다. 나는 쓰레드 풀 같은 것을 생각하고 있는데, 사용법이 어디로가는 지, 헤이, 그냥 쓰레드를 얻는다. 1이 필요하지만, 나는 상관 없다.]

• 스레드 풀은 싱글 톤 역화의 좋은 예입니다. .NET 스레드 풀은 이와 같이 작동하며 고통 스럽습니다. 내 응용 프로그램의 작업에 대한 스레드 풀을 만들 수 없다는 의미입니다. 나는 .NET 클래스 라이브러리, 내가 사용하고 있을지도 모르는 써드 파티 라이브러리와 공유해야하고, 하나님은 다른 것을 알고있다. 나는 심지어 그것이 얼마나 가능성이 높은지 말할 수있는 방법이 전혀 없다.있다자유로운 실. 정상적인 디자인은 스레드 풀 클래스를 만드는 것입니다.누군가원하는 경우 인스턴스화 할 수 있습니다.개인적인쓰레드 풀을 생성 한 다음, 다른 사용자가 몇 명 있는지를 고려하지 않을 때 사용할 수있는 단일 글로벌 쓰레드 풀을 노출합니다. - jalf
• @jaif : 스레드 풀의 요점을 놓친 것처럼 느껴집니다. 무료 스레드를 얻는 것에 관심이 있거나 더 많은 제어를 원한다면 Thread 클래스 나 BackgroundWorker를 사용할 수있어 매우 간단하고 더러운 작업을 메인 스레드에서 끝내기를 원합니다. 자신의 개인 사용자가 관리하는 스레드 풀을 원할 경우 생산자 - 소비자 패턴을 구현할 수 있습니다 (이 페이지의 아래쪽 절반 참조).albahari.com/threading/part4.aspx). 스레드 풀의 핵심은 앱뿐만 아니라 전체 시스템에서 비동기 작업의 균형을 맞추기위한 것입니다. - Simon P Stevens
• 왜해야합니까?나는. NET이 이미 저를 위해 그것을 시도 할 때,이 패턴을 직접 구현해야합니다? 요점은 그들이 싱글 톤으로 하드 코딩하지 않았다면 전체 시스템에서 그렇지 않은 작업을 수행했을 것입니다.게다가내 응용 프로그램 내에서 더 작은 범위에서 유용합니다. 그것은 아무 이유없이 유연성을 제거하는 싱글 톤의 완벽한 예입니다. 스레드 풀의 요점을 놓치지 않고 작은 수정을하면 더 일반적으로 유용했을 것입니다. - jalf
• 여러 스레드 풀을 작성한 경우 어떻게 균형을 유지할 수 있습니까? 원하는 것은 다른 것입니다. 다중 스레드 풀이 어떻게 작동하는지 볼 수 없습니다. 스레드 풀~이다.시스템 전반에 걸친 스레드 풀, 즉 앱 전체에서 작업의 균형을 유지하고 거기에~이다.그것들 중 하나만 가지고 있기 때문에 싱글 톤이 접근하는 적절한 방법입니다. 예, 아마도 MS는 생산자 - 소비자 스레드 대기열을 구현해야하지만 모든 것을 제공 할 수는 없습니다. 어쨌든, 그것에 대해 너무 많이 논박하지 마십시오. , 나는 MS가 자신들이 한 것처럼 그렇게하는 이유가 있다고 확신 할 수 있습니다. 우리는 선을 위해 또는 나쁜 것을 위해 살아야합니다. - Simon P Stevens

나는 이것이 오래된 쓰레드라는 것을 알고 있지만 아무도 OP가하려고했던 것과 맞는 실제 패턴을 언급하지 않았다. 그가 내가 필요하다고 생각하는 것은중재자 패턴. SourceMaking은 이러한 종류의 정보를 배우고 참조하기위한 환상적인 사이트입니다. 소프트웨어 패턴에 사람들을 소개하기위한 장소로 확실히 가고 있습니다. 또한, 일반적으로 어떤 디자인 패턴이 필연적으로 본질적으로 좋거나 나쁘다는 개념에 사지 않는 것이 좋습니다. 그들 모두는 그들의 사용법을 가지고 있으며, 그것들을 언제 어디에서 사용 하는지를 배우는 것이 트릭입니다. 나에게 싱글 톤을 사용하지 말라고 말하는 사람들은 그들의 유용성을 이해하지 못합니다.

아니, 그들은 반드시 나쁜 것은 아닙니다.

책에 관해서는고전.

싱글 톤은 "나쁘지 않다". 관련 싱글 톤이 많고 팩토리를 사용하여 많은 수의 팩을 대체 / 통합 할 수 있지만 걱정하지 않아도되므로 그럴 때가 있습니다.

책에 관해서는,글쎄, 일종의 캐논이있어..

나는 생각했다.싱글 톤은 좋았습니다..

Google은납득시키다그 싱글 톤은 나쁜 생각입니다.

Google이하는 모든 일이 완벽하거나 모든 의견이 논점의 끝이라고 제안하는 것은 아닙니다. 그러나이 Singleton 탐지기를 사용하여이 문제를 해결할 수 있습니다. 너 자신의 생각을해라.