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.

+4  A: 

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.

Why is it hard to use DI on types that use static methods? Agree if you are talking about mocking the class that has the static methods...
@Nix: Forgive me for departing a little from language agnostics. In .NET, static methods cannot be members of an interface. This reduces the options available when mocking the object, as .NET only supports single inheritance of classes, and the interface doesn't describe the whole class contract. Note that it's still the same story to use DI *within* static methods, it's just hard to use DI *with* static methods.
+2  A: 

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:


is a legitimate static property then:


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.

Martin Harris
I take issue to over design, and my fear is blately saying don't use static methods! will unnecessarily increase code complexity. In our field its all about understanding when "StringFactory" or "RandomStringGenerator" are needed.
@Nix: I agree. Static methods have their place. In my applications, they tend to be used in utility classes.

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.

The article that the post refers to, in my opinion, says don't use static methods... make them methods because a static method lacks cohesion. A static class can only* rely on internal static fields* and there is nothing wrong with modifying them...? And why can't a static method change objects that are passed to them? (assuming its on purpose)

one typical use is to implement Singleton pattern.

True, but some of us feel that Singleton is seldom appropriate. See for instance
Like any other tool, when used properly, Singleton is good. It's the 'used properly' part that causes issues, people seldom use it properly.

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.

Mr Shoubs
+2  A: 

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.

Michael Borgwardt
Singleton GetInstance, is the best example of a static method that modifies a static state (could initize the singleton object)
@Nix: singletons are generally considered not such a great thing. And initializing them in the accessor is mainly useful for producing endless pointless discussions about double-checked locking.
Michael Borgwardt

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.