싱글 톤이 왜 그렇게 나쁜가요? [닫은]

싱글 톤 패턴 의 완전 최대 유료 회원입니다 GoF의 의 패턴 책 , 그러나 그것은 최근에 오히려 개발자 세계 고아 보인다. 나는 여전히 많은 팩토리 클래스를 사용합니다. 특히 팩토리 클래스 에는 멀티 스레딩 문제에 대해 조심해야하지만 (실제로 다른 클래스와 마찬가지로) 왜 그렇게 끔찍한 지 알 수 없습니다.

스택 오버플로는 특히 모든 사람들이 싱글 톤이 악하다고 동의한다고 가정합니다. 왜?

" 사실, 참조 또는 특정 전문 지식 "으로 답변을 지원하십시오.

브라이언 버튼에서 번역 :

1. 그것들은 일반적으로 글로벌 인스턴스로 사용되는데 왜 그렇게 나쁜가? 인터페이스를 통해 노출하는 대신 코드에서 애플리케이션의 종속성을 숨기므로 그것을 피하기 위해 전역으로 무언가를 만드는 것은 코드 냄새 입니다.

2. 그들은 하나의 책임 원칙을 위반합니다 . 즉, 자신의 생성과 수명주기를 제어한다는 사실 때문입니다.

3. 이것들은 본질적으로 코드가 밀접하게 결합되도록 합니다. 이로 인해 많은 경우 테스트중인 가짜가 다소 어려워집니다.

4. 응용 프로그램 수명 동안 상태를 유지합니다. 테스트를 주문 해야하는 상황으로 이어질 수 있으므로 테스트에 대한 또 다른 타격은 단위 테스트에 큰 도움이되지 않습니다. 왜? 각 단위 테스트는 서로 독립적이어야합니다.

싱글 톤은 하나의 문제 만 해결합니다.

리소스 경합.

자원이 있다면

( 1 )은 단일 인스턴스 만 가질 수 있으며

( 2 ) 단일 인스턴스를 관리해야합니다.

싱글 톤 이 필요합니다 .

예가 많지 않습니다. 로그 파일이 큰 파일입니다. 단일 로그 파일 만 포기하고 싶지는 않습니다. 플러시, 동기화 및 올바르게 닫으려고합니다. 이것은 관리해야하는 단일 공유 리소스의 예입니다.

싱글 톤이 필요한 경우는 거의 없습니다. 그들이 나쁜 이유는 그들이 글로벌 한 느낌과 GoF Design Patterns 책 의 전액을 지불했기 때문 입니다.

글로벌이 필요하다고 생각하면 아마도 끔찍한 디자인 실수를 저지른 것일 수 있습니다.

일부 코딩 스 너브 (snob)는 그것들을 단지 영광스러운 세계로 봅니다. 많은 사람들이 goto 선언을 싫어하는 것과 같은 방식 으로 글로벌 사용을 싫어하는 사람들이 있습니다 . 나는 여러 개발자 가 실패를 받아들이는 것을 고려했기 때문에 전 세계 를 피하기 위해 엄청난 길이로 진행하는 것을 보았습니다 . 이상하지만 사실입니다.

실제로 Singleton 패턴은 개념 툴킷의 유용한 부분 인 프로그래밍 기술 일뿐입니다. 때때로 당신은 그것이 이상적인 솔루션임을 알 수 있으므로 그것을 사용하십시오. 그러나 디자인 패턴을 사용하는 것에 대해 자랑 할 수 있도록 그것을 사용하는 것은 단지 글로벌 이기 때문에 디자인 패턴을 사용하는 것을 거부하는 것처럼 바보 입니다.

구글의 Misko Hevery는이 주제에 관한 흥미로운 기사를 가지고 있습니다.

싱글턴은 병리학적인 거짓말 쟁이 거짓말 쟁이 는 싱글 톤이 의존성 체인을 파악하고 응용 프로그램을 시작하거나 테스트하는 것을 어렵게 만드는 방법을 보여주는 단위 테스트 예제를 가지고 있습니다. 그것은 학대에 대한 극단적 인 예이지만, 그가 주장하는 요점은 여전히 ​​유효합니다.

싱글 톤은 글로벌 상태에 지나지 않습니다. 전역 상태를 사용하면 객체가 API에 선언되지 않은 것을 비밀리에 보유 할 수 있으므로 싱글 톤은 API를 병리학적인 거짓말 쟁이로 만듭니다.

