Skip to main content
gamedev.net
🔒 Locked

Using a singleton for an application class?

Started by beun 121 replies 23.1k views
Original Post
beun
beun
Hi, I'd like to know whether you think that using a singleton for an application class is a good idea or not. I have a class called Application which contains pointers to other classes like a logger class, a window class, a renderer class etc... All my classes and member functions need access to the logger class, some need access to the renderer or the window class. I assumed that it was a bad idea to pass a reference of the application class to the constructor of each class. So is it OK to use a singleton for my application class, or are there better methods? Thanks
Sneftel
Sneftel
Why have you determined that it's a bad idea to use globals for things like your logger, your renderer, etc.?
beun
beun
Yes, that's another method. So it's OK to use singletons?
DigiMan Shart
DigiMan Shart
I would said it is a fine idea, and in fact should be the only way you should make an application class. My team and I are doing so in our game engine. There may be better methods, but to my knowledge the singleton should work perfectly fine as we have used it for some time now. Hope that helps.
Alabama Man!!!
Sneftel
Sneftel
Quote:
Yes, that's another method. So it's OK to use singletons?

That isn't what I said... nor is it what I asked. I'm sure you already considered the globals option, but you jumped right over it and went on to singletons. Why? Your reasoning there is important in recommending a course of action.
beun
beun
Well, I thought that using globals was considered "evil", and that singletons have some more encapsulation.
Cromulent
Cromulent
Quote:
Original post by beun
Well, I thought that using globals was considered "evil", and that singletons have some more encapsulation.


Globals are only bad if they are poorly implemented. Just as there are some instances where the goto statement is actually the best course to take.

Completely ruling out an entire method seems foolish when there are certain times when it is a good idea to use them.
Sneftel
Sneftel
Quote:
Original post by beun
Well, I thought that using globals was considered "evil", and that singletons have some more encapsulation.


Well, no, singletons have no more effective encapsulation than globals. As for the "evil" designation, it really depends on who you ask. People who are trying for a pure OO design, with strict adherence at all times to every principle of object oriented development (whatever they are), feel that globals are evil, but you should not accept that as canon until you have learned why they feel globals are evil. People who adopt a mixed-paradigm development methodology with a lot of OO but not entirely OO (that is, most people) feel that globals are bad to overuse but useful and good in moderation.

What everyone but EVERYONE agrees on, though, is that there are a lot of programmers out there who love the great taste of globals but have heard from a friend that they're EEEVIL and therefore use singletons to pretend that they're not using globals (even though the way they use singletons is exactly the way they'd use globals), and that those programmers are evil. Hint: If you can replace a singleton with a global, that's a bad place to be using a singleton, regardless of your development methodology.
beun
beun
OK, so it's fine to use globals? Personally I haven't had any bad experiences with them, (and I also prefer (small) goto's over exception handling when it isn't necessary,) so I'll use globals for this case. Thanks for your quick responses [grin]

edit: And normally I wouldn't completely ignore things which are declared "evil [Period]", but I can understand some of the arguments of the global-bashers.
rip-off
rip-off
Quote:

Well, I thought that using globals was considered "evil", and that singletons have some more encapsulation.


Encapsulation of... what exactly?

You need to understand why globals are considered evil. Can you think of anything that makes a Singleton less "global" than a global instance?
Sneftel
Sneftel
Quote:
Original post by beun
OK, so it's fine to use globals?

Not necessarily, no. There's no easy answers here. You need to determine the costs and benefits of using a particular technique in a particular context. You're obviously just as satisfied with "globals not evil" as you were with "globals evil", and you need to learn to be dissatisfied with both.
beun
beun
Quote:
Original post by rip-off
Quote:

Well, I thought that using globals was considered "evil", and that singletons have some more encapsulation.


Encapsulation of... what exactly?

You need to understand why globals are considered evil. Can you think of anything that makes a Singleton less "global" than a global instance?

No, I realize that singletons are just fancy globals.
beun
beun
Quote:
Original post by Sneftel
Quote:
Original post by beun
OK, so it's fine to use globals?

Not necessarily, no. There's no easy answers here. You need to determine the costs and benefits of using a particular technique in a particular context. You're obviously just as satisfied with "globals not evil" as you were with "globals evil", and you need to learn to be dissatisfied with both.


As I said, I'm not satisfied with "evil [period]", I can understand some of the arguments.

edit: and I'm just trying to ask what some people think about which thing to do in this case.
Sneftel
Sneftel
Well, assuming you're going for the whole mixed paradigm thing, it seems to make a lot of sense to make your logger a singleton. Everything logs, after all, and a logger tends to exist "outside" of the rest of the application's organization.

As for the window or the renderer being globals... what would be the point there? Surely only a small portion of your code deals directly with putting things on the screen?

As for the application class, making an object which is just a holder for a bunch of variables, and then making that object global, has no functional advantages over just making the variables themselves globals.
beun
beun
Quote:
As for the window or the renderer being globals... what would be the point there? Surely only a small portion of your code deals directly with putting things on the screen?

Well, in a previous application I had a class 'Widget' for GUI widgets. Maybe it wasn't the best approach, but my widgets needed to have access to fonts and textures, and that's why I made my renderer class global. There are probably better methods.
Antheus
Antheus
Hey, it's the Singleton Thread of the Week.

struct Application {  Application(Configuration & c = Configuration.getInstance())    : log("Application", c)    , w(l, c)    , renderer(w, l, c)  {}  Logger log;  Window w;  Renderer rnd;};struct Renderer {  Renderer(Window & w, Logger & l, Configuration & c = Configuration.getInstance())    : log(l, "Renderer", c)    , w(w)  {}  Logger log;  Window & w;};struct Window {  Window(Logger & l, Configuration & c = Configuration.getInstance())    : log(l, "Window", c)  {    createWindow(c.getInt("Width"), c.getInt("Height"), c.getInt("Depth"));  }  Logger log;}struct Logger {  Logger(const std::string & n, Configuration & c = Configuration.getInstance())    : name(n)    , parent(Logger::getInstance())    , level(c.getInt("LogLevel")  {}  Logger(Logger & p, const std::string & n, Configuration & c = Configuration.getInstance())    : name(n)    , parent(&p)    , level(c.getInt("LogLevel")  {}  static Logger * getInstance() {    static Logger l("Global");    return &l  }  std::string * name;  int level;  Logger * parent;}


Configuration::getInstance() can be considered as the one holding the defaults, but typically you'd override it.
DevFred
DevFred
Quote:
Original post by beun
I thought that using globals was considered "evil"

So is abusing the Singleton pattern.

Quote:
Original post by Sneftel
People who are trying for a pure OO design, with strict adherence at all times to every principle of object oriented development

On a side note, how can these pure OO people use languages like C++ where the main function isn't part of an object? :)
Sneftel
Sneftel
First of all, it's rare for pure OO people to use C++. Secondly, however, don't think of pure OO guys as mindless zealots. If all your main function does is instantiate an object and call a method on it, that's not really a problem.
CmpDev
CmpDev
Quote:
Original post by DevFred

On a side note, how can these pure OO people use languages like C++ where the main function isn't part of an object? :)

Can you explain where main comes into OOA?
DevFred
DevFred
Quote:
Original post by CmpDev
Quote:
Original post by DevFred
On a side note, how can these pure OO people use languages like C++ where the main function isn't part of an object? :)

Can you explain where main comes into OOA?

That's exactly the point! main isn't OO, so pure OO people can't write C++ applications or Java applications (a static member function isn't much better than a normal function) or C# applications (same thing as Java). I guess PURE OO people program in Eiffel where something like main doesn't exist.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.