why alwalys use getSingleton()

[uchickenbutt]

what does getSingleton() mean?

[xavier]

http://www.ogre3d.org/wiki/index.php/Singleton

[Kristian]

Disclaimer: Following is a joke:

Singleton Classes rock. Simply think of it as a way of ensuring that the class you are calling is created only once. That means it can be called from anywhere ( by including header of course ) and you know that your calling the 1 static instance and not creating another instance. I use them mostly for my main application and then for every single "manager" class that I use. Here is an example of a Menu manager

Ehm in fact, Singleton(/Simpletons) is mostly just an excuse for doing none object oriented programming in c++ while clapping yourself on the shoulders claiming to have a great o-o design ;)
Also, all theese words also continiously helps impressing bosses (most importat), finacial partners, clients and coworkers which is nice, for keeping our jobs :)


[/quote]

[:wumpus:]

It saves having to pass around a zillion pointers to all kinds of manager classes, or to have a single "god" class with these pointers which needs to be extended every time a new type of manager comes along..
Singletons certainly have their place, althogh it's easy to abuse them. But IMO Ogre uses them well.

[Imperil]

Kristian you have to realize that singletons are not *always* bad (even though they were almost written off as an anti-pattern by the consortium), it depends on how they are used.

Factory classes are a prime example of where the singleton pattern shines.

Although when using classes that are singletons I would definately use a const ref rather than calling getSingleton() over and over (obviously I'm only talking about while in the scope).

[Kristian]

Kristian you have to realize that singletons are not *always* bad (even though they were almost written off as an anti-pattern by the consortium), it depends on how they are used.

As the disclaimer stated the statement i did was meant as a programmers joke :) Off course you're right about that.

Factory classes are a prime example of where the singleton pattern shines.

Last time I checked with my gang of four "factory design pattern" was not on the same page as singleton design pattern ;)