모든 Singletons Gone 이 의존성 주입을 통해 인스턴스를 필요로하는 생성자에게 인스턴스를 쉽게 가져올 수있게되었으므로 첫 번째 기사에서 언급 한 나쁜 글로벌 Singleton의 근본적인 요구를 완화 할 수있었습니다.

혼동은 사람들이 싱글 톤 패턴의 실제 적용을 알지 못하기 때문에 발생한다고 생각합니다. 나는 이것을 충분히 강조 할 수 없다. 싱글 톤은 글로벌을 감싸는 패턴 이 아닙니다 . 단일 클래스 패턴은 런타임 동안 주어진 클래스의 인스턴스가 하나만 존재 하도록 보장하기 위해 사용해야합니다 .

사람들은 싱글 톤을 글로벌에 사용하기 때문에 싱글 톤이 악하다고 생각합니다. 이 혼동으로 인해 싱글 톤을 내려다 보았습니다. 싱글 톤과 글로벌을 혼동하지 마십시오. 원래 목적에 맞게 사용하면 싱글 톤 패턴의 이점을 최대한 활용할 수 있습니다.

싱글 톤에 대한 한 가지 나쁜 점은 싱글 톤을 매우 쉽게 확장 할 수 없다는 것입니다. 기본적으로 어떤 종류의 데코레이터 패턴 이나 그 동작을 변경하려면 그러한 것을 만들어야합니다. 또한 언젠가 여러 가지 방법으로 하나의 작업을 수행하려는 경우 코드 레이아웃에 따라 변경하기가 다소 어려울 수 있습니다.

한 가지 주목할 점은 싱글 톤을 사용하는 경우 직접 액세스하지 않고 필요한 사람에게 전달하려고 시도하는 것입니다. 그렇지 않으면 싱글 톤이 수행하는 작업을 여러 방법으로 수행하기로 선택한 경우에는 다음과 같이됩니다. 각 클래스가 싱글 톤에 직접 액세스하는 경우 종속성을 포함하므로 변경하기가 다소 어렵습니다.

그래서 기본적으로:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

오히려

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

이런 종류의 패턴을 의존성 주입 이라고합니다. 하며 일반적으로 좋은 것으로 간주됩니다.

그러나 어떤 패턴과 마찬가지로 ... 그것에 대해 생각하고 주어진 상황에서의 사용이 부적절한 지 아닌지 고려하십시오 ... 규칙은 일반적으로 깨지도록 만들어지며, 생각없이 패턴 을 적용 할 수 없습니다.

싱글 톤 패턴 자체는 문제가되지 않습니다. 문제는 패턴이 OO 개념을 제대로 파악하지 않고도 객체 지향 도구로 소프트웨어를 개발하는 사람들이 종종 사용한다는 것입니다. 이 문맥에서 싱글 톤이 소개 될 때, 그들은 거의 사용하지 않는 헬퍼 메소드를 포함하는 관리 할 수없는 클래스로 성장하는 경향이 있습니다.

싱글 톤은 테스트 관점에서도 문제가됩니다. 그들은 고립 된 단위 테스트를 작성하기 어렵게 만드는 경향이 있습니다. 제어 역전 (IoC) 및 의존성 주입 은 단위 테스트에 적합한 객체 지향 방식으로이 문제를 극복하기위한 패턴입니다.

A의 쓰레기 수집 환경 싱글 빠르게 메모리 관리와 관련하여 문제가 될 수 있습니다.

싱글 톤이 병목 현상이 될 수있는 멀티 스레드 시나리오와 동기화 문제도 있습니다.

싱글 톤은 정적 메소드를 사용하여 구현됩니다. 정적 방법은 조롱하거나 스터 빙 할 수 없으므로 단위 테스트를 수행하는 사람들이 피합니다. 이 사이트의 대부분의 사람들은 단위 테스트의 큰 지지자입니다. 이를 피하기 위해 일반적으로 가장 많이 사용되는 규칙은 반전 제어 패턴을 사용하는 것입니다 .

클러스터링과 관련하여 싱글 톤도 좋지 않습니다 . 따라서 더 이상 응용 프로그램에 "정확히 하나의 싱글 톤"이 없습니다.

다음 상황을 고려하십시오. 개발자는 데이터베이스에 액세스하는 웹 애플리케이션을 작성해야합니다. 동시 데이터베이스 호출이 서로 충돌하지 않도록하려면 스레드 저장을 작성하십시오 SingletonDao.

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

