Singleton 사용하시는 개발자분들 몇 %나 되시는지...
Moderator: 류광
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
Singleton 사용하시는 개발자분들 몇 %나 되시는지...
안녕하세요. 따라하기 마테리아를 장착한 메비~랍니다.
예전에도 팀에 있는 프로그래머 분과 얘길 하던 것인데.. 저는 클라이언트 환경.. 아니 대부분 게임 환경에서 Singleton 이 왜 사용되는지 이해를 못하고 있습니다. 최근 논란이 되었던 STL 관련 게시물에서 Singleton이 매우 쓸만하다고 적어주신 분이 계셨는데 막 생각난김에 다른 여러 분들께 물어보고 싶어졌습니다.
몇가지 장점들이 열거되어 있지만 그러한 장점들이 전역 인스턴스(MyClass g_class; )와 얼마나 다르고 어떻게 다르게 접근되는지 이해가 안가더군요. 물론 싱글턴의 장점이 한두가지 더 있지만 다양한 변화가 가능한 어플리케이션이 아니라 특정한 기능을 위해서 만들어지는 게임 프로그램에서 어떠한 점이 장점인지 모르겠습니다.
일단 제가 전역 인스턴스와 싱글턴이 별로 다를게 없거나 단점이라고 생각하는 이유는 아래와 같습니다.
1. 어차피 header 파일은 동일하게 include 시켜야 한다.
2. Instance 를 찾기 위해서 호출할때 작지만 오버헤드가 걸린다.
3. 자동 생성, 소멸은 전역 인스턴스나 Singleton 이나 크게 다르지 않다.
개발자들이 'goto는 쓰지 말라!' 와 '전역은 무조건 나쁘다' 와 같은 생각을 갖고 있기 때문에 어느정도 무의식적으로 Singleton 을 쓰게 되는게 아닌가 생각됩니다. 다른 개발자 분들의 생각이 궁금하네요. (가능하면 전역보다 싱글톤이 좋은 이유를 실제 사용 예를 들어서 들어봤으면 좋겠습니다.)
p.s.%%% 사용하시는 개발자분들 몇 %나 되시는지... <- 당분간 GPG 유행어가 될지도?
예전에도 팀에 있는 프로그래머 분과 얘길 하던 것인데.. 저는 클라이언트 환경.. 아니 대부분 게임 환경에서 Singleton 이 왜 사용되는지 이해를 못하고 있습니다. 최근 논란이 되었던 STL 관련 게시물에서 Singleton이 매우 쓸만하다고 적어주신 분이 계셨는데 막 생각난김에 다른 여러 분들께 물어보고 싶어졌습니다.
몇가지 장점들이 열거되어 있지만 그러한 장점들이 전역 인스턴스(MyClass g_class; )와 얼마나 다르고 어떻게 다르게 접근되는지 이해가 안가더군요. 물론 싱글턴의 장점이 한두가지 더 있지만 다양한 변화가 가능한 어플리케이션이 아니라 특정한 기능을 위해서 만들어지는 게임 프로그램에서 어떠한 점이 장점인지 모르겠습니다.
일단 제가 전역 인스턴스와 싱글턴이 별로 다를게 없거나 단점이라고 생각하는 이유는 아래와 같습니다.
1. 어차피 header 파일은 동일하게 include 시켜야 한다.
2. Instance 를 찾기 위해서 호출할때 작지만 오버헤드가 걸린다.
3. 자동 생성, 소멸은 전역 인스턴스나 Singleton 이나 크게 다르지 않다.
개발자들이 'goto는 쓰지 말라!' 와 '전역은 무조건 나쁘다' 와 같은 생각을 갖고 있기 때문에 어느정도 무의식적으로 Singleton 을 쓰게 되는게 아닌가 생각됩니다. 다른 개발자 분들의 생각이 궁금하네요. (가능하면 전역보다 싱글톤이 좋은 이유를 실제 사용 예를 들어서 들어봤으면 좋겠습니다.)
p.s.%%% 사용하시는 개발자분들 몇 %나 되시는지... <- 당분간 GPG 유행어가 될지도?
-
- Posts: 557
- Joined: 2003-07-26 00:34
- Location: (주)nFlavor
- Contact:
1. 전역변수는 한번도 사용되지 않을경우에도 인스턴스가 생성이 되는데 반해 싱글톤은 인스턴스가 생성되지 않습니다. 최초의 사용시까지 생성이 연기되지요..
2. 전역 인스턴스처럼 직접 접근하느냐 아니면 싱글톤처럼 메소드를 통해 접근하느냐는 꽤 큰 차이가 있습니다. 이것은 멤버변수를 public 으로 노출하느냐, 아니면 private 로 하고 get/set 메소드를 제공하느냐의 차이와 비슷하다고 봅니다. (예를 들자면 접근시 breakpoint 를 설정할 수 있다던가 혹은 log 를 남길 수 있다던가 하는 장점이 있겠지요)
2. 전역 인스턴스처럼 직접 접근하느냐 아니면 싱글톤처럼 메소드를 통해 접근하느냐는 꽤 큰 차이가 있습니다. 이것은 멤버변수를 public 으로 노출하느냐, 아니면 private 로 하고 get/set 메소드를 제공하느냐의 차이와 비슷하다고 봅니다. (예를 들자면 접근시 breakpoint 를 설정할 수 있다던가 혹은 log 를 남길 수 있다던가 하는 장점이 있겠지요)
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
Re: 싱글톤 한표..
긁적.. 싱글톤을 쓴다, 안쓴다에 대한 질문보다는 '이래서 싱글톤이 아니면 안된다!!!' 라는 부분이 어디일까 궁금한 것이죠. 저는 대부분의 경우 모양새가 좋거나 단순히 전역이 아니기 때문에 '싱글톤을 쓰자' 라는게 아닐까 생각하고 있습니다. 저희 팀에서도 많은 부분에서 싱글톤을 쓰고 있는데 저는 전역이 훨씬 좋습니다. 디버깅도 하기 좋고 Heap도 조금 덜 더럽히니까요.BERSERK wrote:게임 옵션 데이타나, 게임 데이타 DB 같은데서 주로 사용합니다.
과연 싱글턴에 전역 인스턴스보다 이러이러해서 안쓸 수 없다!! 라는 부분이 어떤 부분들일까요?
-
- Posts: 103
- Joined: 2004-06-12 11:27
싱글톤 -1 표
저도 싱클턴이 왜 좋은줄 몰겠네요..
여기 왈,
http://www.c2.com/cgi/wiki?SingletonsAreEvil
"싱글톤은 악이다"
추가로 visitor도 그 악 중 하나로 치더군요
여기 왈,
http://www.c2.com/cgi/wiki?SingletonsAreEvil
"싱글톤은 악이다"
추가로 visitor도 그 악 중 하나로 치더군요
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
인스턴스 생성 시점을 조절해야 할 필요가 있을때는 어떤 경우일까요? 가령 DB 연결이 필요 하다던지 특정 작업 이후에 생성되지 않으면 안되는 경우가 때문이라면 대부분 게임 서버/클라이언트는 그 시점을 정확히 알 수 있습니다. 단순히 메모리 사용이나 '인스턴스 하나를 덜 만들자'라는 생각 때문이 아니라면 어떤 부분이 있을까요?Testors wrote:1. 전역변수는 한번도 사용되지 않을경우에도 인스턴스가 생성이 되는데 반해 싱글톤은 인스턴스가 생성되지 않습니다. 최초의 사용시까지 생성이 연기되지요..
직접 작성했던 코드에서 싱글톤의 접근 제한을 걸거나 접근에 대한 이벤트(log등을 남기기 위해서)를 위해서 싱글톤을 써보신적이 있으신지요? 물론 여러가지 가능성을 열어두기 위해서 더 나온 코딩을 하는게 프로그래머로서의 자세일지 모르겠지만 쓸지도 모르는 경우를 대비해서 하는 설계는 그다지 도움이 안되는 경우가 많더군요.Testors wrote:2. 전역 인스턴스처럼 직접 접근하느냐 아니면 싱글톤처럼 메소드를 통해 접근하느냐는 꽤 큰 차이가 있습니다. 이것은 멤버변수를 public 으로 노출하느냐, 아니면 private 로 하고 get/set 메소드를 제공하느냐의 차이와 비슷하다고 봅니다. (예를 들자면 접근시 breakpoint 를 설정할 수 있다던가 혹은 log 를 남길 수 있다던가 하는 장점이 있겠지요)
그리고 단순히 get/set 과 접근 시점을 알기 위해서는 전역 함수가 인스턴스를 리턴하는 방법이 있습니다. 싱글턴든 '단지 하나, only one' 의 인스턴스를 만들기 위한 기법이지 인스턴스에 접근을 알아내기 위해서 쓰는 기법을 기술한 것이 아닙니다. 핵심은 '왜 싱글턴'인가 입니다.
잘 만들어진 Singletone 은 Life Time을 쉽게 조절할 수 있다는게 장점이 될 수 있지 않을까요? ( Modern C++ Design 같은 책등에 나온 Singletone 류..) 단순히 static Object를 선언해서 그걸 return 하는 기능만 가진 Singletone은 사실상 전역변수랑 차이가 없지요.. ( HL2 Source를 보시면, Singletone을 쓰지 않고, 그냥 g_xxx 로 전역변수 난무하는 스타일이지요) 물론 저는 전역변수보다는 이미 만들어진 Singletone template을 통해서 선언하는게 오히려 더 간편하고 깔끔하기 때문에 Singletone을 선호하는 스타일 입니다.
-
- Posts: 103
- Joined: 2004-06-12 11:27
굳이 하나 들자면..
제가 생각한 바는
비주얼 어시스트 깔고 싱글턴 쓰면
Singleton:: 칠때 멤버 리스트가 나와서 전역을 좀더 쉽게 쓸수 있다는 점..
전역변수를 사용할때 일일이 extern 으로 선언해서 안써도 된다는 점.. (잠깐 쓰기위해 선언하고
다시 지우는게 일이라면 또 일일수 있기 때문에..)
저도 전역멤버를 어떻게 관리해야 하나.. 하다가 싱글톤도 써보고.. (이거 쓰다 팀장님한테 뒤지게 혼남)
namespace 로도 전역을 관리해보고(싱글턴보다 더 혼남) 하다가 결국 그냥 필요한곳에 전역선언하고
사용하는 중입니다 ㅜㅜ
저도 왜 싱글톤이 저 이유말고 써야 하는건지 알고 싶네요
비주얼 어시스트 깔고 싱글턴 쓰면
Singleton:: 칠때 멤버 리스트가 나와서 전역을 좀더 쉽게 쓸수 있다는 점..
전역변수를 사용할때 일일이 extern 으로 선언해서 안써도 된다는 점.. (잠깐 쓰기위해 선언하고
다시 지우는게 일이라면 또 일일수 있기 때문에..)
저도 전역멤버를 어떻게 관리해야 하나.. 하다가 싱글톤도 써보고.. (이거 쓰다 팀장님한테 뒤지게 혼남)
namespace 로도 전역을 관리해보고(싱글턴보다 더 혼남) 하다가 결국 그냥 필요한곳에 전역선언하고
사용하는 중입니다 ㅜㅜ
저도 왜 싱글톤이 저 이유말고 써야 하는건지 알고 싶네요
-
- Posts: 980
- Joined: 2003-06-01 12:28
- Location: 모대학
- Contact:
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
각 패턴은 무리해서 끼워 맞추기 보다는 그 패턴이 적당한 적제적소에 사용하는게 가장 좋은 방법이더군요. 어떻게 보면 디자인 패턴 책의 단점인데 여러가지 칭찬과 더불어 거기 나와있는 예제들이 너무 보기 좋기 때문에 비슷해 보일때 무조건 패턴을 쓰려고 노력하게 된다는 거죠. 물론 잘 나올때도 있지만 저는 그렇게 무리하게 고생하다가 '반드시 패턴일 필요는 없잖아?' 라는 깨닮음(???)을 얻었습니다.chadr wrote:저도 게임상 단 한개만 생성되는 객체는 싱글톤으로 할까 생각중에 있습니다.. 여기에 다른분들께서 써주시는 의견을 참고해서 고민해봐야겠군요.
어떤분이 디자인 패턴이 '잡기술이다'라고 하셨는데 어떻게 보면 이런 의미에서 긍극적인 솔루션은 아니라는 말을 하고 싶었는지도 모르죠.
![:(](./images/smilies/icon_frown.gif)
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
작업을 하시면서 Life Time 을 조절하는 싱글턴을 어느어느 부분에 사용해 보셨나요? 제가 의문을 갖게된 것은 싱글턴에 장점이 잘못 기술되었다는 것이 아니라 사용되지 않는 그 장점 때문에 많은 분들이 싱글턴을 무리해서 사용하고 있다는 것입니다. 경우에 따라서는 호출이 잦은 객체들까지 싱글턴을 사용하기 때문에 필요없는 부하를 발생시키면서 사용되지 않는 싱글톤의 장점 때문에 그 단점은 커버가 된다고 생각한다는 것입니다.비회원 wrote:잘 만들어진 Singletone 은 Life Time을 쉽게 조절할 수 있다는게 장점이 될 수 있지 않을까요? ( Modern C++ Design 같은 책등에 나온 Singletone 류..) 단순히 static Object를 선언해서 그걸 return 하는 기능만 가진 Singletone은 사실상 전역변수랑 차이가 없지요.. ( HL2 Source를 보시면, Singletone을 쓰지 않고, 그냥 g_xxx 로 전역변수 난무하는 스타일이지요) 물론 저는 전역변수보다는 이미 만들어진 Singletone template을 통해서 선언하는게 오히려 더 간편하고 깔끔하기 때문에 Singletone을 선호하는 스타일 입니다.
-
- Posts: 18
- Joined: 2002-10-02 11:58
- Location: 위메이드 엔터테인먼트
정말 쓰기 편하죠
라이브러리로 구성된 프로젝트라면 싱글톤이 정말 편하죠. 그래서 저도 예전에 가장 사랑하는(?) 패턴 이었습니다.
그런데 좀 쓰다보니 이놈이 객체 지향으로 가는 걸림돌로 작용하기 시작하더라고요..
그래서 이걸 대체하기 위해 무진장 애를 쓰다 결국 안쓰게 됬지만..
아직까지도 애용합니다.
작은 프로젝트를 할땐 좋지만, oop를 신경쓰다보면 너무 남발할 수가 없게 되던데요 ^^.
ps. 아 그리고 멤버변수에 static으로 두더라도 이걸 static inline함수로 사용하면 호출시의 오버해드가 발생하지 않던 걸로 기억하는데.. 아닌가요? 기억이 가물가물...
그런데 좀 쓰다보니 이놈이 객체 지향으로 가는 걸림돌로 작용하기 시작하더라고요..
그래서 이걸 대체하기 위해 무진장 애를 쓰다 결국 안쓰게 됬지만..
아직까지도 애용합니다.
작은 프로젝트를 할땐 좋지만, oop를 신경쓰다보면 너무 남발할 수가 없게 되던데요 ^^.
ps. 아 그리고 멤버변수에 static으로 두더라도 이걸 static inline함수로 사용하면 호출시의 오버해드가 발생하지 않던 걸로 기억하는데.. 아닌가요? 기억이 가물가물...
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
Re: 정말 쓰기 편하죠
inline이 되어도 if 문은 없어지지 못합니다. 속도를 얘기한다면 포인터 호출보다 전역 호출이 빠르다는 것도 한가지 더 포함되죠.김석호 wrote:ps. 아 그리고 멤버변수에 static으로 두더라도 이걸 static inline함수로 사용하면 호출시의 오버해드가 발생하지 않던 걸로 기억하는데.. 아닌가요? 기억이 가물가물...
저 같은 경우 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 을 통해서 충분히 없앨 수 있지 않나요?zupet wrote:작업을 하시면서 Life Time 을 조절하는 싱글턴을 어느어느 부분에 사용해 보셨나요? 제가 의문을 갖게된 것은 싱글턴에 장점이 잘못 기술되었다는 것이 아니라 사용되지 않는 그 장점 때문에 많은 분들이 싱글턴을 무리해서 사용하고 있다는 것입니다. 경우에 따라서는 호출이 잦은 객체들까지 싱글턴을 사용하기 때문에 필요없는 부하를 발생시키면서 사용되지 않는 싱글톤의 장점 때문에 그 단점은 커버가 된다고 생각한다는 것입니다.비회원 wrote:잘 만들어진 Singletone 은 Life Time을 쉽게 조절할 수 있다는게 장점이 될 수 있지 않을까요? ( Modern C++ Design 같은 책등에 나온 Singletone 류..) 단순히 static Object를 선언해서 그걸 return 하는 기능만 가진 Singletone은 사실상 전역변수랑 차이가 없지요.. ( HL2 Source를 보시면, Singletone을 쓰지 않고, 그냥 g_xxx 로 전역변수 난무하는 스타일이지요) 물론 저는 전역변수보다는 이미 만들어진 Singletone template을 통해서 선언하는게 오히려 더 간편하고 깔끔하기 때문에 Singletone을 선호하는 스타일 입니다.
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
저도 위와 같은 객체들을 쓰고 있고 물론 소멸할때 순서도 지켜주고 있습니다. 단지 다른점은 Life Time 이 조절 가능한 싱글턴을 쓰지 않고 WinMain 에서 필요한 객체들을 순서대로 초기화 함수를 호출해주고(DirectX를 관리하는 클래스는 반드시 HWND 생성 이후에 해야하니까요.) 어플리케이션이 종료해서 다시 WinMain 으로 돌아왔을때 해당 객체들의 종료를 호출해 주곤 합니다. 이렇게 생성/소멸 시점이 명료한 경우 싱글톤은 큰 의미를 갖지 못한다고 생각합니다.비회원 wrote:저 같은 경우 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 을 통해서 충분히 없앨 수 있지 않나요?zupet wrote:작업을 하시면서 Life Time 을 조절하는 싱글턴을 어느어느 부분에 사용해 보셨나요? 제가 ??갖게된 것은 싱글턴에 장점이 잘못 기술되었다는 것이 아니라 사용되지 않는 그 장점 때문에 많은 분들이 싱글턴을 무리해서 사용하고 있다는 것입니다. 경우에 따라서는 호출이 잦은 객체들까지 싱글턴을 사용하기 때문에 필요없는 부하를 발생시키면서 사용되지 않는 싱글톤의 장점 때문에 그 단점은 커버가 된다고 생각한다는 것입니다.비회원 wrote:잘 만들어진 Singletone 은 Life Time을 쉽게 조절할 수 있다는게 장점이 될 수 있지 않을까요? ( Modern C++ Design 같은 책등에 나온 Singletone 류..) 단순히 static Object를 선언해서 그걸 return 하는 기능만 가진 Singletone은 사실상 전역변수랑 차이가 없지요.. ( HL2 Source를 보시면, Singletone을 쓰지 않고, 그냥 g_xxx 로 전역변수 난무하는 스타일이지요) 물론 저는 전역변수보다는 이미 만들어진 Singletone template을 통해서 선언하는게 오히려 더 간편하고 깔끔하기 때문에 Singletone을 선호하는 스타일 입니다.
p.s.왠지 이런식으로 계속 답글을 다니까 못된 아저씨가 되어버린 느낌.. 나도 나이가 어느덧.. 쿨럭~
-
- Posts: 557
- Joined: 2003-07-26 00:34
- Location: (주)nFlavor
- Contact:
이건 'only one' 의 특성과는 관계 없는 얘기지만.. ^^;zupet wrote:저도 위와 같은 객체들을 쓰고 있고 물론 소멸할때 순서도 지켜주고 있습니다. 단지 다른점은 Life Time 이 조절 가능한 싱글턴을 쓰지 않고 WinMain 에서 필요한 객체들을 순서대로 초기화 함수를 호출해주고(DirectX를 관리하는 클래스는 반드시 HWND 생성 이후에 해야하니까요.) 어플리케이션이 종료해서 다시 WinMain 으로 돌아왔을때 해당 객체들의 종료를 호출해 주곤 합니다. 이렇게 생성/소멸 시점이 명료한 경우 싱글톤은 큰 의미를 갖지 못한다고 생각합니다.비회원 wrote:저 같은 경우 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 을 통해서 충분히 없앨 수 있지 않나요?
lifetime 을 객체 스스로 관리하게 되면 해당 인터페이스가 application framework 레벨까지 노출될 필요가 없어지겠지요. 이를테면 SpriteManager.h 와 TextureManager.h 같은 파일을 WinMain.cpp 에 include 하지 않아도 된다는 얘기.
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
-
- Posts: 65
- Joined: 2003-01-23 14:40
제가 생각하기에는..
적절한 예인지 모르겠네요.
위에 말씀하는데로 생성시점을 조절할수 있고 그게 전역단일객체일때 쓰겠죠.
2가지 예문을 드리자면, 좀 오버격이 있지만...
1. 생성시점 조절
CDatabaseSet 클래스가 있습니다.
예를 들어서 이 클래스를 초기화 하는데 1초가 걸리다고 생각해보죠.
이걸 꼭 초기화 할 필요는 없습니다. 예를 들어서
누군가가 원할때 그때 초기화를 해도 않 늦는거죠.
수많은 클래스들중에서 누가 이걸 언제 호출할지 모르니깐
미리 생성하는 것보다는 싱글톤을 이용해서 최초 호출한때 생성한다면
초기실행시간을 1초 단축할수 있겠죠. ㅎㅎ
2. 전역단일객체
class ConnectionCount
{
protected:
ConnectionCount();
~ConnectionCount();
}
#define gs_ConnCount ConnectionCount::GetSingleton()
라는 클래스는 서버연결할때 마다 카운트를 증가시킵니다.
위에처럼 생성자가 protected 이므로 자기자신만 자신을 생성할수 있고,
gs_ConnCount 정의된 define문으로만 객체를 접근할수 있습니다.
그러므로 전역단일객체로 조금 명백해 집니다. (전역변수로도 할수 있으려나?)
----------------------------------
위에 내용이 그냥 전역변수로도 비슷한 효과를 낼수 있을듯합니다.
하지만, 전역변수로 비슷한 효과를 만드는 것보다는
많이 인증된 패턴을 사용하면 좋타고 생각됩니다. ㅎㅎ
전역변수마다 일일이 해주기 힘드니깐 그냥 상속만 받아도 효과를 내주니
좋아서 쓰질 않을까요?
전 싱글톤을 무지 많이 씁니다. ㅎㅎ
위에 말씀하는데로 생성시점을 조절할수 있고 그게 전역단일객체일때 쓰겠죠.
2가지 예문을 드리자면, 좀 오버격이 있지만...
1. 생성시점 조절
CDatabaseSet 클래스가 있습니다.
예를 들어서 이 클래스를 초기화 하는데 1초가 걸리다고 생각해보죠.
이걸 꼭 초기화 할 필요는 없습니다. 예를 들어서
누군가가 원할때 그때 초기화를 해도 않 늦는거죠.
수많은 클래스들중에서 누가 이걸 언제 호출할지 모르니깐
미리 생성하는 것보다는 싱글톤을 이용해서 최초 호출한때 생성한다면
초기실행시간을 1초 단축할수 있겠죠. ㅎㅎ
2. 전역단일객체
class ConnectionCount
{
protected:
ConnectionCount();
~ConnectionCount();
}
#define gs_ConnCount ConnectionCount::GetSingleton()
라는 클래스는 서버연결할때 마다 카운트를 증가시킵니다.
위에처럼 생성자가 protected 이므로 자기자신만 자신을 생성할수 있고,
gs_ConnCount 정의된 define문으로만 객체를 접근할수 있습니다.
그러므로 전역단일객체로 조금 명백해 집니다. (전역변수로도 할수 있으려나?)
----------------------------------
위에 내용이 그냥 전역변수로도 비슷한 효과를 낼수 있을듯합니다.
하지만, 전역변수로 비슷한 효과를 만드는 것보다는
많이 인증된 패턴을 사용하면 좋타고 생각됩니다. ㅎㅎ
전역변수마다 일일이 해주기 힘드니깐 그냥 상속만 받아도 효과를 내주니
좋아서 쓰질 않을까요?
전 싱글톤을 무지 많이 씁니다. ㅎㅎ
프로그래밍은 즐겁다...
futurity골뱅이korea.com
futurity골뱅이korea.com
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
-
- Posts: 557
- Joined: 2003-07-26 00:34
- Location: (주)nFlavor
- Contact:
역시 'only one 을 보장해야 하는가?' 와는 그다지 관계가 없는 얘기이고 위에 올린 글의 확장이긴 합니다만.. ^^;zupet wrote:WinMain에선 안해도 되지만 어디선가는 생성이나 소멸 순서에 대해서는 어딘가에서 신경 써줘야 하지 않나요?
어짜피 로그시스템이나 프린터스풀과 같이 1개 이상의 인스턴스가 존재할 이유가 없는 객체라면 싱글톤처럼 lifetime 을 스스로 관리하는게 좋다고 봅니다. 예를 들자면 싱글톤으로 구현한 BlahBlah 객체의 경우 다른 소스파일에서 해당 객체 접근시에 BlahBlah.h 파일만이 필요한데 반해 전역 변수를 쓰게 되면 해당 객체의 인터페이스 말고도 예를들면 Extern.h 와 같은 application framework 레벨의 소스코드도 include 하게 됩니다. 분명 Extern.h 에는 BlahBlah 말고도 다른 객체에 대한 정보들도 있을 것이고 결국 이런 구조는 불필요한 의존관계를 만들어 내겠지요..
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
-
- Posts: 2764
- Joined: 2003-05-13 03:34
- Location: NCSOFT LE팀
Re: 제가 생각하기에는..
게임 서버인가요? 제 생각에 많은 개발자분들이 게임 시작시 1초가 더 걸리는게 게임 중간 어디선가 1초간 정지하는 것보다 좋은 것이라고 생각할 것 같네요.futurity wrote:1. 생성시점 조절
CDatabaseSet 클래스가 있습니다.
예를 들어서 이 클래스를 초기화 하는데 1초가 걸리다고 생각해보죠.
이걸 꼭 초기화 할 필요는 없습니다. 예를 들어서
누군가가 원할때 그때 초기화를 해도 않 늦는거죠.
수많은 클래스들중에서 누가 이걸 언제 호출할지 모르니깐
미리 생성하는 것보다는 싱글톤을 이용해서 최초 호출한때 생성한다면
초기실행시간을 1초 단축할수 있겠죠. ㅎㅎ
전역으로 위와 같이 만들었을때의 싱글턴에 비해서 어떤 단점이 있을까요? 이것이 주요 질문 사항입니다.futurity wrote:2. 전역단일객체
class ConnectionCount
{
protected:
ConnectionCount();
~ConnectionCount();
}
#define gs_ConnCount ConnectionCount::GetSingleton()
라는 클래스는 서버연결할때 마다 카운트를 증가시킵니다.
위에처럼 생성자가 protected 이므로 자기자신만 자신을 생성할수 있고,
gs_ConnCount 정의된 define문으로만 객체를 접근할수 있습니다.
그러므로 전역단일객체로 조금 명백해 집니다. (전역변수로도 할수 있으려나?)
#define gs_ConnCount ConnectionCount::GetSingleton()
이것이 단순히
extern ConnectionCount gs_ConnCount;
로 바꾸는 것 뿐입니다. 아.. 물론 소스파일 어딘가에 인스턴스도 하나 더 만들어야 합니다. 아마 ConnectionCount 의 내용이 있는 소스 파일에 한줄 더 타이핑을 해야하는 점이 좀 불편하겠네요.