singleton design issue
Author
I have a class that loads and stores ini values. It is the only place ini values are loaded, and as such just about any module in the program could use it. To me it just screams singleton. What other ways are there to design this?
Quote:Original post by stonemetalWhy would just about any module need to use this data? Any relevant data should be passed to the appropriate module, or the module should be able to query another module (E.g. a parent) for that data.
I have a class that loads and stores ini values. It is the only place ini values are loaded, and as such just about any module in the program could use it. To me it just screams singleton. What other ways are there to design this?
Singletons are the root of all evil, as I've recently been finding out [sad]
Instead of:
Write:
Everytime you hear something screaming Singleton, don't listen.
[Edited by - rip-off on January 9, 2008 8:29:52 AM]
class INIStuff : public Singleton... {...};class Video { Video() { INIStuff &stuff = INIStuff::getReference(); setup(stuff.get("graphics.width"), stuff.get("graphics.height"), stuff.get("graphics.fullscreen")); }};Write:
class INIStuff{...};class Video { Video(int width, int height, bool fullscreen) { setup(width,height,fullscreen); }};int main(){ INIStuff stuff("config.ini"); Video video(stuff.get("graphics.width"), stuff.get("graphics.height"), stuff.get("graphics.fullscreen"));}Everytime you hear something screaming Singleton, don't listen.
[Edited by - rip-off on January 9, 2008 8:29:52 AM]
Quote:Original post by stonemetal
I have a class that loads and stores ini values. It is the only place ini values are loaded, and as such just about any module in the program could use it. To me it just screams singleton. What other ways are there to design this?
1: Will it always be the only place configuration settings are read from? What if, later on, you want to be able to pull them in from multiple sources (want to have access to the default settings as well as the ini ones as well as... something else? Maybe I just want to create a couple of different config classes to contain settings for different parts of the game? Maybe I decide to have all the renderer options in a separate instance from the game controls?
Is there any harm done by making it possible to have multiple instances of this class? Will the world come crashing down if you don't make it strictly impossible to create multiple config classes?
I doubt it. What you're saying is "for now, I only need one instance". But singletons are only relevant when "it'll be a disaster if more than one instance is ever created". They are not the same statements.
2: Does every bit of your program need to access every single config value? To me, that screams bad design. Why does your collision detection need to know the current sound volume setting? Why does the enemy AI need to know the screen resolution? Why does the renderer have to have access to the game difficulty?
Most likely, you have a few places in your code which need to be able to access a few config settings.
Author
Ok, so it boils down to parse it once then hand out the info at creation time, or split it into section specific inis and parse them locally.
Quote:Original post by stonemetal
Ok, so it boils down to parse it once then hand out the info at creation time, or split it into section specific inis and parse them locally.
There are a lot of cases where you want to reuse a section of code without reusing its original configuration system. By keeping the configuration system seperate from the logic, you maintain good architecture and enable future code reuse.
But, there's no better way to learn than to learn from your own mistakes! Go ahead and try it and see what happens! Just reallize, you may not see any problems until much further down the road.
Quote:Original post by capn_midnight
But, there's no better way to learn than to learn from your own mistakes! Go ahead and try it and see what happens! Just reallize, you may not see any problems until much further down the road.
Usually I agree that learning from mistakes is extremely effective, but with singletons you might only see the problem much later, and then it will be very hard to go back. So singletons are one place where I would recommend to avoid them even if you don't fully understand why (after reading this (the two paragraphs between the last two quote boxes), that's exactly what I'm doing).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
