The actual construction is in a derived class.
Nonetheless, I might want to figure out something else in the future, I will think at this.
Getting the rid of managers
When I read the title of this thread a jolt of enthusiastic excitement went through me ... until I realized that you're talking about a programming issue.
Singletons are to be used for a case where there can only be one instance of the class without causing erroneous or incorrect behaviour. It's not a catch-em-all insurance policy against having > 1 instances. Sure, it can be used that way, if you really want -- just like globals can be used for things that aren't truly needed globally.
It's just not a terrific idea to do so. Especially when it comes down to: "I think there should never be need for two instances of this."
Exactly, and if the implementation of a class relies on side-effects or some kind of global state which makes it not safe to instantiate more than once, why not make it a singleton? Then you're at least honest with your limitations. Note: I'm not saying you should make such a class.
[font=arial, verdana, tahoma, sans-serif][size=2]
The object is instantiated using a global systemwide lock so no chance of double instantiation can happen.
So this means that for all intents and purposes, it is a singleton, but enforced externally? I might even argue that is worse.[/font]
Singletons are crappy, but sometimes they are needed, and sometimes they minimize incorrect usage of a class. Substituting a singleton with something else that enforces oneness just ignores the underlying issue.
[quote name='Krohm' timestamp='1319395719' post='4876028']The object is instantiated using a global systemwide lock so no chance of double instantiation can happen.So this means that for all intents and purposes, it is a singleton, but enforced externally? I might even argue that is worse.Singletons are crappy, but sometimes they are needed, and sometimes they minimize incorrect usage of a class. Substituting a singleton with something else that enforces oneness just ignores the underlying issue.[/quote]
Not at all.
There are many system-wide unique resources. There are global mutexes and semaphores. There are individually named files on the file system. There is volatile information about larger systems such as machine state.
Locally constrained uniqueness is often enough for small programs that need it, but they are not everything. At the smallest end of the scale you have interlocked memory and IPC communication methods. Externally contstrained uniqueness is absolutely critically on larger systems that span networks, such as resources controlled by remote databases.
Just consider the classic problems of simultaneous updates, such as the computer science problem with two travel agents booking reservations simultaneously, have need of strong external uniqueness constraints.
There are very solid, established, and proven uses for such things. Enforcing uniqueness locally and globally is an extremely important design requirement for many programming problems.
The problem is not simply using it; there are many times when it is not just a good design but instead absolutely essential to proper function. The problem comes from using it unnecessarily.
The real questions to ask are:
(1) Does the problem require enforced uniqueness?
(2) If it is required, does the proposed solution adequately enforce it?
Very few problems require it.
Most of the time it is a non-issue. Don't write code that depends on uniqueness. Data driven designs, component based systems, and thinking with reuse in mind solve this in most cases.
But if it is needed, it is absolutely essential. For every problem you need to discover the necessary scope.
For example, your enforcement may be a single block of shared memory. It may be a single instance of a class within a single app. It may be a single instance of a service on a single OS instance. It may be a single item on a physical machine regardless of virtualization. It may be a mandatory pessimistic lock on a database record that needs to propagate across a server cluster.
Don't use it when it isn't required. But if a system does require it you better know the available tools so you choose the right one for the job.
[quote name='YogurtEmperor' timestamp='1319277790' post='4875301']
[font="arial, verdana, tahoma, sans-serif"]So let’s assume singletons are not welcome, and you are wondering what you can do to make sure that no more than 1 instance of a class exists.[/font][font="arial, verdana, tahoma, sans-serif"] [/font]
If you want to make sure that no more than 1 instance of a class exists, why not use a singleton? That's what they're meant for, after all. If singletons are "not welcome", but it's OK having classes that can only function properly when there's max one instance, then that's just hypocrisy.[/quote]
I am a little late but-
No, I want CGame be instantiated only once, not to be instantiated only once and be global in scope.
My engine will pass the game pointer to the 3 main objects that need it: Scene Manager, State Manager, and States themselves.
Access to the CGame class is restricted to these objects because these 3 objects are the highest-level objects under the CGame class, and they are the only ones that could possibly need to know about all the different systems running in the game (all of which can be accessed through CGame).
There is a design problem with using a singleton, but also one less subjective. If my engine relied on a singleton for the main game class, how would the users of my engine inherit from my CGame and make an instance of their own "CMyGame"?
If the user wants to make a singleton out of his or her own CMyGame, or just make an instance on the stack (preferred), that is his or her business. My engine makes no assumptions as to how the game class is stored; when something needs it it is passed as a parameter.
And the design issue is: How do you control which classes/modules have access to the CGame pointer?
So, you made this nifty system that uses singletons for the CGame. From the CGame you can access all other managers.
Now you have a small bit that just wants a sound manager. Well now he has to include the CGame file, and with that he must now link to the graphics library, the physics library, scene manager, etc.
Trying to avoid this by using a bunch of different singletons does not really improve your design. You still haven't restricted access from things that should not have access, so when your programmers get lazy they will just #include "SoundManSingleton.h" instead of just the components of the sound module they need. Inevitably, singletons lead to unnecessary relationships between classes.
I will take a system of constraint any day. I want to think logically about what every system needs and manually give it (and only it) to them. That is organization.
L. Spiro
Exactly, and if the implementation of a class relies on side-effects or some kind of global state which makes it not safe to instantiate more than once, why not make it a singleton? Then you're at least honest with your limitations. Note: I'm not saying you should make such a class.
The singleton design pattern implies more than just that there be only one instance of the object.
http://blogs.msdn.co.../25/140827.aspx
Also to be noted, it should be the decision of the program, not the class to limit the creation of itself. If you want to limit the creation of certain objects you should make a factory class to handle that, not a singleton.
Also, I seriously question a single class that is not safe to instantiate more than once for anything important. It feels like a bit of a code smell. I could see it being useful in some cases, but if it is something that's coming up repeatedly I would be wary of it. See frob's first post for examples.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
