싱글 톤은 확실히 가장 오용되고 남용 된 패턴 중 하나입니다. 우리 중 많은 수가 Singletonitis에 감염되었습니다. 흥미롭게도 가까운 사촌 인 Monostate은 덜 유명하고 덜 사용됩니다. Monostate에 대한 당신의 의견은 무엇입니까? 좋든 싫든? Singleton을 사용하는 것이 더 나은 대안입니까? Singleton과 마찬가지로 사용법을 방해 하시겠습니까?모노 스테이트는 악마 싱글 톤의 좋은 사촌인가?
패턴을 사용하지 않는 이유는 무엇입니까?
업데이트 : 사람이 패턴이 아닌 양쪽 맞춤을 추가하기 때문에 싱글 톤 남용이 발생합니다. 그것은 종종 아무런 유익이없는 임의의 제약을 추가합니다. 정당화가없는 모노 스테이트를 사용하는 것은 아마도 덜 유해하지만 더 이상 정당화되지는 않습니다. 하나 이상의 인스턴스가있는 경우 유니버스가 축소되지 않으면 패턴으로 적용하지 않는 것보다 하나의 인스턴스 만 만듭니다.
나는 동의하지 않는다. 소프트웨어가 진정한 빌딩 블록 형식으로 발전한다면, 구조 엔지니어가 다리 또는 건물 디자인의 다양한 부분을 표준화 한 것과 유사한 방식으로 작업 방식을 표준화해야합니다. 가능하면 패턴을 항상 롤백해야합니다. –
질문은 패턴을 위해 패턴을 사용해야한다고 제안하지 않습니다. 패턴은 도구가 아닙니다. 소프트웨어 구성에서 반복적으로 발생하는 것과 동일한 테마입니다. 일상적인 코드 디자인에서 그러한 패턴을 식별하고 그 장점을 알고 있다면/죄수, 더 나은 소프트웨어를 만드는 데 도움이 될 것입니다. – Boon
"패턴으로 적용하지 마십시오"는 패턴으로 적용하는 것처럼 보이지만 - 귀하의 경우에는 "하나의 인스턴스 만 생성"패턴을 취합니다. 하나의 인스턴스 만 생성하는 것은 무료가 아니며, 공유 된 정보를 전달하기 위해 메서드 나 메서드 서명을 추가해야 할 수도 있습니다. – Boon
왜 사람들이 싱글 톤의 사용을 방해한다고 가정하고 있습니까? 싱글 톤에 대한 전반적인 설명을 만드는 것은 gotos, 전역 변수 등에 대한 일반적인 일반화와 같습니다. 그들 모두를위한 장소가 있습니다. 이러한 것들 중 어느 것도 "악의"가 아니며 오용으로 인해 악용되지는 않는다. 단지 제대로 사용되어야 함을 의미한다.
Monostate와의 계약은 객체를 구현하기 위해 객체의 구현에 대해 알 필요가 없다는 것입니다. 즉, 개체에 대한 참조를 얻기 위해 개체 getInstance 메서드 (Singleton s = Singleton :: getInstance; s.Method();)를 호출 할 필요가 없기 때문에 몇 번의 키 입력을 저장하면 일반 언어 구문을 사용하기 만하면됩니다 (Monostate ms; ms.Method();). 참으로 훌륭한 선.
모든 프로그래밍 언어가 악용 될 수 있기 때문에 모든 프로그래밍 언어 구조는 악의로 분류 될 수 있습니다.
합리적으로 사용하면 아무도 "악"또는 "양호"하지 않습니다.
모노 스테이트에서 내가 가진 가장 큰 문제는 그것을 사용하는 사람들이 혼란을 겪을 수 있다는 것입니다. 일반적으로 오브젝트의 새 인스턴스를 작성하는 경우, 인스턴스와 라이프 사이클이 고유 한 새 인스턴스 인 것으로 예상 할 수 있습니다. 나는 예기치 않은 행동을 나쁜 것으로 간주하기 때문에 싱글 톤을 선호한다.
두 패턴 중 어느 것이 나쁜지 여부는 싱글 톤이 오용되는 경향이 있지만 다른 패턴, 스위치 문, for 루프 또는 기타 언급 할 사항이 있습니다.
다음은 디자인 패턴 : 감마, 헬름, 존슨 및 Vlissides의 재사용 가능한 객체 지향 소프트웨어의 요소 127 페이지에서 발췌 한 것입니다.
를 사용하여 싱글 톤 패턴 때
악용이 오해되고 오해되기 때문에 실제로 악의가 생기는가?
예. –
번. – Skurmedel
는 Monostates의 정의에 따르면,이 메모입니다 ". Monostates 같은 방법으로 악을 SingletonsAreEvil 점이다"
가
나는 반드시 동의하지 않습니다. 기본적인 전제는 Singletons와 Monostate가 전역 변수이며, Globals가 악의적이므로 Singletons와 Monostates도 마찬가지입니다.
이 추론의 문제점에 대한 문제는 전역이 악조건 인 이유를 고려하지 않는다는 것입니다. 전역 변수는 실수로 외부에서 액세스 할 수있는 변수이기 때문에 실수로으로 악의적입니다. 유형이 지정되지 않은 언어가 변수를 참조하는 방식으로 변수를 간단하게 만들 수있는 것과 유사합니다.
싱글 톤과 모노 스탯은 동일한 유형의 문제를 일으킬 수 없습니다. 글로벌 스태틱을 "우발적으로"참조하는 것이 사실상 불가능하기 때문에 인스턴스 메소드를 호출 한 다음 인스턴스를 활용했습니다.
즉, 전역 변수는 미묘하고 문제가 발생하기 쉽지 않기 때문에 악조건입니다. 싱글 톤과 모노 스탯은 같은 종류의 문제를 일으키지 않기 때문에, 나는 같은 이유로 이들을 악으로 보지 않는다. 이것은 대부분의 사람들이이 논점에서 잘못되는 것처럼 보인다.
이제 싱글 톤과 모노 스탯이 다른 종류의 문제를 일으킬 수 있습니까? 확실한. 명백하게 TDD 사람들은 자동화 된 테스트를 통해 올바르게 테스트하기가 어렵 기 때문에 그 (것)들을 싫어합니다. 좋아요. 그렇지만 TDD를 사용하지 않는 사람들에게는 문제가 존재하지 않습니다.
물론 싱글 톤은 오용 될 수 있습니다. 인스턴스를 전달하는 것을 피하기 위해 이들을 단순히 사용하는 사람들은이를 오용하고 있습니다. Monostate가 싱글 톤보다 더 좋다고 생각합니다.
많은 사람들이 싱글 톤 대신에 공장 패턴을 제안하지만, 팩토리는 단순한 싱글 톤 생성기라고 생각합니다. 아니요, 정적 "인스턴스"메서드는 없지만 기본적으로 동일한 작업을 수행합니다 (팩터 리가 단일 인스턴스 개체를 만드는 경우). Factory.Create는 Singleton.Instance와 다르지 않습니다.
EDIT : 전역에 필적 싱글 톤과 Monostates의
일 양상들이 공유하고, 따라서 스레드 안전 아니라는 것이다. 다중 스레드 응용 프로그램을 수행하려는 경우 이것이 우려되지만,이를 알고 있으면 공유 객체에 대한 액세스를 직렬화하는 단계를 수행 할 수 있습니다. 이것이 아마도 일반적으로 세 가지 유형 모두가 문제를 일으키는 것으로 생각할 수있는 유일한 영역 일 것입니다.
음, 모노 스 테이트 은 싱글 톤 ... 그래서 똑같은 문제가 있습니다.
그 점은 훌륭하게 요약합니다. Monostate * 또는 * Singleton은 일반적으로 좋은 아이디어가 아닙니다. – Randolpho
모노 스테이트는 싱글 톤과 같지 않거나이 질문을 제기하지 않을 것입니다. https://segueuserfiles.middlebury.edu/xp/SingletonAndMonostate.pdf – Boon
싱글 톤과 모노 스테이트를 구분할 때이 백서는 성능, 다형성 및 구문과 같은 기술적 인 부분에서 멈 춥니 다.이 모든 것은 Java 구현에만 해당됩니다. 싱글 톤과 모노 스테이트 사이의 개념적 차이는 다루지 않습니다. –
하지만 글로벌없이 보장 할 수
public class SingleInstance
{
private static boolean exhausted = false;
public SingleInstance()
{
if (exhausted)
{
throw new IllegalStateException("only one instance allowed");
}
exhausted = true;
[...]
}
[...]
}
이렇게하면 Singleton 및 MonoState의 문제를 피할 수 있으며 단 하나의 인스턴스 만 있다는 것을 강제하고 명확하게 전달합니다.
더 정확하게 논의 할 수 있도록 두 패턴 중 어느 것을 설명해주십시오. – Karl