Singleton 사용하시는 개발자분들 몇 %나 되시는지...

회원 전용입니다. 프로그래밍 관련 질문&논의는 금지!

Moderator: 류광

einzero
Posts: 119
Joined: 2004-06-22 15:37

Post by einzero »

zupet wrote:
비회원 wrote:
zupet wrote: 작업을 하시면서 Life Time 을 조절하는 싱글턴을 어느어느 부분에 사용해 보셨나요? 제가 ??갖게된 것은 싱글턴에 장점이 잘못 기술되었다는 것이 아니라 사용되지 않는 그 장점 때문에 많은 분들이 싱글턴을 무리해서 사용하고 있다는 것입니다. 경우에 따라서는 호출이 잦은 객체들까지 싱글턴을 사용하기 때문에 필요없는 부하를 발생시키면서 사용되지 않는 싱글톤의 장점 때문에 그 단점은 커버가 된다고 생각한다는 것입니다.
저 같은 경우 Rendering Library에서 소멸시기가 꼭 순서대로 이루어져야 하는 녀석들이 있었습니다. SpriteManager, TextureManager 이 두가지 녀석들이 전역 객체 였는데, SpriteManager 안에 들어 있는 Register된 Sprite Resource이 Shared Ptr로 Texture를 Reference하고 있는 경우 였구요. SpriteManager는 종료하면서 Register된 Sprite Resource를 모두 Discard 시킵니다. TextureManager의 경우에는 종료시 아직 삭제되지 않은 Texture 를 강제로 Discard 시키면서 Warning 메시지를 뱉는 구조였죠.... 이 경우 TextureManager가 먼저 종료되게 된다면 SpriteManager의 종료시 Discard 되는 Sprite Resource들이 참조 하고 있는 Texture의 Shared Ptr은 이미 delete된 녀석들이라서 문제가 생기겠지요. 물론 Singletone을 쓰지 않고서도 해결 할 수 있는 문제들입니다만...--;; 그리고 객체 호출의 부하는 inline function 을 통해서 충분히 없앨 수 있지 않나요?
저도 위와 같은 객체들을 쓰고 있고 물론 소멸할때 순서도 지켜주고 있습니다. 단지 다른점은 Life Time 이 조절 가능한 싱글턴을 쓰지 않고 WinMain 에서 필요한 객체들을 순서대로 초기화 함수를 호출해주고(DirectX를 관리하는 클래스는 반드시 HWND 생성 이후에 해야하니까요.) 어플리케이션이 종료해서 다시 WinMain 으로 돌아왔을때 해당 객체들의 종료를 호출해 주곤 합니다. 이렇게 생성/소멸 시점이 명료한 경우 싱글톤은 큰 의미를 갖지 못한다고 생각합니다.

p.s.왠지 이런식으로 계속 답글을 다니까 못된 아저씨가 되어버린 느낌.. 나도 나이가 어느덧.. 쿨럭~
하하 못된 아저씨라뇨 ^^; 충분히 좋은 말씀 해주시고 계십니다.. (아참 위에 두 비회원은 전부 제가 쓴 글입니다.. 도대체 이 컴퓨터에선 왜 자동 로그인이 안되는지 OTL) 일리 있는 말씀이십니다. 사실 제가 위에서 말한 작업도 zupet님 말씀대로 전역객체들을 통해서 충분히 해결할 수 있는 작업이구요. 제가 Singletone을 썼던것도 왠지 "전역객체로 하면 후져 보니이까~" 이런 생각에 썼던 점도 분명히 있는거 같네요 ^^ (사실 그래서 요샌 그냥 전역 객체 하나 선언하고 펑션통해서 리턴하는 방식을 주로 선호 합니다. singletone template header file을 include 하기 귀찮아서 -_-) 아무튼 저의 Singletone을 쓰는 방식은 아무래도 "이놈이 프로그램에 하나 밖에 없으니 다들 그리 알고 쓰세요 ~" 다른 사람들에게 의도를 알려주는 목적이 제일 클지도 --;; 게다가 매 frame마다 singletone object를 호출한 적은 없기 때문에 ^^ calling overhead나 if문 등은 아직 별 문제가 안되는듯 하네요.
Testors
Posts: 557
Joined: 2003-07-26 00:34
Location: (주)nFlavor
Contact:

Re: 제가 생각하기에는..

Post by Testors »

zupet wrote:#define gs_ConnCount ConnectionCount::GetSingleton()

이것이 단순히

extern ConnectionCount gs_ConnCount;

로 바꾸는 것 뿐입니다. 아.. 물론 소스파일 어딘가에 인스턴스도 하나 더 만들어야 합니다. 아마 ConnectionCount 의 내용이 있는 소스 파일에 한줄 더 타이핑을 해야하는 점이 좀 불편하겠네요.
타이핑의 불편함 말고도 해당 객체를 사용하지 않을경우에도 객체의 인스턴스가 생성된다는 문제가 있겠지요.
물론 이것은 "단순히 메모리 사용이나 '인스턴스 하나를 덜 만들자'라는 생각" 입니다. ^^
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Post by zupet »

Testors wrote:예를 들자면 싱글톤으로 구현한 BlahBlah 객체의 경우 다른 소스파일에서 해당 객체 접근시에 BlahBlah.h 파일만이 필요한데 반해 전역 변수를 쓰게 되면 해당 객체의 인터페이스 말고도 예를들면 Extern.h 와 같은 application framework 레벨의 소스코드도 include 하게 됩니다. 분명 Extern.h 에는 BlahBlah 말고도 다른 객체에 대한 정보들도 있을 것이고 결국 이런 구조는 불필요한 의존관계를 만들어 내겠지요..
제 경우는 Extern.h 파일을 따로 쓰지 않고 BlahBlah.h 파일에 extern BlahBlah g_blahblah; 를 한줄 넣어두고 BlahBlah.cpp 맨 윗부분에 BlahBlah g_blahblah; 를 한줄 넣어줍니다. 같은 헤더, CPP 안에 들어가기 때문에 읽을때도 좋고 어차피 싱글턴을 만들던 전역을 만들던 '이 클래스는 하나만 만들꺼야'라는건 개발하는 사람이 이미 알고 있으니 별로 상관 없곘죠.?
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Re: 제가 생각하기에는..

Post by zupet »

Testors wrote:
zupet wrote:#define gs_ConnCount ConnectionCount::GetSingleton()

이것이 단순히

extern ConnectionCount gs_ConnCount;

로 바꾸는 것 뿐입니다. 아.. 물론 소스파일 어딘가에 인스턴스도 하나 더 만들어야 합니다. 아마 ConnectionCount 의 내용이 있는 소스 파일에 한줄 더 타이핑을 해야하는 점이 좀 불편하겠네요.
타이핑의 불편함 말고도 해당 객체를 사용하지 않을경우〉?객체의 인스턴스가 생성된다는 문제가 있겠지요.
물론 이것은 "단순히 메모리 사용이나 '인스턴스 하나를 덜 만들자'라는 생각" 입니다. ^^
넵!! 윗 부분은 저도 동감합니다. 싱글턴을 쓰면 경우에 따라서 메모리를 한번 덜 쓸 수 있습니다.
Last edited by zupet on 2005-02-18 14:23, edited 1 time in total.
Testors
Posts: 557
Joined: 2003-07-26 00:34
Location: (주)nFlavor
Contact:

Post by Testors »