따라서 응용 프로그램에는 하나의 싱글 톤 만 존재하고 모든 데이터베이스는이 하나만 통과해야합니다 SingletonDao. 프로덕션 환경은 이제 다음과 같습니다.

지금까지 모든 것이 정상입니다.

이제 클러스터에 여러 웹 애플리케이션 인스턴스를 설정하려고합니다. 이제 갑자기 다음과 같은 것이 있습니다.

이상하게 들리지만 이제는 응용 프로그램에 많은 싱글 톤이 있습니다 . 이것이 바로 싱글 톤이 아니어야하는 것입니다. 이 예제에서 볼 수 있듯이 데이터베이스에 동기화 된 호출을하려는 경우 특히 나쁩니다.

물론 이것은 싱글 톤의 나쁜 사용법의 예입니다. 그러나이 예제의 메시지는 다음과 같습니다. 응용 프로그램에 특히 단일 클러스터의 인스턴스가 하나만 있다고 믿을 수는 없습니다.

1. 전역 변수로 쉽게 사용됩니다.
2. 싱글 톤에 의존하는 클래스는 상대적으로 단위 테스트가 상대적으로 어렵습니다.

독점은 악마이며 읽기 불가능 / 변경 불가능한 상태의 싱글 톤은 '실제'문제입니다 ...

싱글 톤이 병리학적인 거짓말 쟁이 임을 읽은 후 , Jason의 답변 에서 제안한대로 싱글 톤이 종종 오용 되는 방법에 대한 최상의 예를 제공하는이 작은 음식을 발견했습니다 .

다음과 같은 이유로 글로벌이 나쁩니다.

• ㅏ. 네임 스페이스 충돌이 발생합니다
• 비. 부주의 한 방식으로 국가를 폭로합니다

싱글 톤에 관해서

• ㅏ. 명시적인 OO 방식으로 호출하면 충돌이 방지되므로 a를 가리 킵니다. 문제가 아니다
• 비. 상태가없는 싱글 톤 (공장과 같은)은 문제가되지 않습니다. 상태가있는 싱글 톤은 다시 두 가지 범주에 속할 수 있는데,이 범주는 변경 불가능하거나 한 번 쓰고 많은 구성 (속성 파일)을 읽습니다. 이것들은 나쁘지 않습니다. 참조 홀더의 일종 인 가변 싱글 톤 (Mutable Singleton)이 당신이 말하는 것입니다.

마지막 진술에서 그는 블로그의 '싱글 톤은 거짓말 쟁이이다'라는 개념을 언급하고있다.

이것이 독점에 어떻게 적용됩니까?

독점 게임을 시작하려면 먼저 :

• 모든 사람들이 같은 페이지에 있도록 규칙을 먼저 설정합니다
• 게임이 시작될 때 모두에게 동등한 시작이 주어집니다
• 혼란을 피하기 위해 하나의 규칙 세트 만 제공됩니다.
• 게임 내내 규칙을 변경할 수 없습니다

자,하지 않은 사람을 위해 정말 독점을했다,이 표준은 최상의 이상적입니다. 독점에 대한 패배는 삼키기가 어렵습니다. 독점은 돈에 관한 것입니다. 당신이 잃어 버리면 나머지 플레이어가 게임을 끝내는 것을 힘들게 지켜봐야하며, 손실은 대개 신속하고 파쇄됩니다. 따라서 규칙은 일반적으로 특정 시점에서 다른 플레이어를 희생하여 일부 플레이어의 자기 이익을 제공하기 위해 왜곡됩니다.

친구 밥, 조, 에드와 독점을하고 있습니다. 빠르게 제국을 건설하고 지수 비율로 시장 점유율을 소비하고 있습니다. 상대방이 약해지고 혈액 냄새가 나기 시작합니다 (그림 참조). 버디 밥은 가능한 한 많은 가치가 낮은 부동산을 그리드 락에 넣었지만, 예상대로 높은 투자 수익을 얻지 못했습니다. 불운의 일격으로 밥은 보드 워크에 착륙하여 게임에서 제외됩니다.

이제 게임은 친절한 주사위 굴림에서 진지한 사업으로 진행됩니다. 밥은 실패의 모범이되었으며 조와 에드는 '그 사람'처럼되기를 원하지 않습니다. 따라서, 당신은 최고의 선수가되어 갑자기 적이됩니다. Joe와 Ed는 테이블 밖에서 거래, 뒤에서 돈을 주입, 저평가 된 주택 스와핑 및 일반적으로 그들 중 하나가 정상에 올 때까지 당신을 약화시키는 것을 연습하기 시작합니다.

