4
\$\begingroup\$

I need to build an object that will have only one instance because this Object is dedicated to the storage of vital settings for my application and I would like to avoid a misuse of this type or a conflict at run-time.

The most popular solution for this, according to the internet, is the Singleton pattern. But I would like to know about other ideas or solutions for this; also I would like to know if other solutions can be much more easy to grasp for an user of this hypothetical library.

Thanks.

Improve this question
\$\endgroup\$
3
  • 1
    \$\begingroup\$ There are many debates and conflicts started by the issue of using a singleton. If it is thread safe and templatized, it can still be simple and very powerful. If you do not plan to delegate the singleton with the management of objects and entities, then there aren't other alternatives that are code-wise more elegant for this purpose. What would you really like this singleton of yours to do in terms of performance and interface? Read a good tutorial on it (perhaps codeproject.com/Articles/4750/… ) and avoid leaks, locks and abuse. \$\endgroup\$
    – teodron
    Oct 9, 2012 at 13:56
  • \$\begingroup\$ Singleton gives you encapsulation but if you don't want/need that you can stick your stuff (like functions) in a namespace ... there are a lot of different ways to do it. BTW doesn't this belong to stackoverflow and not to gamedev? \$\endgroup\$
    – Valmond
    Oct 9, 2012 at 13:59
  • \$\begingroup\$ @Valmond i would like to have a game-dev prospective about this. I'm reading that article, i also like to know about solutions that can be easier to debug for the user. \$\endgroup\$
    – axis
    Oct 9, 2012 at 14:02

1 Answer 1

Reset to default
3
\$\begingroup\$

You generally will have some other globally unique object, like an Engie or Applicaion instance. Storing settings on that (in a member object for example) is totally viable.

It's in many ways the same as any other singleton, except now you have a single point of initialization and cleanup rather than tons of them for different singletons.

I've also seen fully component based engines where even the engine is composed of runtime components, and one or more configuration oriented components can be added there.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ ok, but what about real viable alternatives ? if someone will complain about debugging related problems, which the Singleton pattern can offer, what are the real alternatives ? What do you mean with "engine composed of runtime" ? Something like a "plugins" design ? \$\endgroup\$
    – axis
    Oct 10, 2012 at 7:07
  • \$\begingroup\$ @axis What should the debugging problems with a singleton be? They are exempt of the problems global variables have (you don't always know when they get initialized for example). Singletons make some programmers cringe, that's all:-) \$\endgroup\$
    – Valmond
    Oct 10, 2012 at 7:42
  • \$\begingroup\$ @axis: these are real viable alternatives. They're what every last single game engine I've ever used in the real world use for such objects. Don't get stuck in the rut if academia; just because some "old wisdom" says something is bad doesn't mean you need to find some (non-existent) perfect alternative. So far as the engine composition comment, I was referring to the component based design pattern. It's frequently brought up in the context of game object composition, but it can also be used for the main engine object, resource objects, etc. \$\endgroup\$
    – Sean Middleditch
    Oct 10, 2012 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .