The static modifier, much like the access modifiers, is one of the first keywords that new developers learn and, much like the public access modifier, static is often misused by new developers because it provides a seemingly easy shortcut around learning how to write proper Object Oriented code.
Excessive use of the static modifier can lead to messy, overly complex code. On the other hand, careful use of the static modifier can lead to functionality that is elegant, scalable and performs well. The aim of this article is to help new developers strike the right balance. First I'll describe when to use static, then I'll explain why.
When?
Ideally, static should only be used for private or protected members when you need to share a single value between all instances of the class to which those members belong. You should avoid using public static wherever possible.
There are a couple of occasions where a public static is required, however.
Providing Common Values for structs
If you've ever used string.Empty or int.MinValue then you've invoked a public static property. Here's an example of using the same technique in a Point struct.
public struct Point
{
public int X;
public int Y;
// Static property that returns an instance of point
public static Point Zero
{
return new Point { X = 0, Y = 0 };
}
}
// This...
var point = Point.Zero;
// ...is cleaner and more descriptive than writing this...
var point = new Point { X = 0, Y = 0 };
// ...every time we want a zero value point
Extension Methods
Extension methods are a way to add new functionality to classes that you don't have access to the code for. The design pattern for extension methods requires that you use the static modifier on a public method.
public static class StringExtensions
{
public static string Left(this string str, int count)
{
return str.Length <= count
? str
: str.SubString(0, count);
}
}
// We use the extension method just like any normal method
var example = "Hello world".Left(5);
Why?
Over-use of the static modifier is an anti-pattern because it increases and actually encourages class coupling. Code that features classes that reference each other excessively is often referred to as spaghetti code because of how difficult it is to untangle and understand.
When all of your classes know about each other in this way they become less reusable and they also become harder to maintain. After all, it's much easier for you as a programmer to understand and reuse a class that only knows about itself than it is to understand one that accesses eight or nine other classes, each of which accesses another eight, and so on.
Further Reading
I encourage you to read up on all of the below topics as even a loose understanding in the back of your mind will have you start asking the right questions when writing code.
SOLID, Class Coupling, Cohesion, Interfaces, Factory Pattern, Dependency Injection
Understanding programming theory really is just as important as understanding syntax. If you have any questions at all about these subjects, feel free to drop me an e-mail or ask straight in the comments.
