Are global static classes and methods bad?

It's generally agreed upon that rel开发者_运维技巧ying heavily on global stuff is to be avoided. Wouldn't using static classes and methods be the same thing?

Global data is bad. However many issues can be avoided by working with static methods.

I'm going to take the position of Rich Hickey on this one and explain it like this:

To build the most reliable systems in C# use static methods and classes, but not global data. For instance if you hand in a data object into a static method, and that static method does not access any static data, then you can be assured that given that input data the output of the function will always be the same. This is the position taken by Erlang, Lisp, Clojure, and every other Functional Programming language.

Using static methods can greatly simplify multi-threaded coding, since, if programmed correctly, only one thread will have access to a given set of data at a time. And that is really what it comes down to. Having global data is bad since it is a state that can be changed by who knows what thread, and any time. Static methods however allow for very clean code that can be tested in smaller increments.

I know this will be hotly debated, as it flies in the face of C#'s OOP thought process, but I have found that the more static methods I use, the cleaner and more reliable my code is.

This video explains it better than I can, but shows how immutable data, and static methods can produce some extremely thread-safe code.

Let me clarify a bit more some issues with Global Data. Constant (or read-only) global data isn't nearly as big of an issue as mutable (read/write) global data. Therefore if it makes sense to have a global cache of data, use global data! To some extent every application that uses a database will have that, since we could say that all a SQL Database is one massive global variable that holds data.

So making a blanket statement like I did above is probably a bit strong. Instead, let's say that having global data introduces many issues that can be avoid by having local data instead.

Some languages such as Erlang get around this issue by having the cache in a separate thread that handles all requests for that data. This way you know that all requests and modifications to that data will be atomic and the global cache will not be left in some unknown state.

static doesn't necessarely mean global. Classes and members can be static private, hence only applying to the specific class. That said, having too many public static members instead of using appropriate ways to pass data (method calls, callbacks, etc.) is generally bad design.

If you're trying to be purist about your OO development, then statics probably don't fit the mold.

However the real world is messier than theory, and statics are often a very useful way to solve some development problems. Use them when appropriate, and in moderation.

As an addition to whatever else is said, final static variables are just fine; constants are a good thing. The only exception to that is when/if you should just move them to a properties file, to be easier to change.

Mutable static variables are bad because they're just global state. The best discussion I know of about this is here, under the heading "Why Global Variables Should Be Avoided When Unnecessary".

Static methods have several drawbacks that often make them undesirable - the biggest one being that they cannot be used polymorphically.

First, why are the old global variables so bad? Because it is state that is accessible from anywhere, any time. Hard to track.

There are no such problems with static methods.

That leaves static fields (variables). If you declared a public static field in a class, that would truly be a global variable and it would be bad.

But make the static field private and most problems are solved. Or better, they are limited to the containing class and that makes them solvable.

public class Foo
{
    private static int counter = 0;

    public static int getCounterValue()
    {
         return counter;
    }
    //...
    public Foo()
    {
        //other tasks
        counter++;
    }
}

In the code above you can see that we count how many Foo objects were created. This can be useful in many cases.

The static keyword is not global, it's telling you that it's on class level, which can be very useful in various cases. So, in conclusion, class level things are static, object level things are not static.

Static methods are used to implement traits in Scala. In C#, extension methods (which are static) fulfill that role in part. That could be seen, as the DCI proponents state, as a "higher order form of polymorphism".

Also, static methods can be used to implement functions. This is what F# uses to implement modules. (And also VB.NET.) Functions are useful for (unsurprisingly) functional-programming. And sometimes they're just the way something should be modeled (like the "functions" in the Math class). Again, C# comes close here.

I think the bad thing about global variables is the idea of having global state - variables that can be manipulated anywhere and tend to cause unintended side effects in far-flung areas of a program.

Static data would be similar to global variables in that they introduce a kind of global state. Static methods though are not nearly as bad, assuming they are stateless.

Not entirely. Static actually determines when, where and how often something is instantiated, not who has access to it.