그런 다음 그중 하나가 승리하는 대신 프로세스가 완전히 시작됩니다. 갑자기 유한 한 규칙이 움직이는 목표가되고 게임은 생존자 이후 모든 높은 등급의 현실 TV 쇼의 기초를 구성하는 사회적 상호 작용의 유형으로 변질됩니다. 왜, 규칙이 바뀌고 있으며 어떻게 / 왜 / 어떻게 대표해야하는지에 대한 합의가 없기 때문에 더 중요한 것은 결정을 내릴 사람이 없다는 것입니다. 그 시점에서 게임의 모든 플레이어는 자신의 규칙을 만들고 있으며, 두 명의 플레이어가 너무 피곤하여 차드를 유지하고 천천히 포기할 때까지 혼란을 겪습니다.

따라서 게임의 룰북이 싱글 톤을 정확하게 나타내면 독점 룰북이 남용의 예가됩니다.

이것이 프로그래밍에 어떻게 적용됩니까?

변경 가능한 싱글 톤에서 발생하는 명백한 스레드 안전성 및 동기화 문제를 제외하고 ... 데이터 세트가 하나 인 경우 여러 다른 소스에서 동시에 읽거나 조작 할 수 있으며 애플리케이션 실행 수명 동안 존재합니다. 아마도 물러서서 "여기에 올바른 유형의 데이터 구조를 사용하고 있습니까?"라고 물을 때가 좋습니다.

개인적으로, 나는 프로그래머가 응용 프로그램 내에서 일종의 꼬인 크로스 스레드 데이터베이스 저장소로 사용하여 싱글 톤을 남용하는 것을 보았습니다. 코드를 직접 연구 한 결과, 느리게 (스레드 안전에 필요한 모든 스레드 잠금으로 인해) 느리게 작동하고 악의적 인 작업 (예측할 수없는 / 간헐적 인 동기화 버그 때문에)을 증명할 수 있습니다. '생산'조건에서 테스트하기가 거의 불가능합니다. 물론 성능 문제 중 일부를 극복하기 위해 폴링 / 시그널링을 사용하여 시스템을 개발할 수 있었지만 테스트와 관련된 문제를 해결하지 못하고 왜 '실제'데이터베이스가 훨씬 더 강력한 기능으로 동일한 기능을 이미 수행 할 수 있는지 고민하는 이유 / 확장 가능한 방식.

싱글 톤은 싱글 톤이 제공하는 것이 필요한 경우 에만 옵션입니다. 개체의 1 회 읽기 전용 인스턴스입니다. 동일한 규칙이 객체의 속성 / 멤버에도 연결되어야합니다.

싱글 톤은 싱글 인스턴스가 아닙니다!

다른 답변과 달리 Singletons의 문제점에 대해 이야기하고 싶지 않지만 올바르게 사용될 때 얼마나 강력하고 훌륭했는지 보여주기 위해!

• 문제 : 멀티 스레딩 환경에서 싱글 톤이 문제 가 될 수 있습니다.
  해결책 : 단일 스레드 부트 스트랩 프로세스를 사용하여 싱글 톤의 모든 종속성을 초기화하십시오.
• 문제 : 싱글 톤을 조롱하기는 어렵다.
  솔루션 : 조롱을위한 메소드 팩토리 패턴 사용

에 매핑 MyModel할 수 있습니다TestMyModel 때 상속이 사방 클래스 MyModel주입 될 것입니다 당신이 얻을 것이다 TestMyModelinstread. - 문제 : 싱글 톤은 절대로 폐기되지 않아 메모리 누수를 일으킬 수 있습니다.
해결책 : 음, 폐기하십시오! 싱글 톤을 올바르게 처리하기 위해 앱에서 콜백을 구현하면 연결된 데이터를 모두 제거하고 마지막으로 팩토리에서 제거해야합니다.

제목에서 언급했듯이 싱글 톤은 단일 인스턴스에 관한 것이 아닙니다.