zupet wrote:제 경우는 Extern.h 파일을 따로 쓰지 않고 BlahBlah.h 파일에 extern BlahBlah g_blahblah; 를 한줄 넣어두고 BlahBlah.cpp 맨 윗부분에 BlahBlah g_blahblah; 를 한줄 넣어줍니다. 같은 헤더, CPP 안에 들어가기 때문에 읽을때도 좋고 어차피 싱글턴을 만들던 전역을 만들던 '이 클래스는 하나만 만들꺼야'라는건 개발하는 사람이 이미 알고 있으니 별로 상관 없곘죠.?
개인적으로 그와같은 스타일을 좋아하지 않는 이유를 쓰신글 바로 윗글에 달았습니다. :)

(몇초단위로 글이 올라오는건지.. 마치 실시간 채팅 하는것 같군요. 후후)
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
futurity
Posts: 65
Joined: 2003-01-23 14:40

Re: 제가 생각하기에는..

Post by futurity »

zupet wrote:게임 서버인가요? 제 생각에 많은 개발자분들이 게임 시작시 1초가 더 걸리는게 게임 중간 어디선가 1초간 정지하는 것보다 좋은 것이라고 생각할 것 같네요.

1초는 단순한 예일 뿐입니다.
전 클라이언트프로그래머입니다.
제가 말씀드리고 싶은것은 1초가 어디서 더 걸린다가 아니라
필요할때 1초를 쓴다입니다.

당연히 게임화면 랜더링중에 1초가 걸리면 당연히 안되죠.
그럴경우 게임화면 시작함수에서 미리 1초를 써야 겠죠.

그런데, 게임화면 나오지 않고, 로그인창인데
미리 1초를 쓸 필요가 있을까요?
저는 게임화면 초기화 함수에서 그때 전역으로 사용하겠습니다.

^^
Last edited by futurity on 2005-02-18 14:34, edited 1 time in total.
프로그래밍은 즐겁다...
futurity골뱅이korea.com
einzero
Posts: 119
Joined: 2004-06-22 15:37

Re: 제가 생각하기에는..

Post by einzero »

zupet wrote: extern ConnectionCount gs_ConnCount;
로 바꾸는 것 뿐입니다. 아.. 물론 소스파일 어딘가에 인스턴스도 하나 더 만들어야 합니다. 아마 ConnectionCount 의 내용이 있는 소스 파일에 한줄 더 타이핑을 해야하는 점이 좀 불편하겠네요.
zupet님의 글을 다시 보고 ^^ 또 한가지 말씀드리자면, 소스 파일에 한줄 더 타이핑 해야 되는 경우가 문제가 되어서 singletone을 쓴 경우가 있습니다 ;; ( 바로 어제 짠 소스 코드인데..) meta file로 부터 header file을 generate 하는 util 을 만들었는데, 어쩌다 보니 이놈이 각 meta file별로 unique 하게 전역 object를 하나씩 access 해야 되는 경우가 생기더라구요. 그렇다고 전역 object를 위해서 header file만 만들던 놈을 cpp file까지 같이 만들게 하자니 불편하고 -_-;; 그냥 간단히 마이어스 singletone 방식으로 header 에 선언하게 만들어 놓으니까 간단히 문제가 해결 되더군요!! 혹시 header file만 가지고 instance를 만들어 내는 방식이 singletone 말고 다른 방법으로도 가능한가요? 제가 이쪽 기반지식이 좀 모잘라서, 고수 여려분들의 의견을 듣고 싶습니다.
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

zupet wrote:
Testors wrote:예를 들자면 싱글톤으로 구현한 BlahBlah 객체의 경우 다른 소스파일에서 해당 객체 접근시에 BlahBlah.h 파일만이 필요한데 반해 전역 변수를 쓰게 되면 해당 객체의 인터페이스 말고도 예를들면 Extern.h 와 같은 application framework 레벨의 소스코드도 include 하게 됩니다. 분명 Extern.h 에는 BlahBlah 말고도 다른 객체에 대한 정보들도 있을 것이고 결국 이런 구조는 불필요한 의존관계를 만들어 내겠지요..
제 경우는 Extern.h 파일을 따로 쓰지 않고 BlahBlah.h 파일에 extern BlahBlah g_blahblah; 를 한줄 넣어두고 BlahBlah.cpp 맨 윗부분에 BlahBlah g_blahblah; 를 한줄 넣어줍니다. 같은 헤더, CPP 안에 들어가기 때문에 읽을때도 좋고 어차피 싱글턴을 만들던 전역을 만들던 '이 클래스는 하나만 만들꺼야'라는건 개발하는 사람이 이미 알고 있으니 별로 상관 없ㅤㄱㅖㅆ죠.?
'이 클래스를 하나만 만들꺼야!' 라는 생각을
작성하는 사람은 알겠지만 다른 사람이 그 생각을 알기란 정말 힘들죠

