🔒 Locked
Using a singleton for an application class?
Advertisement
Original Post
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Hey, it's the Singleton Thread of the Week.
Configuration::getInstance() can be considered as the one holding the defaults, but typically you'd override it.
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.
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? :)
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.
Advertisement