I have no idea what I am talking about, but I hear more people saying no to Singletons than yes, so whatever.

Quote:Original post by jyk
In fact, you've sort of fallen into the classic singleton trap with your entity manager example. Remember, a singleton is an appropriate solution when the following holds true:

1. It is an error for there to be more than one of the specified object type in existence at any one time.

2. Global access is a requirement.

Actually, #1 needs to go even further than that, IMO. Sloppy and lazy engineering of other code often leads to the first condition being satisfied -- In other words, poor engineering and coding practices in the overall system comes to rely on there only being one instance in existence. In my mind, what this condition should really state, is that some condition beyond the programmer's control to engineer away requires a single instance exist in such a way that more than one instance is an error.


I've been in the position of migrating manager classes from a singleton design (based on Scott Balias' Game Programming Gems I article) to a non-singleton design -- The cost was less than a dozen changed lines, some slight re-structuring [an entire (now unnecessary) class went away] and a single new parameter passed to each managed objects constructor -- which can be, of course, hidden neatly behind a factory :) My experience with Singletons is that the "ease of use" argument is a near-total fallacy, and simply an excuse made up by lazy typists who fancy themselves programmers.