물론 작업을 계속 계속 하다 보면 알게 되겠지만
새로운 멤버가 들어올 수 도 있고, 멤버가 교체될 수도 있고..
그렇다고 매번 문서화 해놓을 수도 있는것도 아니고 (문서화 해놓는다고 그게 제대로 업데이트될리도 없고)

그럴바에는 아예 표현 자체를 딴생각 못하게 명확히 해놓는 것이 좋지 않나 싶습니다

예를 들면

Code: Select all

CTextureManager g_kTexMgr;
이런 형태는 작성자로 하여금 g_kIntroTexMgr; 혹은 g_kGameTexMgr ; 처럼 다른 텍스쳐 매니저의
존재 여부를 의심할 수 있게 하게 되지만

Code: Select all

class CTextureManager:
     protected ~CTextureManager();

CTextureManager& rkMgr=CTextureManager::GetSingleton();
이런 싱글턴 방식은 아예 전역 변수 생성도 막아버리고,
다른건 절대 존재하지 않는다라는걸 명확히 알려주니 의심할 여지가 없어지는 장점이..

물론 여기저기 싱글턴 쓰면 코드가 - -); 난감해져서 그리 좋아하지는 않지만
하나만 만들고 싶다라는 프로그래머의 의도를 표현하는 방법이란 점에서는 훌륭한 표현 방식이죠

ps. 예제는 텍스쳐매니저지만 솔직히 텍스쳐 매니저는 싱글턴을 쓰면 안되는 부분이라고 생각합니다.
Last edited by myevan on 2005-02-18 15:04, edited 1 time in total.
빗자루네 http://www.myevan.net >_<b
비회원

제 허접 생각에는

Post by 비회원 »

대강 적자면요.

주로 하나의 인스턴스만이 생성되서 여러 곳에서 참조되는 경우라 치고요.
그런 경우라면 주로 프로그램 구동시 초기화및 생성이 된 경우라 치고요.


전역의 경우: 소스코드상에서 명시적이라 좋다. 다른 파일에서 참조할려면 조금 짜증난다

싱글톤의 경우: 아무 파일에서나 참조하기 편해 좋다. 생성시점이 소스상에서 명시적이지 않은 것이 왠지 좀 걱정된다. 클래스간 대화 구조가 골 때릴 수 있다.

매개변수로 넘기는 경우: 명시적이라서 좋다. 타이핑이 귀찮고 클래스간 대화가 잘되도록 구조에 신경써야 한다
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

싱글턴을 쓰니까 아무 파일에서나 참조 하자!
라는건.. 작업 후반기에 무서운 현상(막 리빌드 10분;; ) 이 생기니 자제하시는게 좋습니다
어느정도 구축되면(별로 고칠일이 없어지는 시점) 선언되는 부분과 구현되는 부분 클래스를 후다닥 쪼개놓아야 (첨부터 하면 작업만 오래걸리니 주의!! )
나중에 연관관계 안꼬이고 깔끔한 빌드가 된다는 전설이 ... ~(- -)~
Last edited by myevan on 2005-02-18 15:09, edited 2 times in total.
빗자루네 http://www.myevan.net >_<b
jeddli
Posts: 138
Joined: 2001-08-06 09:00
Location: NeowizGames