• 싱글 톤은 가독성을 향상시킵니다 . 클래스를 살펴보고 어떤 싱글 톤이 어떤 종속성인지 파악하여 종속성을 파악할 수 있습니다.
• 싱글 톤으로 유지 보수 향상 . 한 번 클래스에서 종속성을 제거한 후 싱글 톤 주입을 삭제하면 종속성을 이동시킨 다른 클래스의 큰 링크를 편집 할 필요가 없습니다 (이 냄새 나는 코드 @Jim Burger )
• 싱글 톤은 메모리와 성능을 향상시킵니다 . 어플리케이션에서 어떤 일이 발생하고 콜백이 오래 걸리면 싱글 톤을 사용하여 중개인을 줄이고 메모리와 성능을 낭비하고 성능과 메모리 사용량을 향상시킵니다 ( 불필요한 지역 변수 할당을 피함으로써).

싱글 톤이 어떻게 나쁜지에 대한 나의 대답은 항상 "올바른 일을하기가 어렵다"입니다. 언어의 많은 기본 구성 요소는 싱글 톤 (클래스, 함수, 네임 스페이스 및 심지어 연산자)이며 컴퓨팅의 다른 측면 (로컬 호스트, 기본 경로, 가상 파일 시스템 등)의 구성 요소와 마찬가지로 우연이 아닙니다. 그들은 때때로 문제와 좌절을 야기하지만, 많은 일들이 훨씬 더 잘 작동하도록 만들 수 있습니다.

내가 볼 수있는 가장 큰 두 가지 단점은 전역처럼 취급하고 싱글 톤 클로저를 정의하지 못하는 것입니다.

모든 사람들은 기본적으로 싱글 톤을 글로벌로 이야기합니다. 그러나, 지구상에서 많은 (슬프게도, 전부는 아님) 악의는 본질적으로 세계적이라는 것이 아니라 어떻게 사용 하는가에 달려 있습니다. 싱글 톤도 마찬가지입니다. 실제로 "단일 인스턴스"가 실제로 "전 세계적으로 액세스 가능"을 의미 할 필요는 없습니다. 그것은 더 자연스러운 부산물이며, 우리가 알고있는 모든 나쁜 점을 감안할 때, 우리는 전 세계의 접근성을 이용하기 위해 서둘러서는 안됩니다. 프로그래머가 싱글 톤을 본 후에는 항상 인스턴스 메소드를 통해 직접 액세스하는 것 같습니다. 대신 다른 개체와 마찬가지로 탐색해야합니다. 대부분의 코드는 싱글 톤 (느슨한 커플 링, 맞습니까?)을 다루고 있다는 것을 인식해서는 안됩니다. 전역 코드처럼 작은 코드 만 객체에 액세스하면 많은 피해가 발생하지 않습니다.

싱글 톤 컨텍스트도 매우 중요합니다. 싱글 톤의 정의 특성은 "하나만"있다는 것이지만, 어떤 맥락 / 네임 스페이스 내에서 "하나만"이라는 것이 진실입니다. 일반적으로 스레드, 프로세스, IP 주소 또는 클러스터 당 하나이지만 프로세서, 컴퓨터, 언어 네임 스페이스 / 클래스 로더 / 무엇이든, 서브넷, 인터넷 등 하나 일 수 있습니다.

덜 흔한 또 다른 실수는 싱글 톤 라이프 스타일을 무시하는 것입니다. 단 하나만 있다고해서 Singleton이 "항상 존재하고 항상있을 것"이라는 전능함을 의미하지는 않으며 일반적으로 바람직하지도 않습니다 (시작과 끝이없는 객체는 코드에서 모든 종류의 유용한 가정을 위반하므로 사용되어야합니다) 가장 절박한 상황에서.

이러한 실수를 피하면 Singletons는 여전히 PITA가 될 수 있습니다. 비트는 최악의 많은 문제가 크게 완화 될 수 있습니다. 정의 된 생성 및 소멸 방법과 호출시기 및 방법을 결정하는 수명주기와 "인스턴스"메소드의 수명주기를 사용하여 클래스 로더 당 한 번 (스레드 안전성 정책이 필요함) 명시 적으로 정의 된 Java Singleton을 상상해보십시오. 패키지 보호를 통해 일반적으로 다른 비전 역 객체를 통해 액세스합니다. 여전히 잠재적 인 문제의 원천이지만 확실히 훨씬 적은 문제입니다.

슬프게도, 싱글 톤을하는 방법에 대한 좋은 예를 가르치기보다는. 우리는 나쁜 예를 가르치고, 프로그래머가 잠시 동안 사용하지 못하게하고, 잘못된 디자인 패턴이라고 말합니다.

Wikipedia Singleton_pattern 참조

