How to decide between C# static and non-static methods?

Question

[Edit]

My original-question was \"Why to decide between static and non-static? Both do the same...\"

Unfortunately it was edited to a C#-specific question wh

Answer 1

In general if you have method like:

Document.Copy(myDocumentObject, toPath);

I think it is better to use a non-static method, because the first parameter being a Document suggests that it is really an operation on the document.

Answer 2

If you have to ask, don't use statics.

Actual rule of thumb (and there are plenty of real technical reasons but I find this helps explain the concepts):

• If the class in question can exist multiple times it's not static.

• If the method in question acts against the instance information it's not static.

• If the method or class is about meta-information it's static.

With those guidelines it's clear that files and documents are multiples and copying is an act against the instance. The method should not be static.

Answer 3

KISS. If you don't have to call a constructor, even better.

Also, a method being static should tell you a little about how the function operates:

• It doesn't operate on variables outside of what's passed to it.
• It doesn't require any memory other than when the method is called (not counting what is returned from the function)

There are some other important things to note:

• Static methods in some instances (Java) are not able to be overridden/subclassed, so they are better suited for cases where the implementation will not need to change.
• Some would argue that static methods are intrinsically difficult to test.

I would also refer to this thread, and a simple google search which frankly provides copious amounts of discussion on this very topic.

Answer 4

Static Methods are can be very useful, I love extension methods, but they force coupling and if used improperly can make testing a nightmare!

A good example of when to use a static is when you want to do so validation

public static errors Validate(Document myDoc)
{
..some validation code
}

this is very testable and it doesn't mater that your tightly coupling the method to an object. A Bad place to use a static method is when it dose something other then just return something, an example would be in a Biz layer that validates an object and if it passes validation it save the data to the DB

public static errors ValidateAndSave(Document myDoc)
{
    errors docErrors = Validate(myDoc);
    if(docErrors.count==0)
    {
         docErrors = SaveToDB(myDoc);
    }

   return docErrors; 
} 

This is a real pain to test because every time you run it, and it passes validation your taking to the database, your Biz logic may not generate an error but but your DAL layer might, so instead of only testing the functionality of the Biz layer your also having to test the DAL layer as well, and your tightly coupling your object, your Biz layer and your Dal together making this very hard to test and maintain.

Answer 5

In general, I would say that "copying" oneself, as far as an object is concerned, usually means cloning one's data into a new object. The "copying" described here is something the filesystem is doing on your behalf, not the object. As such, I'd make it a static method and not a method on a Document instance.