Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #2464

Re: When to use static methods?

Show all headers | View raw

markspace wrote:
> Steve wrote:
>> I find static methods to be very convenient when the method doesn't need
>> stored ( in the class it belongs to ) values.

That is a necessary but not sufficient motivation for a static method.
 
> Yup.  Use static methods when they are not logically part of an 

The game, Watson, is to determine by what criteria a method is deemed 
"not logically part".

> instance.  Collect static methods together in a single non-instantiable 

Maybe a single class. Maybe. 

> class when such collections make logical sense.

Oh.

> Eschew automated code review tools.  Seriously, wtf?

Depends on what they mean by "code review tool".  FindBugs and other static analysis 
tools, and lints are code review tools. They are no more the code review than a power saw 
is carpentry.

The game here is to use them as tools, and to use them as responsibly as a professional 
would.

As for static methods, obviously they cannot depend on instance state. That is not so much 
a motivation as a restriction.

But staticness, as global members are wont to do, brings other restrictions. You cannot 
override a static method. You cannot declare a static method that is signature-compatible 
with a supertype's instance method. You should only refer to a static member, including 
methods, via the declaring type, not a subtype or instance reference. Once you declare a 
method static it breaks backward binary compatibility to make it non-static, like say if 
you decide you need to be able to override it. Because you can't override a static method, 
you can't implement an interface's static methods in a concrete class. Concurrency is 
sometimes more of an issue with static methods. It really does not make a difference to 
code size whether a method is static, so there's no compelling reason ever to make a method 
static except to avoid instantiation. If you have an instance of a type anyway whenever 
the method is used, it's usually better to have the method tied to the instance and otherwise 
harmless.

The real test of staticness, for both member variable and methods, is the "to what does it
belong?" test. If your type's architecture calls for an instance to manage whatever state and 
behavior it's doing, then that instance should own all the behaviors it's doing even if they 
don't directly use the instance state. If your type's architecture calls for there never to be an 
instance, and you only create one to run a stateless method, then the method belongs to 
the type, and should be static. If the method is designed to serve many types, not just its 
owning type, and there's no other reason to have an instance own the method, it belongs 
to the type. If a method serves only its own type, ever, then most likely it should not be 
static, unless you are clear that its behavior belongs to the type and not any one instance.

Or in short form: Favor instance methods over static, unless compelled otherwise.

-- 
Lew

Back to comp.lang.java.help | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

When to use static methods? Steve <tinker123@gmail.com> - 2013-01-17 16:15 -0500
  Re: When to use static methods? markspace <markspace@nospam.nospam> - 2013-01-17 14:02 -0800
    Re: When to use static methods? Lew <lewbloch@gmail.com> - 2013-01-17 15:04 -0800
      Re: When to use static methods? Lew <lewbloch@gmail.com> - 2013-01-17 15:13 -0800
  Re: When to use static methods? Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 15:01 -0800

csiph-web