Sign in to follow this  

singleton design issue

This topic is 3625 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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?
Why 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.

Singletons are the root of all evil, as I've recently been finding out [sad]

Share this post


Link to post
Share on other sites
Instead of:

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

This topic is 3625 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this