Static methods verus Instance methods

[lightning]

In project, I feel that using SomeClass.someMethod() is very
convenient and quick to deal with sth.
e.g:
MailUtil.sendMail(String from,String to,String text) throws
XXXException...

In fact, I worte so much code to make tool methods in this way and
feel that not only me myself feel good but also others using my code
feel good.

However,
the code like:
SomeClass x= Somelocator.getSomeinstance();// or SomeClass
x=new ....
x.someMethod();

bothers us more.

What's the advantage of using instance methods instead of using static
methods in making tool methods?
Memory issue? GC or jvm issue? Or just design pattern issue?

 

[Mark Space]

Memory issue? GC or jvm issue? Or just design pattern issue?

In my opinion, since static methods are not polymorphic in Java, you
can't conveniently change implementations or code to an interface.

Given a program that uses this static method:

public class Utils {

public void largeExpensiveFileIO( File f ) { //...

}

One cannot easily switch implementations of largeExpensiveFileIO to a
test harness. You'll have to rig up a test class yourself.

public interface MyUtils {
public void largeExpensiveFileIO( File f );
}

class TestUtils implements MyUtils {
@Override
public void largeExpensiveFileIO( File f ) { //... test stuff
}

class LiveUtils implements MyUtils {
@Override
public void largeExpensiveFileIO( File f ) {
Utils.largeExpensiveFileIO( f );
}
}

Now you have a pair of classes you can easily test with. Code
everything to the interface, then inject the class you want (test/live)
at runtime.

Which is better, provide an interface for your callers, or make them rig
up a specific interface for their own problem domains? Heck if I know.

If the static methods work, I think there's no reason not to use them.
Do think a bit beyond just writing code and towards testing, maintenance
and latter modification and extension. But if those can't be easily
foreseen, I think static methods are adequate.

 

[Lew]

[...]
What's the advantage of using instance methods instead of using static
methods in making tool methods?
Memory issue? GC or jvm issue? Or just design pattern issue?

IMHO, there's no reason not to make a method static unless it has to  
access instance members of the class.  That's practically "by definition",  
as far as I'm concerned.

There are numbers of examples of classes, often utility classes, that are  
_nothing_ but static methods.  There are some slight performance  
considerations, where static calls can have less overhead, but IMHO the  
main issue is simply one of design.  Don't give your code more access than  
it needs, and don't make callers make and/or use an instance if the code  
is never going to actually take advantage of data in the instance.

IMO, though I see the value of Peter's advice, there's no reason *to*
make a method static unless it absolutely must represent global
behavior from a design standpoint. Even if the method doesn't access
instance state, there's no harm in having it be an instance method.

Provided you have an instance available anyway.

I believe this makes thread-safety and possible future refactoring
easier. It also supports overriding the method in subclasses (if
heritable) and simplifies the reference to the method. (No need for a
class reference when 'this' is here.)

Static methods are for factories and non-instantiable classes, the
rest of the time I use instance methods unless the behavior is truly
intended to represent class-wide behavior.

Just another POV. I would not ding a module in code review for
following Pete's standard, nor for declaring an instance method that
doesn't access the instance's state (again, provided you have an
instance anyway).

In that way, my standards are similar to those I use for brace
placement in control structures. While I believe it's more logical
and easier to read to have the opening brace on its own line, it's a
well-established convention to have it on the end of the condition
line, so I don't ding either approach.

To summarize:
Static methods represent global behavior, and are best used as factory
methods and in non-instantiable classes. Instance methods must be
used in order to access instance state, and may help even absent that
if you want the ability to override them. When in doubt, Peter will
call for a static method, and I will call for an instance method
whenever access is via an instance anyway.

 

[Arne Vajhøj]

In project, I feel that using SomeClass.someMethod() is very
convenient and quick to deal with sth.
e.g:
MailUtil.sendMail(String from,String to,String text) throws
XXXException...

In fact, I worte so much code to make tool methods in this way and
feel that not only me myself feel good but also others using my code
feel good.

However,
the code like:
SomeClass x= Somelocator.getSomeinstance();// or SomeClass
x=new ....
x.someMethod();

bothers us more.

What's the advantage of using instance methods instead of using static
methods in making tool methods?
Memory issue? GC or jvm issue? Or just design pattern issue?

It is rather common to use static methods in FoobarUtil and FoobarHelper
classes.

As a general rule though be careful only to create static methods when
you are absolutely sure that they will stay static forever. It is very
common to start with static methods and then have to refactor to
non-static methods later when requirements become more complex. I have
never seen the other direction. So if in doubt make it non-static.

Arne

 

[Daniel Pitts]

In project, I feel that using SomeClass.someMethod() is very
convenient and quick to deal with sth.
e.g:
MailUtil.sendMail(String from,String to,String text) throws
XXXException...

In fact, I worte so much code to make tool methods in this way and
feel that not only me myself feel good but also others using my code
feel good.

However,
the code like:
SomeClass x= Somelocator.getSomeinstance();// or SomeClass
x=new ....
x.someMethod();

bothers us more.

What's the advantage of using instance methods instead of using static
methods in making tool methods?
Memory issue? GC or jvm issue? Or just design pattern issue?

Design pattern is the common one. I have several times had to refactor
from static methods into a instance class. I have *never* had to
refactor the other way.

Now, it depends on what the use of method is, and if it depends on other
methods itself.

If it is a simple method that is basically a "functional style" function
(meaning no state is used or modified during the call), then it is "safe
enough" to use static.

If it is a method that makes lots of other callbacks or calls many other
static methods, it might make more sense to put it, along with a lot of
the other calls, into there own class.

As for memory/gc, creating an instance takes a minuscule amount of
memory, and static takes slightly less. The benefits of instance
methods are they are polymorphic and can have state.