전 조금 다른애기지만 GPG 1권의 단일체에 대해서..

Post by jeddli »

일반적인 심플한 Singleton 구현에선 단순하게 Singleton::Instance() 등을 호출하면
원하는 객첵을 얻을수 있게( 아직 생성이 안되어 있다면 생성을 해서 리턴해주는 ) 구현이 되는걸로 알고 있습니다. 그런데 GPG1권의 구현을 보면 어디엔가 전역변수를 선언하듯이 실제로 객체를 생성해줘야합니다. 왜 이렇게 해놨는지.. ( 한라인을 어딘가에 더 쳐야한다는게.. )
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Re: 제 허접 생각에는

Post by zupet »

비회원 wrote:싱글톤의 경우: 아무 파일에서나 참조하기 편해 좋다. 생성시점이 소스상에서 명시적이지 않은 것이 왠지 좀 걱정된다. 클래스간 대화 구조가 골 때릴 수 있다.
이 부분은 꼭 사실은 아닙니다. 초기화 이후에 접근하는 싱글턴도 어디까지나 '전역'의 다른 표현방식에 불과합니다. 위에 .h 파일과 .cpp 파일에 대한 얘기를 읽어보시면 이해가 쉽겠지만 싱글턴을 쓸때도 해당 클래스의 헤더파일은 꼭 include 시켜줘야 합니다. 싱글턴을 쓰면서 '이렇게 include 해줄꺼면 전역이랑 뭐가 달라!!!'라는 생긱이 이 문제를 깨닳은 시점이었죠.
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Post by zupet »

myevan wrote:'이 클래스를 하나만 만들꺼야!' 라는 생각을
작성하는 사람은 알겠지만 다른 사람이 그 생각을 알기란 정말 힘들죠

물론 작업을 계속 계속 하다 보면 알게 되겠지만
새로운 멤버가 들어올 수 도 있고, 멤버가 교체될 수도 있고..
그렇다고 매번 문서화 해놓을 수도 있는것도 아니고 (문서화 해놓는다고 그게 제대로 업데이트될리도 없고)

그럴바에는 아예 표현 자체를 딴생각 못하게 명확히 해놓는 것이 좋지 않나 싶습니다
넵.. 명시적인 이유로 그런 방식을 쓴다는 점으로는 도움이 될 것 같습니다. 그렇다면 역시 #define ~~~ 식으로 쓰면 곤란하겠군요. 개인적으로 그런 실수를 하게 원천적으로 막는다기 보다는 그냥 실수한 녀석 붙잡고 '술이나 묵자' 라고 말할 듯 싶긴 합니다만..

p.s.물론 비싼술 시켜먹고 술집에 버리고 와야죠. ^^
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

헉-_- 실수한 사람에게 술값을 내게하다닛!
그렇게 작성한 사람이 악당-_-)/ (... 이라고 하지만 죄악이 많다;; )
빗자루네 http://www.myevan.net >_<b
비회원

gpg가 재미있어 졌네요 ㅎㅎ

Post by 비회원 »

싱글톤..

생성 시점 조절..
전역변수 대신..
이러한 것보다는 이런것은 어떨까요 ㅎㅎ

굉장히 많은 객체들이 가지고 있을수 있는 디폴트 값은 단 하나로 족한다.

예를 들면
머트리얼의 상태를 가지고 있는 객체의 디폴트값을 싱글톤으로 만들어놓고
디폴트 머트리얼을 사용하는 많은 오브젝트들은 싱글톤을 가집니다.
상당히 많은 메모리를 절약할수 있습니다.

@ㅇㅇ@
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

싱글턴 자체 가지고 뭐라고 하는것보다는 -_-)>
나는 싱글턴으로 정말 아름다운 소스가 구축했다! (그때 프로그램팀 모두가 감동했었지..)
같은 눈물나는 수기를 모으는게 더 재밌을듯 싶어요

