Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

zealouselixir

Singleton versus Monostate Pattern

This topic is 5336 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''ve found myself using Monostates much more commonly recently, rather than the apparently more popular Singleton pattern. I''ve used Singletons in the past and found them to be overly elaborate for what they achieve. Off the bat, I''d like to say that I think single-instance classes are overused in modern game programming (at least at the amatuer level). I can imagine only a handful of subsystems that might truly need to utilize one such pattern, including: a global debugging system, resource management (spec. precaching), and message passing between subsystems. My question is this (and I''m assuming that you''re familiar with both patterns to a conversant degree; if not, please refrain from response): Are monostates not (1) more elegant, (2) less complex, (3) more efficient, and (4) less error-prone, in the same contexts as one might use a Singleton? I ask because, as I said, Singletons have been promoted wildly by the likes of Meyers, the GOF, and even Alandrescu (sp?), while virtually no emphasis has been placed on Monostates. I find them to be pretty functional in most circumstances, due to the fact that single-instance and single-state just seem to go hand-in-hand. Am I overlooking something? Discuss. Later, ZE. //email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
Advertisement
One of the worst things about monostate systems is that the user doesn't know that there is really only 1 underlying object, which could cause some nasty bugs. I, too, think singeltons are used way too much. They promote global access, which is just as bad as having global variables. IMO I think singeltons are better because they are about as explicit as you can get, and you can overcome the global access thing by just refering to it in your main function and passing it as a parameter to other functions that need it.
EDIT: Oops, I don't think I answered all your questions:
1) monostates, IMO, are more elegant than singeltons
2) they are much less complex to make, but to the user there isn't much of a difference.
3) singeltons are more efficient memory-wise, but they are both as efficient speed-wise.
4) I think singeltons are less error-prone, acually (which I already mentioned above)

-------
"Hey, what about those baggy pants you kids are wearin' these days? Aren't they hip and cool and poppin' fresh?"-Peter Griffin
"Everytime I see an M followed by a dollar sign I just say "oh god" and go to the next post."-Neurokaotix
the D programming language

[edited by - brassfish89 on November 29, 2003 2:51:49 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What is complex about making a singleton?


class singleton
{
public:
static singleton& instance()
{
static singleton eg;
return eg;
}
private:
singleton(){};
singleton(const singleton&){};
singleton& operator=(const singleton&){};
};


Typing time approx 30 seconds.. how is that complex?

Share this post


Link to post
Share on other sites
You misunderstand. Due to the fact that this is a comparison, there are grades of "complexity;" quite clearly, neither of these patterns is difficult to generate a sample case for. Having said that, would you not prefer this?

class monostate
{
public:
static bool service(...);

private:
static int data;
}

I mean, my gosh; you can even instantiate one of them and toss it all over the place without the need to monitor pointer validity or order of initialization (unless your monostate has some type of invariant, which it really oughtn''t). And every instantiation references the same data. It''s unified-state heaven!



Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you cant get more unified than only being allowed one state

Share this post


Link to post
Share on other sites
quote:
(3) more efficient

I disagree, a Meyers singleton gets created only if it is actually needed. A monostate will have to be initialized everytime (thus creating it).

In situations where space is tight thats one reason to prefer it, but we''re talking about very tiny differences here.

Share this post


Link to post
Share on other sites
quote:
Original post by ZealousElixir
Off the bat, I''d like to say that I think single-instance classes are overused in modern game programming (at least at the amatuer level). I can imagine only a handful of subsystems that might truly need to utilize one such pattern, including: a global debugging system, resource management (spec. precaching), and message passing between subsystems.

I''d potentially argue that those might also not be good candidates for Singleton status, depending on the context.
quote:

My question is this (and I''m assuming that you''re familiar with both patterns to a conversant degree; if not, please refrain from response): Are monostates not (1) more elegant, (2) less complex, (3) more efficient, and (4) less error-prone, in the same contexts as one might use a Singleton?

In general, I''d agree. The fundamental difference between Singleton and Monostate is that Singleton focuses on singularity of identity, which is often the wrong focus when you just want to ensure singularity of state. You''re not the first person to have raised these issues. For example, read about the Python Borg pattern.
quote:

I ask because, as I said, Singletons have been promoted wildly by the likes of Meyers, the GOF, and even Alandrescu (sp?), while virtually no emphasis has been placed on Monostates.

There''s a lot of mileage to be had from Singletons due to the complexity of getting them right.

quote:
Original post by Anonymous Poster
What is complex about making a singleton?

Let me guess. You''ve never actually used Singletons in non-trivial contexts, right?

Share this post


Link to post
Share on other sites
quote:
Original post by ZealousElixir
Having said that, would you not prefer this?

class monostate
{
public:
static bool service(...);

private:
static int data;
}

That's not Monostate! OK, it kind of is, but the omission of non-static member functions misses the essence of Monostate.

[edited by - SabreMan on December 1, 2003 9:09:53 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!