class design: When to use static methods?

[Stefan Ram]

Instance methods! They make the difference between
object-oriented programming in Java and procedural
programming in Java (according to the common believes).
And OOP is better than procedural programming, so we must
use instance methods! (according to the common believes)

Yet Sun or Oracle has moved the non-static exists() method
of java.nio.file.Path (of the early 1.7 versions of Java)
to the static exists() method of java.nio.file.Files (of the
current version of Java).

What might have been the reason for which they have done this?

 

[Stefan Ram]

Yet Sun or Oracle has moved the non-static exists() method
of java.nio.file.Path (of the early 1.7 versions of Java)
to the static exists() method of java.nio.file.Files (of the
current version of Java).

Another remarkable case is this:

Today, one needs to write:

java.nio.file.Files.readAttributes
( path, java.nio.file.attribute.BasicFileAttributes.class )

, that is, one has to use a kind of »class token« (2nd
argument) to tell the static readAttributes method what to do.
This does not really use Java's type system and was also
changed since the prerelease version.

A hypothetical version of this call that would use the
Java type system in a more natural way might be:

java.nio.file.attribute.BasicFileAttributes.of( path );

. It would not need a »type token« to tell the method called
which kind of attributes to read, while it, too, still uses
a static method.

 

[Arne Vajhøj]

Another remarkable case is this:

Today, one needs to write:

java.nio.file.Files.readAttributes
( path, java.nio.file.attribute.BasicFileAttributes.class )

, that is, one has to use a kind of »class token« (2nd
argument) to tell the static readAttributes method what to do.
This does not really use Java's type system and was also
changed since the prerelease version.

public <T> T methodname(Class<T> clz, SomeType arg)

is a very commonly used construct in Java.

And I don't see it as not using the type system.

A hypothetical version of this call that would use the
Java type system in a more natural way might be:

java.nio.file.attribute.BasicFileAttributes.of( path );

. It would not need a »type token« to tell the method called
which kind of attributes to read, while it, too, still uses
a static method.

First BasicFileAttributes is an interface which makes it impossible
to do this in Java 1.7.

Second even it were a class then making a class its own factory
is rarely a good choice.

Arne

 

[Arne Vajhøj]

Instance methods! They make the difference between
object-oriented programming in Java and procedural
programming in Java (according to the common believes).
And OOP is better than procedural programming, so we must
use instance methods! (according to the common believes)

That is an over simplification of OOP.

GoF patterns are very OOP'ish and they use static methods
for some things.

Yet Sun or Oracle has moved the non-static exists() method
of java.nio.file.Path (of the early 1.7 versions of Java)
to the static exists() method of java.nio.file.Files (of the
current version of Java).

What might have been the reason for which they have done this?

Both my Java 7 and 8 docs has a Path interface and a class Files
with a static exists method.

So I am a bit confused by the above.

All methods in Files are static utility methods that just
use some other classes with the real functionality.

Arne

 

[Eric Sosman]

Instance methods! They make the difference between
object-oriented programming in Java and procedural
programming in Java (according to the common believes).
And OOP is better than procedural programming, so we must
use instance methods! (according to the common believes)

Not so long ago in a thread about "The invokeLater loop,"
you seemed quite pleased with a (perverted) use of the static
method SwingUtilities.invokeLater(). Does this transgression
against OOP principles bring a blush to your cheek?

Or is the redness a result of blowing too much smoke?