(흑흑 - - 내공이 없어 싱글턴 쓰고 고생한 기억만 .. )
빗자루네 http://www.myevan.net >_<b
비회원

함수 호출 할때의 오버해드..

Post by 비회원 »

Code: Select all


// 선언부

class CObject
{
  static CObject*   s_pInstance;
public:
  CObject();
  virtual ~CObject();

  static inline CObject* CreateInstance()   { return new CObject(); }
  static inline void DestroyInstance()         { delete s_pInstance; }
  static inline CObject* GetInstance()        { return s_pInstance; }

}

// 구현부

CObject* CObject::s_pInstance = NULL;

CObject::CObject()
{
  if( !s_pInstance )
  {
     s_pInstance = thils;
  }
}

CObject::~CObject()
{
  s_pInstance = NULL;
}

주제와는 조금 벗어난 이야기지만... (궁금함을 참지 못하고.. ^^;;)
가물 거리는 기억을 더듬어 적어봤습니다.
예전에 이렇게 구현했었는데요. 이렇게 하면 릴리즈 컴파일 할때 내부적으로 s_pInstance를 바로 호출 하지 않나요?

call 0x00402100
이렇게 콜을 안하고

mov eax, 0x01202300 // CObject::GetInstance();
이렇게요. 직접 포인터를 가져왔던거 같은데...
verena
Posts: 136
Joined: 2003-09-04 16:36

Re: Singleton 사용하시는 개발자분들 몇 %나 되시는지...

Post by verena »

zupet wrote:안녕하세요. 따라하기 마테리아를 장착한 메비~랍니다.

예전에도 팀에 있는 프로그래머 분과 얘길 하던 것인데.. 저는 클라이언트 환경.. 아니 대부분 게임 환경에서 Singleton 이 왜 사용되는지 이해를 못하고 있습니다. 최근 논란이 되었던 STL 관련 게시물에서 Singleton이 매우 쓸만하다고 적어주신 분이 계셨는데 막 생각난김에 다른 여러 분들께 물어보고 싶어졌습니다.

몇가지 장점들이 열거되어 있지만 그러한 장점들이 전역 인스턴스(MyClass g_class; )와 얼마나 다르고 어떻게 다르게 접근되는지 이해가 안가더군요. 물론 싱글턴의 장점이 한두가지 더 있지만 다양한 변화가 가능한 어플리케이션이 아니라 특정한 기능을 위해서 만들어지는 게임 프로그램에서 어떠한 점이 장점인지 모르겠습니다.

일단 제가 전역 인스턴스와 싱글턴이 별로 다를게 없거나 단점이라고 생각하는 이유는 아래와 같습니다.

1. 어차피 header 파일은 동일하게 include 시켜야 한다.
2. Instance 를 찾기 위해서 호출할때 작지만 오버헤드가 걸린다.
3. 자동 생성, 소멸은 전역 인스턴스나 Singleton 이나 크게 다르지 않다.

개발자들이 'goto는 쓰지 말라!' 와 '전역은 무조건 나쁘다' 와 같은 생각을 갖고 있기 때문에 어느정도 무의식적으로 Singleton 을 쓰게 되는게 아닌가 생각됩니다. 다른 개발자 분들의 생각이 궁금하네요. (가능하면 전역보다 싱글톤이 좋은 이유를 실제 사용 예를 들어서 들어봤으면 좋겠습니다.)

p.s.%%% 사용하시는 개발자분들 몇 %나 되시는지... <- 당분간 GPG 유행어가 될지도?

안녕하세요. ^^ [으 이 이후 멘트가 저는 없네요.. 얼른 만들어야할듯 ㅜㅜ~]

