Design decisions.. static methods and singletons, good or bad?

wyrd

wyrd

Well-known member
Joined
Aug 23, 2002
Messages
1,408
Location
California
Are there design "rules" on when to use and when not to use static methods? (Im talking about C# static methods just to clarify).

Also what about singletons? To me they seem no different then global variables and probably should be avoided like the plague, but sometimes I cant help but think that they should be used in some situations.

Anyone have thoughts on this subject?
 
Nothing is wrong with static methods. If you are making helper classes or whatever, its best to be able to do this:
C#: 
gs = ColorHelper.ToGrayScale(Color.Blue);
rather than having to do this:
C#: 
ColorHelper ch = new ColorHelper();
gs = ch.ToGrayScale(Color.Blue);
So youd make ToGrayScale static. Another good spot for static methods is in non-creatable classes and structures... for example, you cant create a new Graphics object, but you can use the shared methods of it to get one.
C#: 
Graphics g = Graphics.FromHdc();

I cant think of any time youd use a singleton (that is a class in which only one instance can ever be used) over a static class.
 
One area which springs to mind and there are loads which use Singletons is the game loop in games programming. I often write the game loop within a class and obviously you dont want two of them running.
 
Hm. What about this situation;

I have a class (GameManager) which keeps track of game object interaction. Im only going to have one game running, so it would be easier to just make it a static class that way I dont have to pass a GameManager object to each and every object that I create. Certainly it would be easier, but the easy way is not always the best way.

If I took this same philosophy, it could also be applied to my Map class. After all, only one map is going to be loaded at a time. Okay, maybe Im reaching with this example. :P

For some reason this is screaming "stay away!" yet at the same time it just seems to make some odd amounts of sense.

To give an idea, this is a quick run down of what my GameManager would look like if everything in it was made public static;

C#: 
GameManager.StaticObjects   // ArrayList
GameManager.MovingObjects   // ArrayList
GameManager.Effects         // ArrayList

GameManager.Update()        // Updates Everything
GameManager.Draw()          // Draws Lists & Map

GameManager.Ticks           // Property
GameManager.Map             // Property

Every single object in my game has to reference a GameManager object for several reasons .. 1) It needs to know what map to use for movement, 2) It needs to know where to add game objects (ie; a missile explodes, the missile needs to know where to place its explosion effect), 3) It needs to know about all other objects in the game for collision detection (or AI for computer controlled players), 4) It needs the current tick count to control how its updated (Calling Environment.TickCount tons and tons of times per a single loop is out of the question, calling it once per loop and putting the value in GameManager.Ticks is needed)

Then of course, theres always making it a singleton rather then a purely static class. :/

One area which springs to mind and there are loads which use Singletons is the game loop in games programming.
Click to expand...

:confused: That sentence doesnt make sense. :(
 
Interchangeable data providers are often interfaced through a singleton implementation. This is one of the more common examples.
 
Back
Top