Although when using classes that are singletons I would definately use a const ref rather than calling getSingleton() over and over (obviously I'm only talking about while in the scope).

Isnt the optimizer taking care of that ? Check out the genereate asm it should just push the pointer into the ean and then jump to the the function address. since the method is static i think its the same as pushing a const. Im not totally sure about this though.

[Imperil]

Last time I checked with my gang of four "factory design pattern" was not on the same page as singleton design pattern

I'm not sure what you are talking about? As a factory is one of the only valid uses of a Singleton (other than fixing broken design). So I was a little thrown off by your whole same page thing, maybe you could clear that up for me?

Isnt the optimizer taking care of that ? Check out the genereate asm it should just push the pointer into the ean and then jump to the the function address. since the method is static i think its the same as pushing a const. Im not totally sure about this though.

Not all compilers are the same an optimization is not standard, especially when using specific compilers for various console platforms.

Also I am not sure about your 'joke' as it really is bang on in the majority of cases. The Singleton 'pattern' was almost written off as an 'anti-pattern' due to the horrible misuse that has happened. There are very few situtations where using one is actual good design and not a hack for bad design.

[Kristian]

The gang of four also best knows as GOF is a group of 4 people who wrote a book with descriptions of the most common design patterns including singleton(/ simpletons) and factory<->product pattern.
In this book the factory pattern and singleton pattern are not related.

In other words factories have nothing to do with singletons, since they're 2 diffirent design patterns. A solution to a random problem on the other hand can happily fit into both patterns.

A RL example from a software solution... In a large scale distributed enviroment you can have a set factories factorising the same product (objects). Theese can reside on diffirent servers and you can then apply formulars to let them compeet in producing the cheapest product based on bandwith and compution powers for example.

A RL example of a singleton patterns ( which has nothing to do with programming )
In a socity there can be only one government it doenst make sence talking about a society with several governments becourse then it would be 2 individual societies... so if one are to model a software solution of tbe "society domain" the government class would be a singleton.

[pkdawson]

I have to agree with Imperil: the factory pattern is one of the few good uses of a singleton. In UML parlance (or English), a factory is a singleton. Is there a reason you'd want more than one instance of a factory? Rarely.

[Imperil]

The gang of four also best knows as GOF is a group of 4 people who wrote a book with descriptions of the most common design patterns including singleton(/ simpletons) and factory<->product pattern.
In this book the factory pattern and singleton pattern are not related.

Ok first off I obviously know what the GoF book is, and secondly if you miss how a singleton and factory pattern are related than you didn't understand the book at all. The whole point is to give a number of common building blocks to combine and build solutions to problems... and not to copy or clone but to work them as a solution to what you are facing.

In other words factories have nothing to do with singletons, since they're 2 diffirent design patterns. A solution to a random problem on the other hand can happily fit into both patterns.

In other words if you don't see how a factory and singleton can be related than again you might have 'read' the book but you don't understand it. If you go back and read what I said it states that:

"Factory classes are a prime example of where the singleton pattern shines."

And if you can't comprehend that I advise you to go back and read the GoF book again. I clearly stated that using making your factory a singleton is a valid use and that's it. The whole GoF book seperates various patterns in order to give the reader some building blocks and to think about the problem at hand.

In this book the factory pattern and singleton pattern are not related.

This statement shows that you do not understand the GoF book and should go back and study it further. The patterns are concepts to be applied and not just blocks of code to copy. Just because there are two patterns on different pages you can't grasp how they are related to each other? You obviously missed where the book clearly states that the factory pattern can be implemented as a singleton (in the singleton chapter) or where it states that a factory is often a singleton (in the factory chapter) lol.

Now regarding your examples I don't know why you even state those things... maybe you are confused? The patterns in GoF are small building blocks to be used to solve larger problems. All I stated is that one of the only actual 'good' uses of the singleton pattern is with factory classes. I'm not sure if you realize but those patterns aren't meant to be copied directly out of the book as solutions, but are there to help you solve problems by combining various aspects.

Singleton and Factory go hand in hand, as in the vast majority of cases you want to be able to build classes from a factory from anywhere in the application, and you only want a single factory to exist. That is why it is a valid use of a singleton. As pkdawson already stated a factory IS a singleton in the vast majority of cases, as there is no reason to have more than one instance.

[chuck_starchaser]

I agree about factory, too. Definitely a singleton.

What seems to have escape this thread is a feature of singletons that a static instance cannot equal: Guarantee of initialization.

Suppose you have 3 classes: Widget, WidgetFactory and WidgetSalespeople.
WidgetSalespeople would go to the WidgetFactory to buy Widgets to re-sell.
Now, suppose that somewhere in the program you have a static WidgetSalesman; --whether declared at file scope, as a static data member of a class, or as a static variable in a function.
This WidgetSalesman will get created at static initialization time; before main() is entered.
If your WidgetFactory were just a static instance, you have no way to know whether your static WidgetSalesman is created before or after your static WidgetFactory.
Your static WidgetSalesman might wake up into existance, go to the WidgetFactory, and find a construction sign, instead.

With a singleton, that problem is solved. Even at static time, when your static salesperson calls WidgetFactory::instance(), the factory is created.

[Kristian]

Imperial: If you look closely at the last post There is no quotes from you or referances to you. The gof explanation is not minded directly towards you. I get the impression of your last post that you think the post was directly minded towards you.
Im sorry if I failed to explain things in a way which you can understand. I'm not saying a problem cant fit into both singleton pattern and factory pattern im just saying that a factory doesnt have to be a singleton and a singleton doesnt have to be a factory.
If you read my analyzation of the society vs singleton closely you must have understood that I as a person is quite aware of the abstraction that theese patterns are no just bits of code.
As you say singleton and factories go hand in hand. You but not as a rule, sometimes you want factories to compeat with eachother for instance when you factories resides in a large scale distributed system.

[chuck_starchaser]

Just thought I'd comment about the gof argument: in their book "Design Patterns", they avoid mixing patterns. Each chapter is about one pattern, and one pattern only. They intentionally avoid confusion, that way. But at the end of each chapter they make suggestions for how the pattern could be combined with other patterns.

I bought the book twice, loaned it twice, and never saw it again twice, so I don't have it with me to say for sure; but I'd be surprised if they don't mention the possibility of making Factory a singleton.

[Kristian]

chuck_starchaser: off course it's possible having this sort of thing :) just as well as old mother russia had a single factory producing shoes as on the opposite, the USA having a whole lot of factories supported by supply and demand. ( metaphorical speaking ).
Essensionally a factory is beeing defined by its relationship with the product which it factorises.

[Imperil]

But at the end of each chapter they make suggestions for how the pattern could be combined with other patterns.

They do. They explicitly say in both chapters that the patterns are well-suited for each other.