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

Groups > comp.lang.java.help > #2461 > unrolled thread

When to use static methods?

Back to article view | Back to comp.lang.java.help

Contents

  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

#2461 — When to use static methods?

Hi,

I was at a JUG roundtable workshop last night where various code review 
tools were being discussed.

The facilitator kept mentioning how the use of static methods made 
automated code reviews more difficult and that he tried to minimize the 
use of static functions.

I find static methods to be very convenient when the method doesn't need 
stored ( in the class it belongs to ) values.   Instead of having
to instantiate the object every time I want to use the method I just
have to type the class name and the method.

So, I would like to hear your opinion.  When wouldn't I want to use 
static methods aside from the obvious( the method depends on member
variable with changing values )

Steve

[toc] | [next] | [standalone]

#2462

On 1/17/2013 1:15 PM, Steve wrote:
>
> I find static methods to be very convenient when the method doesn't need
> stored ( in the class it belongs to ) values.

Yup.  Use static methods when they are not logically part of an 
instance.  Collect static methods together in a single non-instantiable 
class when such collections make logical sense.

Eschew automated code review tools.  Seriously, wtf?

[toc] | [prev] | [next] | [standalone]

#2464

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

[toc] | [prev] | [next] | [standalone]

#2465

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

Addendum: The "depends on instance state" criterion is circular reasoning, if you have 
mis-architected your type to have mutable static member variables on which the method 
depends. Then a judgment of "depends only on global state" is a consequence of the 
design error that there is global mutable state.

So that rule is more safely expressed as "depends on mutable state". This helps you 
realize that mutable state should be instance state.

-- 
Lew
All rules have zero exceptions, ever.

[toc] | [prev] | [next] | [standalone]

#2463

On Thu, 17 Jan 2013 16:15:54 -0500, Steve <tinker123@gmail.com> wrote,
quoted or indirectly quoted someone who said :

>The facilitator kept mentioning how the use of static methods made 
>automated code reviews more difficult and that he tried to minimize the 
>use of static functions.

The main reason to use a instance method when a static method would do
it to permit it to be overridden later.  I use IntelliJ whose lint
presses you not to do that.  If you need overriding later then remove
the static keyword.

This may be a limitation of his lint tool.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web