A Simpler Way to Think About the “static” Keyword

I like to give beginners an easier way to think about the “static” keyword. They see it peppered around the code base and often don’t understand how it works in the various contexts- with a class, method, variable, event, etc. My description may be an oversimplification, but I think it gets new programmers in the game quicker. Anyway, here it is: think of the static keyword as turning object oriented programming OFF for whatever you apply that keyword to.

Recall that object oriented programming, or OOP for short, is the programming paradigm of C# and many other current languages where we model software after real life objects and interactions. The idea is you create blueprints (classes) for creating these objects, then you use these classes to create the software objects in your running program. These objects, which contain logic and data, then interact with each other in ways that we (hopefully) easily understand from our real life experiences. I’ll do a separate article on OOP, but the takeaway here is that OOP is about creating objects, which each have their own state. By state I mean that one “Employee” object for example may have an age of 25 while another has an age of 43. They have different salaries, social security numbers, etc. as well.

So “static” turns these features off. Static says that whatever it’s applied to doesn’t pertain to specific objects. So what’s left for it to pertain to? Think of it like just an independent piece of logic. This comes up more than you may think. Consider a method that converts a temperature in Fahrenheit, passed in as a parameter, to Celsius. Does this conversion need to built in to all objects with temperature data, as a class behavior? No. The conversion is self contained- it has the data it needs passed in and doesn’t need to know anything about objects. So you can implement the method as a static one:

Using a static method doesn’t involve instantiating objects (OOP)

Now if you didn’t intend to pass the temperature in as a parameter and rather meant for the method to access a temperature field of the class to make the conversion, then you wouldn’t use the “static” keyword. You are using object oriented programming in this case. The conversion method is now a behavior of the class, contained within it:

Using OOP and not a static conversion method

Can you see the difference? For the former approach the data was passed in and it was just a math calculation. For the latter, the method relies on specific object data that it has access to to get the conversion right for each object. The conversion is a behavior of Forecast objects.

I don’t like the latter approach here. There are many other scenarios where you may want to convert a temperature- for a patient at a clinic, for the setpoint of an oven, for a scientist experimenting with liquids, etc. I wouldn’t want to make conversion behaviors, which do the same thing, for every type of object that may work with temperatures. This would violate the DRY principle. With the static method I can use that for any conversion- it doesn’t have anything to do with objects. I can pass in objects’ temperature values as the parameter.

It should be clear then that if you mark a class as static, you cannot instantiate objects from it. It follows then that all data and methods in such a class need to be static as well. Again I think of these kinds of “classes” as logical units of code and not really classes at all. It’s unfortunate that the name “class” is used in this context. That’s why I tell beginners to think of it as turning off OOP, or sort of as canceling out the “class” keyword. To me “class” means blueprint for creating objects,

You may have noticed from my images above that the Main method (entry point) in programs is static too. You don’t have to create any object to invoke it. Static methods are usually accessed by the class name they reside in.

As usual, consult the docs for more information and don’t hesitate to reach out to me.