Re: To static or not to static

Wojtek wrote:


The example was perfect for the intended purpose, and illustrated the question
perfectly as well. I disagree that it should have been longer.

OTOH, the factors that distinguish the choice of static or not tend to emerge
only in somewhat more complex circumstances. It is not didactically necessary
to provide new SSCCEs for those circumstances; it suffices to outline the
differences from the original example and how they would influence the decision.

For example, a class dedicated entirely to methods that receive all relevant
state from method arguments would and should declare those methods static. A
class that wishes a method to be overridable, that is, to display variant
behavior polymorphically, must declare such a method at instance level even if
all state arrives in the arguments. Such a class will also be intended for
instantiation.

Factory methods for the class in which the factory appears should be static.
(Factory classes with instance methods are a different idiom.)

Absent those rules of thumb, a class intended to be instantiable might prefer
instance methods to static methods, if only to reduce the need for two ways to
invoke methods in the code:

  Foo foo = new Foo().
  Baz zesult = Foo.act(); // act depends on no instance variables
  Bar result = foo.transform( zesult );

vs.

  Foo foo = new Foo().
  Baz zesult = foo.act(); // act depends on no instance variables
  Bar result = foo.transform( zesult );

For me at least, the presence of an instance variable makes it natural for
that instance to own all the behaviors, even ones that might be implementable
at class level. Even then, some behaviors so clearly belong to the class as
such that it just makes sense to make them static.

--
Lew