i posted a reply at stackoverflow then i noticed the last post was 2009. i liked my own advice
so i start a thread here.
i have developed a liking for static methods(only, if possible) in "helper" classes. the calling class need not create another member(instance) variable of the helper class. you just call the methods of the helper class. also the helper class is improved because you no longer need a constructor, and you need no member(instance) variables. there are probably other advantages.
i think the static keyword should be used anytime it seems appropriate. also the same regarding final. anytime it seems appropriate!
an argument could be made that any main GUI class should maybe be final. such a class you might want to change but not extend.
Randall Twede wrote:i think the static keyword should be used anytime it seems appropriate. also the same regarding final. anytime it seems appropriate!
Well, this isn't saying much. "X should be used anytime it seems appropriate" goes for everything in life.
Personally I think you should be careful with static. Helper or utility methods are good, and should be static, but you should always think well when you find yourself writing the word static. Also be careful not to write "companion classes". If a utility class exists solely for the purpose of aggregating static methods used by one other class, you should just put those methods in that class.
Final is different. Slap it around as much as possible. Make "value types" immutable; the use of final should be obvious. Make collection members final. Make all classes final unless you explicitly design them to be subtyped. If it doesn't impede readability too much, I even make method parameters and local variables final.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.