또한 일부 사람들에 의해 반 패턴으로 간주되며, 과도하게 사용되었다고 느끼고 클래스의 유일한 인스턴스가 실제로 필요하지 않은 상황에서 불필요한 제한을 초래합니다. [1] [2] [3] [4]

참조 (기사에서 관련 참조 만)

1. ↑ Alex Miller. 내가 싫어하는 패턴 # 1 : Singleton , 2007 년 7 월
2. ^ Scott Densmore. 싱글 톤이 악한 이유 , 2004 년 5 월
3. ^ Steve Yegge. 싱글 톤은 어리석은 것으로 간주 , 2004 년 9 월
4. ^ JB Rainsberger, IBM. 2001 년 7 월, 싱글 톤을 현명하게 사용하십시오

싱글 톤 자체가 나쁘지는 않지만 GoF 디자인 패턴은 아닙니다. 실제로 유일하게 유효한 주장은 GoF 디자인 패턴이 테스트와 관련하여, 특히 테스트가 병렬로 실행되는 경우에는 적합하지 않다는 것입니다.

코드에서 다음 수단을 적용하는 한 클래스의 단일 인스턴스를 사용하는 것이 올바른 구성입니다.

1. 싱글 톤으로 사용될 클래스가 인터페이스를 구현하는지 확인하십시오. 이를 통해 동일한 인터페이스를 사용하여 스텁 또는 모의를 구현할 수 있습니다.

2. 싱글 톤이 스레드로부터 안전해야합니다. 그것은 주어진 것입니다.

3. 싱글 톤은 본질적으로 단순해야하고 지나치게 복잡해서는 안됩니다.

4. 단일 객체를 지정된 객체로 전달해야하는 응용 프로그램을 실행하는 동안 해당 객체를 빌드하는 클래스 팩토리를 사용하고 클래스 팩토리가 싱글 톤 인스턴스를 필요한 클래스로 전달하도록합니다.

5. 테스트하는 동안 그리고 결정적인 동작을 보장하기 위해 싱글 톤 클래스를 실제 클래스 자체 또는 별도의 인스턴스로 동작을 구현하는 스텁 / mock으로 만들고이를 필요한 클래스에 그대로 전달하십시오. 테스트 중에 싱글 톤이 필요한 테스트 대상 객체를 생성하는 클래스 팩터를 사용하지 마십시오. 단일 글로벌 인스턴스를 통과하므로 목적을 상실합니다.

우리는 솔루션에서 싱글 톤을 사용하여 병렬 테스트 실행 스트림에서 결정적인 동작을 보장 할 수있는 많은 성공을 거두었습니다.

허용 된 답변에서 4 점을 다루고 싶습니다. 아마도 누군가 내가 왜 잘못했는지 설명 할 수 있기를 바랍니다.

1. 코드에 의존성을 숨기는 것은 왜 나쁜가? 이미 수십 개의 숨겨진 종속성 (C 런타임 호출, OS API 호출, 전역 함수 호출)이 있으며 싱글 톤 종속성을 쉽게 찾을 수 있습니다 (예 : search ()).

   "전세계를 통과하지 못하도록하는 것은 코드 냄새입니다." 싱글 톤 코드 냄새를 피하기 위해 왜 무언가를 전달하지 않습니까?

   단일 톤을 피하기 위해 호출 스택에서 10 개의 함수를 통해 객체를 전달하는 경우 그렇게 훌륭합니까?

2. 단일 책임 원칙 : 나는 이것이 약간 모호하며 귀하의 책임 정의에 달려 있다고 생각합니다. 관련 질문은 왜이 특정 "책임"을 수업에 추가 하는 것입니까?

3. 왜 객체를 클래스에 전달하면 해당 객체를 클래스 내에서 싱글 톤으로 사용하는 것보다 더 밀접하게 결합됩니까?

4. 상태가 지속되는 시간이 왜 변경됩니까? 싱글 톤은 수동으로 생성하거나 파괴 할 수 있으므로 컨트롤은 여전히 ​​존재하며 수명은 싱글 톤이 아닌 오브젝트의 수명과 동일하게 만들 수 있습니다.

단위 테스트와 관련하여 :

• 모든 수업을 단위 테스트 할 필요는 없습니다.
• 단위 테스트가 필요한 모든 클래스가 싱글 톤의 구현을 변경해야하는 것은 아닙니다.
• 그들이 경우 어떻게 단위 테스트 및 구현을 변경해야 할 필요, 그것은 의존성 주입을 통해 전달 된 싱글을 필요로 싱글 톤을 사용하는 클래스를 쉽게 변경할 수 있습니다.

