When should you use public static methods

Question

There are a lot of people out there against the use of "public/private" static methods. I have search around,with no luck, and tried to find anyone that advocates good use of static methods.

Assuming the methods will always be Cohesive where are the acceptable areas to use public static methods? Do these methods vary between Java and .NET (aka is it more acceptable in one then the other)?

This recent SO post spurred my anger/interest in this topic.

Answer 1

Use public static methods if the method can be considered a unit, and can be effectively tested on its own. It's plain hard to implement dependency injection or mocks on types that use static method.

I use static methods for utility methods with few/no dependencies, and well defined input/output.

Answer 2

I would say it is fair to use them in simple factory like scenarios where the type that holds the static method is returned. It isn't a huge leap to say that if:

string.Empty;

is a legitimate static property then:

string.GenerateRandomString();

is a legitimate static method. However even then I can see that a pure OO programmer may prefer a StringFactory or RandomStringGenerator class, but I guess it all depends on where you draw the line.

Answer 3

Marking a method as static tells consumers that you won't change the state of any objects passed into the method. A static method should perform an operation on the parameters it is passed and shouldn't have a reliance on any internal fields.

I believe the specific advice given in the post you reference is to do with where the static method was located - rather than advice against using a static method.

Answer 4

one typical use is to implement Singleton pattern.

Answer 5

I use Static/Shared for methods that are not part of the instance of the class, or if I am updating "shared" variables (remember to make them thread safe).

Usually, this means I end up having these methods in a different "Manager" class that contains them, I mark the constructor as private as well to make sure they can't be implemented.

On a side note: static/shared methods are slightly faster and I remember something about their implementementation in the CLR being non-OOP related and not allowed in interfaces which has something to do with a design flaw in OOP languages (.NET at least) inherent from Java - Discussed Here.

Answer 6

A static method generally shouldn't:

• Access any state outside its parameters (because that results in hard-to-change coupling)
• Modify its parameters (because if it does, why isn't it an instance method of that parameter?)

Conversely, pure functions (i.e. no side effects) make for good static methods.

Of course, this should not be taken as absolute dogma.

Answer 7

A static method has the same semantics as an instance method on a global object instance. Unless you are cool with a global object instance, you shouldn't want to use a static method. That said, it depends a lot on the situation. Some times, a nasty hack is the right thing to do.