우선 잘 아시겠지만 singletone이 나오게된 동기에 대해서 몇자 적어 보겠습니다. singletone을 논하기에 앞서 디자인패턴이란 일종에 일반화된 결과물임을 먼저 밝혀? 드리겠습니다. 패턴이란 말 자체의 의미를 되세겨 보신다면 이해가 빨리 가실겁니다. 디자인패턴이란 영역에서 어떤 concept을 release하기위한 일반화라고 생각하시면 되겠습니다. 뭔말이지 ~_~

singletone이 나오게 된 동기

단어에서 알수 있듯이 어떤 클래스의 인스턴스가 프로그램내에서 단 하나만 존재하는 여러 경우에 이 클래스를 일반화하여 패턴화 시킨것이 singletone이 나오게 된 동기임은 잘 아실겁니다.

singletone의 핵심[goal]은?

인스턴스 생성에 대해서 단 하나만을 이루어지게하는 용법이나 메소드를 만들게 하는것이 가장 큰 핵심이겠습니다. 더 큰 핵심은 위의 방식에 대한 책임을 해당 클래스에게 전담 시키는것이라고 볼 수 있습니다. 책임할당- 이게 바로 객체지향의 핵심중 하나라고 볼 수 있습니다.
디자인패턴의 밑바탕이 객체지향이란 관점에서 볼때 새 인스턴스가 생성될 클래스에 직접 "한개의 객체만을 생성시키게 하는" 책임을 할당 하는것이 싱글톤의 핵심이라고 할 수 있습니다.

이런점에서 전역변수선언방법과는 비교대상에 있어서 기준이 다소 틀리다고 봅니다. 전역변수 이용법은 또다른 클래스의 메소드나 함수를 통해 "한개의 객체만"이라는 조건을 만족시켜야 하기 때문입니다. 여기서도 알 수 있듯이 한객의 객체와 관련된 메소드등을 한 클래스에 집중시킬 수 있다는것이 싱글톤의 가장 큰 핵심입니다.
물론 선언을 하나만 하고 더이상 선언하지 않으면 궂이 "한개의 객체만"이라는 조건을 만족시키기 위한 함수들을 만들 필요는 없습니다. 하지만 프로그램은 더이상 혼자 작업하지 않습니다. 다들 공감하시리라 봅니다. 다른 프로그래머의 실수로 해당객체를 하나더 전역적으로 선언하거나 지역적으로 선언해서 충분히 사용할 수 있습니다. 이런 부분에 대해서 전역변수기법은 막기 힘들겠죠. 설령 조건을 만족시키기 위한 함수가 있다 하더라도요... 싱글톤은 이렇던 저렇던 오직 한개만 생성됩니다. 이유는 잘 아실겁니다. 또 하나의 핵심은 바로 "확장성, 유지보수성" 이지 않을까 합니다.

싱글톤의 핵심은 더도 덜도 위의 사항말곤 없습니다.


다음은 zupet님께서 생각하시는 단점에 대해서 저의 생각을 전해 드리겠습니다. ^^ 굵게 해서 죄송해요^^;

1. 어차피 header 파일은 동일하게 include 시켜야 한다.

이 부분은 싱글톤과 전역변수 그 자체의 차이점이라기 보단 c++의 특성상 파일별로 모듈화 하기 위해서 어쩔수 없이 생기게된 c++의 관례라고 보는것이 맞지 않을까 합니다. 싱글톤을 쓰나 전역변수를 쓰나 둘다 c++에서 이루어지는것만큼 c++특성자체로 인해 차이점이 없다고 하는건 초점이 약간 잘못되지 않나 싶습니다. ^^ 디자인패턴은 java에서는 100% 효과를 발휘할 수 있으니깐요. 그만큼 c++언어자체가 java보다는 약간 객체지향이 아니다 정도가 되겠습니다.

2. Instance 를 찾기 위해서 호출할때 작지만 오버헤드가 걸린다.

네. 전역변수는 말그대로 직접 변수를 억세스하게 되지만, 싱글톤은 클래스의 static메소드를 통해서 접근하게 되니 당연히 전역변수보다 오버헤드가 많이 걸리는건 사실입니다. 이정도는 제 생각으론 무시할수 있지 않나 싶습니다. ^^;;

