I think that one of the style alarms goes off if you access a static via an
object reference.
For me, it pretty much comes down to intent. If the method really feels
like it is applied to the object, then it should be non-static.
If it is a pure function and is obviously such, then it should be static.
Math.sin is obviously static because the sine function isn't associated with
any particular object.
On the other hand, if I see
x.defaultInsertStrategy()
then the fact that (today) defaultInsertStrategy just returns a constant
should not necessarily make it (today) a static. Tomorrow,
it might be something more dynamic.
You comment about over-riding is trenchant, but it seems to me a part of the
real issue of object-centrism. Over-riding is one
of the obvious and main uses of objects so it is a strong indicator that the
method is object-oriented and not a pure function.
There are other indications as well, I think.
On Wed, Aug 18, 2010 at 5:42 AM, Sean Owen <[email protected]> wrote:
> What's the argument for making them non-static, versus not accessing
> them via instance references?
>
