Design question

Started by
5 comments, last by Emmanuel Deloget 18 years, 1 month ago
Ok, first of all, please don't flame at me. I don't have much experience, and their is nobody here at work who can help me on those questions (apart from saying : "I like it that way, and not this way" without any good argument :/) So, now the question. I have a few classes of my program that I want to have only 1 instance of. At first, I used the singleton pattern. It worked fine, did its job. But I don't really like having to write : CFoo::GetInstance->DoSomething(); all the time :/ And I tried on one classe to do the following : All the members / variables are static, and now it looks like : CFoo::DoSomething(); I really find the second way more readable, easy to use. BUT I wonder if having a class with everything static in it is fine :/ A little voice in my head says that it's very dirty .At least I don't really have control on WHERE the members are initialized. But for some my classes that is not a problem. So the real question is : What would be the different methods to achieve my goals. And most important : why / why not ! I want to learn and not just be told : 'do this it's better than that' Thx in advance. [Edited by - paic on March 3, 2006 10:41:20 AM]
Advertisement
A quick comment... When you have a static function in a class like that, it's usually so that you can call the function and have it do whatever independently of the rest of the class's functions/members (kind of like a global function). Is this what you want to do?

Also, read this article, should answer your questions:

http://cplus.about.com/od/beginnerctutorial/l/aa080802c.htm
Once you have initialised your singleton, could you not just use GetInstance to return a pointer to that singleton, and then use the pointer to access the functions inside?
Having an all-static class is basically called a "monostate". It's a viable Singleton alternative, but as you pointed out, you can't really gaurantee initialization order of it's static data. You probably need an Init() in many cases.

If you like the Singleton pattern (and, hey, a lot of people do), but you don't like the ugly syntax, there is a very simple alternative:

If you have:

SomeClass::GetInstance()

you can "shorthand" it with a simple define:

#define Foo SomeClass::GetInstance()

Now in your code you just say

Foo->Whatever();
Depending on the design, one consideration is the longevity of the singleton.

Kuphryn
thx leiavoia. Apparently their is nothing really wrong in what I'm doing (well, may cause problems with dlls and threads, but I don't need those for the moment)
And It's not really monostate pattern in my case since even the methods are static (in monostate pattern, they are not static) but it's quite close.
Quote:Original post by paic
thx leiavoia. Apparently their is nothing really wrong in what I'm doing (well, may cause problems with dlls and threads, but I don't need those for the moment)
And It's not really monostate pattern in my case since even the methods are static (in monostate pattern, they are not static) but it's quite close.


You can also define something like this - it will hide how you access your singleton:
class SingletonAccessor{public:  MyClass *operator->() { return theSingleton::getInstance(); }};

It looks like a monostate, but it's not a monostate :) Anyway, it's not much different from
MyClass *myClass = theSingleton::getInstance();myClass->callFunc();

(which is perfectly legal and safe, providing that your singleton implementation is safe)

Regards,

This topic is closed to new replies.

Advertisement