Menu
I've recently noticed that when I create private methods that set a few fields in the objects passed to them that Resharper puts up a hint stating that the method can be made static.
Here's a greatly simplified example of the sort of method I might have.
private void MakeStatusTheSame(MyClass mc, MySecondClass msc)
{
mc.Status = msc.Status;
}
When I've got a method like this, Resharper provides a recommendation that the method can be made static.
I try to avoid making public methods static since they wreck havoc on unit tests...but I'm not sure that the same applies for private methods.
Is Resharper's recommendation a valid best practice or should I just turn it off?
446
You should consider making a method static in Java : 1) If a method doesn't modify the state of the object, or not using any instance variables. 2) You want to call the method without creating an instance of that class.
After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code.
Common Use for Static Methods followed by the name of a method. They are declared with the keyword "static" when defining a method. Static methods can be accessed without having to create a new object. A static method can only use and call other static methods or static data members.
The advantage of using a static class is that the compiler can check to make sure that no instance members are accidentally added. The compiler will guarantee that instances of this class cannot be created. Static classes are sealed and therefore cannot be inherited. They cannot inherit from any class except Object.
I think that's definitely a prime candidate for a static method. It's not changing any of the class's properties, fields, etc.
Here's an example:
class MyClass
{
public static void MakeStatusTheSame(MyClass mc, MySecondClass msc)
{
mc.status = msc.status;
}
private void MakeStatusTheSame(MySecondClass msc)
{
this.status = msc.status;
}
private int status;
}
Also, you could make it an extension method (which would also be static):
public static class Extensions
{
public static MyClass MakeStatusTheSame(this MyClass mc, MySecondClass msc)
{
mc.status = msc.status
return mc; /* make the method chainable */
}
}
At the risk of sounding like a contrarian, I've got to admit that I don't like mixing static methods with instance methods; and I dislike static methods in general. Static methods are difficult to test, difficult to override, and difficult to maintain. I prefer to stick all static methods for dealing with Foo objects into a single FooUtils class -- or, better yet, into a singleton instance of a FooSomethingDoer class.
Of course, static methods make perfect sense in some cases -- for example, when creating the aforementioned singletons, or factories, etc. I'm not saying that all static methods are made of pure evil; I just prefer to err on the side of avoiding them when possible.
30
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
