The static
keyword can be a little hard for newbies to grasp. Its primary purpose is to identify a class member as not belonging to any single instance of the class, but instead to the class itself.
Without going into too much detail, C# (and Java) rigidly enforce the object-oriented ideal that all code and data must belong to an object, and therefore is limited in scope, visibility and lifetime. That's generally best practice wherever the fundamental tenet of an object representing some real-world thing applies. However, it doesn't always; sometimes what you need is a function or variable that you can get to from anywhere in code, without requiring you to pass around a reference to an object containing it, and with the guarantee that the data you are looking at or changing is exactly what everyone else is dealing with, and not a copy of it belonging to a different instance of an object.
Such behavior was available in C and C++ in the form of the "global" function or variable, which was not encapsulated in an object. So, as a compromise, C# and Java support "static scope", a halfway point between truly global code with no parent object and limited-scope instance members.
Any "code member" (function, property, field) declared as static
comes into scope as of the first line of the program's main()
function, and does not leave it until the main()
function terminates. In plain English, a static member exists and can be used as long as the program is running. In addition, static members are invoked by calling them as members of the type itself, not members of any one instance of that type:
public class Foo
{
public int MyInt {get;set;} //this is an "instance member"
public static int MyStaticInt {get;set;} //this is a "static member"
}
...
var myFoo = new Foo();
myFoo.MyInt = 5; //valid
myFoo.MyStaticInt = 5; //invalid; MyStaticInt doesn't belong to any one Foo
Foo.MyInt = 5; //invalid; MyInt only has meaning in the context of an instance
Foo.MyStaticInt = 2; //valid
This makes static members visible to any code that has knowledge of the type, whether or not they know about any single instance of it.
To answer your question, the primary benefit of marking something as static is that it becomes visible wherever the type itself is known, regardless of whether the consuming code has or can get an instance of the containing object. There's also a slight performance benefit; because the method is in static scope, it can only access other static members (of the same class or others), and whatever is passed in as a parameter. Therefore, the runtime does not have to resolve any reference to the current instance of the containing object, as it normally would have to for an instance method in order to provide context-specific state information.
Entire classes can also be marked static; by doing so, you tell the compiler that the class declaration will consist solely of static members, and thus cannot be instantiated. This is an easy way to ensure there is one, and only one, copy of an object in memory; make the class and everything in it static. However, it's very rare that this is the best solution to such a need. In a situation where exactly one copy of a set of data is required, the "singleton" is typically advocated instead; this is a non-static class, which uses a static accessor and a non-public constructor to provide access to a single instance of itself. Theoretically, a singleton provides much the same benefits of a fully static class, but with the added ability to use the class in an instance-based, object-oriented way.