Don’t Make the Recipe Static

Today it was time to talk about static class members in the first year programming course. I always have problems with static. If you are not careful you start thinking that static means “doesn’t change much”. This is reasonable in real life, but not in C# programming. In C# programming static means “always present, part of a class and not of an instance”. At this point I thought an example would serve well, so we started talking about contexts where static would make sense.

Consider that you are implementing a system for a fast food store. You have a class called “Dish” and the system stores an instance of Dish for each of the items in the menu. A Dish instance holds the list of ingredients for the dish, the sale price, and the name of the dish. For example, there might be a dish called “Chicken and Chips” which held two ingredients (chicken and chips) and a price value (perhaps four pounds 50 pence). I asked everyone for some suggestions for static class members for the Dish class. Someone suggested that recipe would be a good candidate for a static member.

Not so. The idea of a static member is one that exists as part of the class. Which means that recipe could only be static if every dish was cooked in the same way (i.e. the recipe exists once for the entire class). Each dish needs its own recipe, so this must be a non-static member of the Dish class. However some things, for example the maximum and minimum price of dishes, the maximum number of ingredients that a dish can have all make sense as static members of the Dish class.

Simon has a sign on his office wall, “Consider the context”. When trying to work out what makes sense as static and what doesn’t, this is very good advice. And a good starting point is that “a recipe should not be static”.

Comments

[Lindsay]

I find static can sometimes make for more understandable code in some cases and sometimes is actually better

[Jules]

I am a lazy prrogrammer, and make my List of Game Objects Static Lists in the main Game calss, so that these can be seen by all other and between Game objects and classes.

But need lessons on Reference types. I could not work out why my games Manoeuvre Scheduler was being 'corrupted'. It was set up as a static List of Manouvres, to schedule Aircraft Movements on Game creation. Every couple of seconds my Aircraft class for Manoeuvres, at current time, and if so then copies into its own Local Manoeuvre object for processsing, and updates.

I noticed that after the first cycle through of my Game manoeuvre sequence, that my Manoeuvres list was being 'corrupted'. 6 frustrating hours later, I eventually worked out that in fact that 'copy' burried down in my Aircraft class was really making the same reference the main Game Manouvre lists, so when I was manipulating my local variable, deep withion my class I was actually manipulating the main Game static List . Such is the lack of awareness in Lists being Reference by types, and the care associated with any presumed copying, as you will probably actually end up inadvertently changing the original data as well.