When to Use Static and Non-Static

If there's one thing I see, get asked many, many times especially by new developers working on .NET and that's the age old question of:

"How do I know when it's appropriate to use a static construct?"

Well, to be perfectly honest, in all the years I've been writing .NET code, I still ask myself the very same question. Not quite with the same frequency I used to, granted, but I do still ask myself, especially in the first incarnation of a bit of code.

So, does this mean that the question can't actually be answered? No, not at all; it just means that it's one of those things that you have to evaluate for every single project you do. As you gain experience, you'll learn to instinctively recognise certain patterns, patterns that will start to steer you towards good design in your code, and, like me, the frequency with which you ask yourself the question will start to diminish.

The underlying question however, well, that's a different thing entirely.

Why on Earth Is It Such a Hard Question to Answer?

In my mind, this stems from the fact that many developers don't really see, or understand, the differences between Static and Non-Static constructs. Myself, I originally did advanced-level C++ back in the 1990's and, for a C++ developer, understanding this concept was part of the mantra of being a C++ developer. In today's world, however, with nicely typed languages such as C#, the lines have become a little more blurred.

Many of the newer developers I speak to and read questions from seem to be of the persuasion that static means exactly that. It stays in one place, and as such, the run-time doesn't have to check where/how to call it, and so access is generally faster. Well, there is an element of truth in that, but it's also by no means the full story.

The Full Story...

The biggest underlying difference is that static classes are NOT instantiated. That is, you can use them without having to 'new them up'.

Now, to some, this might seem counter intuitive, especially if you've been trained in the more modern "text book" ways of object-orientated software development, where you're taught that all objects should be 'newed up' when needed and disposed of when finished with.

Let's just stop to think about this for a moment.

Without the ability to use static code, patterns like the Factory & Singleton patterns wouldn't be useable, or, at the very least, they would be so complicated that it would be easier to do things different ways. Without the ability to use static code, all your utilities would have to be re-created every time you wanted to use them, not at all fun from a memory perspective.

And, many other patterns and practices we employ today would be wholly impractical and difficult to follow.

So, Why Is It So Hard to Decide?

Because software development is hard, the .NET environment tries to hold your hand as much as it possibly can, and to a lesser extent you have an enormous amount of power and flexibility at your finger tips, but you, the developer, still have to make decisions that may or may not break your project. The key to making this task easy is not answering the questions like "Static versus Non-Static," but more about looking at what .NET has available to help you achieve your given task, and architecting your solution with a lot of thought and experimentation.

Don't be afraid to sit down and code both a static and a non-static version of a routine you have in mind, and then test both of them, in production if you have to. Find out which one works best.

Me, personally? Well, I find using static code works best when I have common abstractions that I intend to use in multiple places. In fact, if I have multiple code that's used across multiple projects in a solution, I'll even put that code into a purely static class library in a project all of its own, and then reference that where needed.

If I find that a given class needs some initialisation, however, for example a POCO that has a generic collections list in it, then making that non-static is sensible, because then you can create a constructor that initialises said list with an empty list. Doing this means that you know, in the future, every time you new up a copy of that object, you're going to have an empty list ready to add and remove things to/from.

Of course, this is not the absolute be all and end all of this, not by any stretch of the imagination.

A singleton, for example, combines both approaches. It provides a static, always-callable entry point, but in the background if it needs to be. It will new up a concrete instance of any object that it makes use of, and then return via the static interface the reference to that object.

To answer the question, experimentation is the key. Find out which works best for the project you're writing.

That's all for this week. We'll get back to something a bit more technical in the next post. Until then, keep on coding.

If you have any suggestions or ideas for posts you'd like to see, please feel free to reach out to me on Twitter as @shawty_ds, or come and hunt me down in the Lidnug Linked.NET users group on Linked-In that I help run. I'll be more than happy to produce posts on specific topics of interest.

Related Articles


  • The right questions is why should you use static ?

    Posted by Pitming on 10/01/2014 12:46pm

    Hello, Thx for you comment. But my experience of static is totally different. Except for the factory (wich could also be discussed), I always wonder why somebody should use static somewhere ? There are a lot of problem comming when you use static: Memory leak, multi threading synchronisation, hidding collaborators, unability to mock when testing. So at the question when should I need to use static, my answer would most of the time be: Never !

    • RE: the right question...

      Posted by Peter Shaw on 10/21/2014 06:23am

      The reason many people don't give a static class the credit it deserves is simply because of the way that Object Orientated development is taught in schools and colleges these days. Let me try and give you a real world analogy. If you where a water main engineer, and you had a leak in a pipe to deal with, your goal would be to stem the flow of water enough so that you could asses the break and develop a method to fix it. Now let's further imagine that the break was just inside a T-Junction off a main pipe, and 200 yards away from where you are, is your colleague standing right next to a tap that closes off all water going into the section of pipe you might want to work on. At this point you have a decision to make, do you: a) Shout (or Radio) your colleague and ask him to turn the tap off, thus stemming the water flow. or b) Go to the location where your colleague is, measure the tap, examine it's construction and workings, then return back to your own location, build and install a tap of exactly the same type, then use that to turn off the water just in front of the section where your working? This scenario is not too dissimilar to the static question. If you have a piece of discrete functionality, say for example a calculation utility, then having that as a static function is usually very desirable. As an example, look at the .NET Math library. Would you be happy instantiating a new Math object EVERY time you needed to calculate the 'Sin' of a number? Memory leaks in static constructs usually occur because developers using them don't pay attention to what their doing. They look at the static way of doing things and think, this is just a data getting utility, no need to new it up. Then they go ahead pull a load of data from a database, throw it into an in memory list, do some magic on it, then return it assuming the GC will just take care of everything as normal. This is the worst possible case for using a static construct. If your developing code, that will handle a large chunk of data and may need to manipulate it, then static is absolutely the wrong way to do it. If however your developing something like a facade, then static is an acceptable pattern to use, if all that's happening is the data is being passed through from a correctly managed non static construct behind the scenes. I can think of other scenarios too, but this comments already too long :-) Bottom line: Don't just look at the text book and follow it blindly, do a feasibility exercise if you have too, determine if something works better as a static or if it does not, a developers job is not to interpret rules blindly, it's to solve problems in the best way possible, and often that requires experimentation.

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date