- Gof/Singleton . . . . 132 matches
== Singleton ==
더 좋은 방법은 클래스 자신으로 하여금 자기자신의 단일 인스턴스를 유지하도록 만드는 것이다. 이 클래스는 인스턴스가 생성될 때 요청을 가로챔으로서 단일 인스턴스로 만들어지는 것은 보증한다. 또한, 인스턴스에 접근하는 방법도 제공한다. 이것이 바로 SingletonPattern이다.
SingletonPattern은 다음과 같은 경우에 사용한다.
* Singleton
* Instance operation (클래스의 메소드)을 정의한다. Instance 는 클라이언트에게 해당 Singleton의 유일한 인스턴스를 접근할 수 있도록 해준다.
* Singleton 자신의 유일한 인스턴스를 생성하는 책임을 가진다.
* 클라이언트는 오직 Singleton의 Instance operation으로만 Singleton 인스턴스에 접근할 수 있다.
SingletonPattern은 여러가지 장점을 가진다.
1. 클래스에 대한 접근이 오직 하나의 인스턴스에게로 제한된다. Singleton 클래스는 자기 자신의 단일 인스턴스를 캡슐화하기 때문에, 클라이언트가 언제, 어떻게 접근하던지 그 접근이 엄격하게 제어된다.
2. namespace를 줄인다. SingletonPattern은 global variable을 줄임으로서 global variable로 인한 namespace의 낭비를 줄인다.
3. 명령어와 표현을 확장시킬 수 있다. Singleton class는 subclass될 수 있고, 이 확장된 클래스의 인스턴스를 가지고 어플리케이션을 설정하는 것은 쉽다. run-time중에 필요한 경우에도 가능하다.
4. 여러개의 인스턴스를 허용한다. 프로그래머의 마음에 따라 쉽게 Singleton class의 인스턴스를 하나이상을 둘 수도 있도록 할 수 있다. 게다가 어플리케이션이 사용하는 인스턴스들을 제어하기 위해 동일한 접근방법을 취할 수 있다. 단지 Singleton 인스턴스에 접근하는 것을 보장하는 operation만 수정하면 된다.
5. class operation 보다 더 유연하다. 패키지에서 Singleton의 기능을 수행하기위한 또다른 방법은 class operation들을 사용하는 것이다. (C++에서의 static 함수나 Smalltalk에서의 class method 등등) 하지만, 이러한 언어적인 테크닉들은 여러개의 인스턴스를 허용하는 디자인으로 바꾸기 힘들어진다. 게다가 C++에서의 static method는 virtual이 될 수 없으므로, subclass들이 override 할 수 없다.
SingletonPattern 을 사용할 때 고려해야 할 사항들이 있다.
1. unique instance임을 보증하는 것. SingletonPattern의 경우도 일반 클래스와 마찬가지로 인스턴스를 생성하는 방법은 같다. 하지만 클래스는 늘 단일 인스턴스가 유지되도록 프로그래밍된다. 이를 구현하는 일반적인 방법은 인스턴스를 만드는 operation을 class operations으로 두는 것이다. (static member function이거나 class method) 이 operation은 unique instance를 가지고 있는 변수에 접근하며 이때 이 변수의 값 (인스턴스)를 리턴하기 전에 이 변수가 unique instance로 초기화 되어지는 것을 보장한다. 이러한 접근은 singleton이 처음 사용되어지 전에 만들어지고 초기화됨으로서 보장된다.
다음의 예를 보라. C++ 프로그래머는 Singleton class의 Instance operation을 static member function으로 정의한다. Singleton 또한 static member 변수인 _instance를 정의한다. _instance는 Singleton의 유일한 인스턴스를 가리키는 포인터이다.
Singleton class는 다음과 같이 선언된다.
class Singleton {
static Singleton* Instance ();
Singleton ();
- HolubOnPatterns/밑줄긋기 . . . . 15 matches
* ''''유일성'과''' ''''전역 접근'이란''' 조건을 만족시키면 Singleton 패턴의 실체화라 할 수 있다. Employee factory는 두 조건을 모두 만족시키므로 합당한 Singleton 패턴 실체화이다.
==== Singleton에서의 스레딩 이슈 ====
class Singleton
{ private static Singleton instance = null;
{ instance = new Singleton();
==== Singleton 죽이기 ====
* 또한 셧다운 훅 안에서 Singleton을 사용한다면 죽었다 되살아나는 좀비 Singleton을 만들 위험도 있다.
* 앞에서 객체를 생성할 때 Singleton 패턴과 Abstract Factory 패턴이 자주 함께 사용된다고 설명했다. '''그러므로''' Abstract Factory에 대해 좀 더 알아보기로 하자.
* Clock이 전형적인 GoF Singleton 임을 주의 깊게 보기 바란다.
* 좀 더 단순한 구현을 사용하려 시도해 보았늗네 Clock Singleton이 너무 일찍 생성되어 메뉴가 올바로 설정되지 않는 문제가 발생했다. '고전적'인 Singleton이 이런 문제를 해결해 준다.
* Java는 플렛폼 기반이기 때문에 나오는 문제로 '고전적'인 Singleton은 컴파일동안 해당 Singleton 클래스를 구성할 충분한 정보를 가지는 기회를 주기때문에 이런문제를 해결해 주는것이다. 역시 책을 읽은 보람이 있군! - [김준석]
- SingletonPattern . . . . 6 matches
프로그램 내에서 오직 하나만 존재해야만 하는 공용 객체에 대한 해결방법. (내용에 대해서는 ["Gof/Singleton"] 참조)
SingletonPattern 은 남용할 경우 위험하다. 여전히 Global object 이기 때문이다. 즉, Singleton 을 이용하는 모든 모듈은 Singleton Object 와 관계를 맺고 있는 것이 된다.
적절한 상속관계와 오브젝트를 인자로 넘겨주는 방법으로 Singleton 의 남용을 적절하게 줄일 수 있는 경우가 많다.
이전에 ProjectZephyrus 를 프로그래밍할때 느낀점이라면, 초반에 디자인을 할 때 일수록 Singleton 을 쓸 생각을 하지 않는것이 좋겠다는 점이다. 초반에 디자인을 할때엔 (특히 Conceptual Model 단계정도만 생각하고 프로그래밍에 들어가는 사람의 경우) 어떠한 클래스건 대부분이 인스턴스가 한개이다. -_- 그렇다고 이 모든 것들을 글로벌 객체로 만들어내는 것은 그리 좋지 않다. --["1002"]
- LearningGuideToDesignPatterns . . . . 3 matches
Pattern들은 각각 독립적으로 쓰이는 경우는 흔치 않다. 예를 들면, IteratorPattern은 종종 CompositePattern 과 같이 쓰이고, ObserverPattern과 MediatorPattern들은 전통적인 결합관계를 형성하며, SingletonPattern은 AbstractFactoryPattern와 같이 쓰인다. Pattern들로 디자인과 프로그래밍을 시작하려고 할때에, 패턴을 사용하는데 있어서 실제적인 기술은 어떻게 각 패턴들을 조합해야 할 것인가에 대해 아는 것임을 발견하게 될 것이다.
=== Singleton - Creational ===
SingletonPattern은 종종 AbstractFactoryPattern 을 만드는데 이용된다. (Related Patterns 참조)
- 1002/Journal . . . . 2 matches
~ 2 : 16 (지하철) using singleton wisely 읽고 이해
* DesignPatterns 연습차 간단하게 그림판을 구현해봄. 처음 간단하게 전부 MainFrame class 에 다 구현하고, 그 다음 Delegation 으로 점차 다른 클래스들에게 역할을 이양해주는 방법을 써 보았다. 그러던 중 MFC에서의 WinApp 처럼 Application class 를 ["SingletonPattern"] 스타일로 밖으로 뺐었는데, 계속 Stack Overflow 에러가 나는 것이였다. '어라? 어딘가 계속 재귀호출이 되나?..'
* ["SingletonPattern"] - Application Instance를 Global 객체로. 근데, 이는 일장일단인것 같다. 잘못하면 Application 중앙집중체제가 된다. Application 내에서 Delegation하는 객체들이 많은데, 그 덕에 Application 이 너무 중간 메세지 전달역할로만 작용하는것 같다. 뭐, ["FacadePattern"] 인양 된다면 모르겠지만. 이건 코드 커지고 난 뒤 두고볼 일인것 같다.
- Gof/State . . . . 2 matches
TCPState 서브클래스는 내부 상태를 가지지 않는다, 그러므로 TCPState는 공유될 수 있고, 각각 단지 하나의 인스턴스만이 요구되어진다. 이 TCPState 서브클래스의 각각의 유일한 인스턴스들은 정적함수인 Instance 로 얻어진다. (TCPState 서브클래스는 Singleton 으로 만들어진다.)
* State객체는 종종 SingletonPattern 으로 구현된다.
- MoreEffectiveC++/Techniques1of3 . . . . 2 matches
* 작성자주 : 이 부분은 Singleton 패턴과 연관해서 생각하면 재미있을 것 같다. Singleton 패턴이 DP에 논의될때 이것을 감안 안한것이 아쉽다. 1995년에 발간이라 STL도 제대로 다루지 않았고, C++의 기본적인 문법을 이용해 구현하였다. MEC++는 Techniques 부분은 C++의 문법과 개념을 극한으로 쓴다는 느낌이 든다.
- NSISIde . . . . 2 matches
-> Singleton 으로 있어야 할 녀석임.
-> AppClass 에 있으면 자동으로 Singleton 이 되겠군. ^-^;
- PatternCatalog . . . . 2 matches
* ["SingletonPattern"]
* ["Gof/Singleton"]
- 임인택/삽질 . . . . 2 matches
* C++ 에서 SingletonPattern 을 적용했는데.. 소멸자가 호출되지 않는것 같다.. 프로그램 종료시에 인스턴스를 강제로 삭제하였다. - 타이머 루틴에서 instance() 를 얻어왔는데. 타이머는 KillTimer 직후에 소멸되지 않는다.. 이로 인해.. 인스턴스가 삭제 된 후에 다시 생성되었었다...
''PatternHatching 에서의 Singleton 부분 참조''
- DPSCChapter1 . . . . 1 match
Design patterns also provide a succinct vocabulary with which to describe new designs and retrospectively explain existing ones. Patterns let us understand a design at a high level before drilling down to focus on details. They allow us to envision entire configurations of objects and classes at a large grain size and communicate these ideas to other designers by name. We can say, "Implement the database access object as a Singleton," rather than, "Let's make sure the database access class has just one instance. The class should include a class variable to keep track of the singl instance. The class should make the instance globally available but control access to it. The class should control when the instance is created and ..." Which would you prefer?
- EightQueenProblemSecondTryDiscussion . . . . 1 match
음.. 아직 구현은 안해보고 그냥 생각해본거지만, 체스 말과 보드가 타이트하게 연결되어도 큰 문제는 아닐 것 같은데요. 보드를 Singleton 으로 모든 Queen들이 공유하는 객체로 생각해도 좋을 것 같고요. (Queen에 눈이 달렸던지, 그렇지 않으면 체스 플레이어같이 Queen이 존재하고 있는 세계에 대한 답을 내려줄 신 (?) 이 존재하던지 둘중 하나가 될듯 하다는. ^^;) 아직 OO 관점으로는 그냥 생각만 해보는중. --석천
- Gof/Facade . . . . 1 match
보통 facade는 단일 오브젝트로 요구된다. 그래서Facade 객체는 종종 SingletonPattern으로 구현된다.
- HowToStudyDesignPatterns . . . . 1 match
''...but I always teach Composite Pattern, Strategy Pattern, Template Method Pattern, and Factory Method Pattern before I teach Singleton Pattern. They are much more common, and most people are probably already using the last two. ... ''
- InternalLinkage . . . . 1 match
C++ 에서 SingletonPattern 을 구현할때 다음과 같은 방식을 사용하고는 한다.
''암튼,결론이 어떻게 되나요? singleton 을 구현하는 용도로 자주 쓰는 static 변수를 사용하는 (주로 getInstance류) 메소드에서는 inline 을 쓰지 말자 인가요? --[1002]''
- 작은자바이야기 . . . . 1 match
* [Singleton] 패턴과 lazy initialization의 필요성에 대해 이야기했습니다.
Found 16 matching pages out of 7555 total pages (5000 pages are searched)
You can also click here to search title.