3. 자동 생성, 소멸은 전역 인스턴스나 Singleton 이나 크게 다르지 않다.

프로그램시작부터 끝까지 존재하는것이라면 당연히 둘다 생성 소멸에 있어선 차이점이 없습니다.

하지만 전역변수와 싱글톤의 가장 큰 차이점은 바로 싱글톤핵심란에서 언급해 드린 사항이라고 보시면 되겠습니다.

제가 언급한 싱글톤에 대해서 한번 생각해 보신다면 분명 전역변수와는 차이점이 있을거라고 느끼실겁니다. 그리고 저의 경우에는 싱글톤과 전역변수를통한 기법은 아예 비교조차하질 않습니다. 애시당초 둘은 표현할 수 있는 영역이 다르다고 보기 때문입니다.
근데 위에 든 사항은 구지 차이점을 들어 비교하면서 부각 시키는 이유는 많으신분?들께서 전역변수와 싱글톤에 대해서 많이들 비교를 하시니깐 좀 대중적인 방법으로 싱글톤의 특징이나 본질을 설명해 드린거라고 보시면 되겠습니다.

게임프로그램에 있어서 장점이라면...

솔직히 딱부러지게 게임에서만!의 장점을 서술하기는 힘듭니다. 장점이라면 이미 제가 언급한, 객체지향적~인 싱글톤이라고 볼 수 있겠습니다. 어디에 사용하느냐에 따라 장점이 될수도 단점이 될수도 있는게 도구이니깐요... 이부분에 대해서 딱히 시원하게 뭐라 말씀을 못드리겠네요.. ^^;

아주 원초적인 이야기이지만...

디자인패턴을 옹호하는건 아닙니다. 디자인패턴은 어떤 내용을 확립하는데에 있어서 "객체지향"이란 분야의 기본 원리원칙을 사용하고 있습니다. 소프트웨어 내부 구조나 흐름에 있어서 구조적으로 일반화 할 수 있는것들을 객체지향이란 원리원칙에 근거하여 모듈화 하는것이 디자인패턴의 핵심 과제입니다. 이 내용도 잘 아시겠지만 다시 되세겨 보신다면 수긍이 좀 가시지 않을까 합니다.

그러면 전이만~
Holic for Template +_+
비회원

싱글턴의 사용 이유에 대해서

Post by 비회원 »

제 생각에 싱글턴의 사용이유는 전역이다 아니다의 문제와는 조금 관점이 다릅니다.
싱글턴의 탄생 배경에는 어플리케이션에서 하나의 인스턴스만 있으면 되는 규칙을
언어적 차원에서 제어하기 위한 것입니다.
("이 클래스는 글로벌로 선언해서 쓰고 있으니까 다른사람은 인스턴스를 만들지 마세요" 라는
주석을 안읽는 사람들을 위한 것이라고도 볼수 있죠)

그런 문제(언어적 차원에서의 제어)가 필요 없다면 글로벌이든 싱글턴이든 아무 상관이 없는거죠.

그리고 싱글턴의 GetInstance() 부분에서의 NULL 체크 부분이 오버헤드로 염려된다면
Meyers Singleton을 사용하는것도 권장해 드립니다.
einzero
Posts: 119
Joined: 2004-06-22 15:37

Post by einzero »

Meyers Singletone도 결국엔 NULL 체크와 비슷한 오버헤드가 있을거라고 생각합니다. assembly code를 살펴보시면 static object의 생성여부를 체크하는 flag가 있어서 GetInstance() call 할때 이 flag를 항상 체크하는걸 알 수 있죠. 물론 이게 NULL 체크를 할때 생성되는 assembly code와는 비교 해본적은 없지만 ^^; static object라고 해도 공짜는 아니라는 거죠 ^^;;
* 인생은 열혈 *
Post Reply