빈스 휴스턴 (Vince Huston) 은 다음과 같은 기준을 가지고 있습니다.

다음 기준 중 세 가지가 모두 충족되는 경우에만 싱글 톤을 고려해야합니다.

• 단일 인스턴스의 소유권을 합리적으로 할당 할 수 없습니다
• 게으른 초기화가 바람직합니다
• 달리 글로벌 액세스는 제공되지 않습니다

단일 인스턴스의 소유권, 초기화시기 및 방법 및 전역 액세스에 문제가없는 경우 Singleton은 충분히 흥미롭지 않습니다.

싱글 톤은 순수한 관점에서 나쁘다.

실질적인 관점에서 보면 싱글 톤은 개발 시간과 복잡성 사이의 균형을 이룹니다 .

응용 프로그램이 많이 변경되지 않는다는 것을 알고 있다면 함께 갈 수 있습니다. 요구 사항이 예기치 않은 방식으로 변경되는 경우 상황을 리팩토링해야 할 수도 있습니다 (대부분의 경우는 괜찮습니다).

싱글 톤은 때때로 단위 테스트를 복잡하게 만듭니다 .

패턴이 본질적으로 단일 인 모델의 일부 측면에 사용된다고 가정하면 패턴에는 본질적으로 아무런 문제가 없습니다.

나는 백래시가 과도하게 사용되어서 이해하고 구현하는 것이 가장 쉬운 패턴이기 때문이라고 생각합니다.

나는 good / evil 논쟁에 대해서는 언급하지 않을 것이지만 Spring 이 등장한 이래로 나는 그것들을 사용하지 않았다 . 의존성 주입 을 사용하면 싱글 톤, 서비스 로케이터 및 팩토리에 대한 요구 사항이 거의 제거되었습니다. 적어도 내가하는 일 (Java 기반 웹 응용 프로그램)의 경우 훨씬 생산적이고 깨끗한 환경입니다.

싱글 톤은 패턴이며 다른 도구와 마찬가지로 사용하거나 남용 할 수 있습니다.

싱글 톤의 나쁜 부분은 일반적으로 사용자입니다 (또는 싱글 톤이 의도하지 않은 작업에 부적절하게 사용한다고 말해야합니다). 가장 큰 문제는 싱글 톤을 가짜 전역 변수로 사용하는 것입니다.

로거 또는 데이터베이스 연결과 같은 싱글 톤을 사용하여 코드를 작성한 후 둘 이상의 로그 나 둘 이상의 데이터베이스가 필요하다는 것을 알게되면 문제가 발생합니다.

싱글 톤은 그것들을 일반 객체로 옮기기가 매우 어렵습니다.

또한 스레드로부터 안전하지 않은 싱글 톤을 작성하는 것은 너무 쉽습니다.

싱글 톤을 사용하는 대신 필요한 모든 유틸리티 개체를 함수에서 함수로 전달해야합니다. 다음과 같이 모든 것을 도우미 객체로 감싸면 단순화 될 수 있습니다.

void some_class::some_function(parameters, service_provider& srv)
{
    srv.get<error_logger>().log("Hi there!");
    this->another_function(some_other_parameters, srv);
}

싱글 톤의 문제점은 범위 확대 문제이므로 커플 링 . 단일 인스턴스에 액세스해야하는 상황이 있다는 것을 부인할 수 없으며 다른 방법으로도 달성 할 수 있습니다.

나는 이제 제어 역전을 중심으로 설계하는 것을 선호한다 IoC ( ) 컨테이너를 컨테이너에서 수명을 제어 할 수 있습니다. 이를 통해 인스턴스에 의존하는 클래스의 이점을 통해 단일 인스턴스가 있다는 사실을 알 수 없습니다. 싱글 톤의 수명은 나중에 변경 될 수 있습니다. 그런 예가 최근에 발생하면 단일 스레드에서 다중 스레드로 쉽게 조정할 수있었습니다.

FWIW, 단위 테스트를 시도 할 때 PIA 인 경우 디버깅, 버그 수정 또는 향상하려고 할 때 PIA가됩니다.

이 주제에 관한 최근 기사는 논평없이 코딩 하는 Chris Reath의 기사입니다 .

참고 : 주석없는 코딩은 더 이상 유효하지 않습니다. 그러나 연결된 기사가 다른 사용자에 의해 복제되었습니다.

