Thoughts and Best Practices on Static Classes and Members

Question

I am very curious as to thoughts and industry best practices regarding static members, or entire static classes. Are there any downsides to this, or does it participate in any anti-patterns?

I see these entities as "utility classes/members", in the sense that they don't require or demand instantiating the class in order to provide the functionality.

What are the general thoughts and industry best practices on this?

See the below example classes and members to illustrate what I am referencing.

// non-static class with static members
//
public class Class1
{
    // ... other non-static members ...

    public static string GetSomeString()
    {
        // do something
    }
}

// static class
//
public static class Class2
{
    // ... other static members ...

    public static string GetSomeString()
    {
        // do something
    }
}

Thank you in advance!

Answer 1

In general, avoid statics - especially any sort of static state.

Why?

1. Statics cause trouble with concurrency. Since there is only one instance, it is naturally shared amongst concurrent execution. Those shared resources are the bane of concurrent programming, and often do not need to be shared.

2. Statics cause trouble with unit testing. Any unit testing framework worth it's salt runs tests concurrently. Then you run into #1. Worse yet, you complicate your tests with all of the setup/teardown stuff, and the hackery you'll fall into to try and "share" setup code.

There are a plenty of small things too. Statics tend to be inflexible. You can't interface them, you can't override them, you can't control the timing of their construction, you can't use them well in generics. You can't really version them.

There are certainly uses of statics: constant values work great. Pure methods that don't fit in a single class can work great here.

But in general, avoid them.

Answer 2

If the function is "pure" I see no problems. A pure function operates only in the input parameters, and provide a result based on that. It does not depend on any global state or external context.

If I look at your own code example:

public class Class1
{
    public static string GetSomeString()
    {
        // do something
    }
}

This function does not take any parameters. Thus, it is probably not pure (the only pure implementation of this function would be to return a constant). I assume that this example is not representative of your actual problem, I am merely pointing out that this is probably not a pure function.

Lets take a different example:

public static bool IsOdd(int number) { return (number % 2) == 1; }

There is nothing wrong with this function being static. We could even make this into an extension function, allowing client code to become even more readable. Extension functions are basically just a special kind of static functions.

Telastyn correctly mentions concurrency as a potential problem with static members. However, since this function does not use shared state, there are no concurrency problems here. A thousand threads can call this function simultaneously without any concurrency issues.

In the .NET framework, extension methods have existed for quite some time. LINQ contains a lot of extension functions (e.g. Enumerable.Where(), Enumerable.First(), Enumerable.Single(), etc.). We don't see these as bad, do we?

Unit testing can often benefit when the code uses replaceable abstractions, allowing the unit test to replace system code with a test double. Static functions prohibit this flexibility, but this is mostly important at architectural layer boundaries, where we want to replace, for example, an actual data access layer with a fake data access layer.

However, when writing a test for an object that behaves differently, depending on whether some number is odd or even, we don't really need to be able to replace the IsOdd() function with an alternative implementation. Likewise, I don't see when we need to provide a different Enumerable.Where() implementation for the purpose of testing.

So let's examine the readability of client code for this function:

Option a (with the function declared as an extension method):

public void Execute(int number) {
    if (number.IsOdd())
        // Do something
}

Option b:

public void Execute(int number) {
    var helper = new NumberHelper();
    if (helper.IsOdd(number))
        // Do something
}

The static (extension) function makes the first piece of code much more readable, and readability matters a lot, so use static functions where appropriate.