http://geekswithblogs.net/AngelEyes/archive/2013/09/08/singleton-i-love-you-but-youre-bringing-me-down-re-uploaded.aspx

싱글 톤은 나쁘지 않습니다. 전 세계적으로 독특하지 않은 세계적으로 독특한 것을 만들 때만 나쁩니다.

그러나 "응용 프로그램 범위 서비스"(구성 요소가 상호 작용하게하는 메시징 시스템에 대해 생각할 수 있음)가 있습니다.이 방법은 "SendMessage (...)"메서드가있는 단일 클래스 인 "MessageQueue"에 대한 호출입니다.

그런 다음 모든 곳에서 다음을 수행 할 수 있습니다.

MessageQueue.Current.SendMessage (new MailArrivedMessage (...));

그리고 물론 다음을 수행하십시오.

MessageQueue.Current.RegisterReceiver (this);

IMessageReceiver를 구현하는 클래스에서

너무 많은 사람들이 싱글 톤 패턴으로 스레드 안전하지 않은 객체를 넣습니다. DataContext가 스레드 안전하지 않고 순수하게 작업 단위 객체라는 사실에도 불구하고 Singleton 패턴으로 수행 된 DataContext ( LINQ to SQL )의 예를 보았습니다 .

아직 아무도 말하지 않은 싱글 톤에 대해 한 가지 더 있습니다.

대부분의 경우 "단일성"은 인터페이스의 특성이 아니라 일부 클래스에 대한 세부적인 구현입니다. 컨트롤 컨테이너의 반전은이 특성을 클래스 사용자로부터 숨길 수 있습니다. 클래스를 싱글 톤으로 표시하면됩니다.@Singleton 예 : Java 주석 포함) 그게 전부입니다. IoCC가 나머지 작업을 수행합니다. 액세스가 이미 IoCC에 의해 관리되므로 싱글 톤 인스턴스에 대한 글로벌 액세스를 제공 할 필요가 없습니다. 따라서 IoC 싱글 톤에는 아무런 문제가 없습니다.

IoC 싱글 톤과 반대되는 GoF 싱글 톤은 getInstance () 메소드를 통해 인터페이스에 "단일성"을 노출 시키므로 위에서 언급 한 모든 문제를 겪게됩니다.

싱글 톤 은 적절 하고 최소한으로 사용한다면 악한 것이 아닙니다 . 어떤 시점에서 싱글 톤의 요구를 대체하는 다른 좋은 디자인 패턴이 많이 있습니다 (또한 최상의 결과를 제공합니다). 그러나 일부 프로그래머는 그러한 좋은 패턴을 인식하지 못하고 싱글 톤을 악용하는 모든 경우에 싱글 톤을 사용합니다.

첫째, 수업과 협력자들은 먼저 부양 가족에게 초점을 맞추기보다는 의도 된 목적을 수행해야합니다. 수명주기 관리 (인스턴스 생성시 및 범위를 벗어난 경우)는 클래스 책임의 일부가되어서는 안됩니다. 이에 대한 가장 좋은 방법은 종속성 주입을 사용하여 종속성을 관리하기 위해 새 구성 요소를 만들거나 구성하는 것입니다.

종종 소프트웨어가 복잡 해져서 상태가 다른 Singleton 클래스의 여러 독립 인스턴스를 갖는 것이 합리적입니다. 이러한 경우 싱글 톤을 잡기 위해 코드를 커밋하는 것은 잘못입니다. 사용Singleton.getInstance()작은 간단한 시스템에서는 이 가능하지만 동일한 클래스의 다른 인스턴스가 필요할 때 작동하지 않거나 확장되지 않습니다.

어떤 클래스도 싱글 톤으로 생각해서는 안되지만, 클래스의 사용법이나 종속 항목을 구성하는 데 사용되는 방법이어야합니다. 빠르고 불쾌한 경우에는 이것이 중요하지 않습니다. 단지 하드 코딩은 파일 경로가 중요하지 않다고 말하지만 더 큰 응용 프로그램의 경우 DI를 사용하여 이러한 종속성을 더 적절하게 제거하고 관리해야합니다.

테스트에서 싱글 톤이 발생하는 문제는 하드 코딩 된 단일 사용 사례 / 환경의 증상입니다. 테스트 스위트와 많은 테스트는 각각 개별적이며 단일 코드 하드 코딩과 호환되지 않는 무언가를 분리합니다.

기본적으로 객체 지향 전역 변수이므로 필요하지 않은 방식으로 클래스를 디자인 할 수 있습니다.