Excessive use of 'static' in Objects

Question

Hello all,
I have inherited a code base which consists of around 90 objects seemingly randomly thrown together in a down and dirty effort to crank out working code as soon as possible. The original programmer has left the company and I've inherited his projects. While attempting to isolate some performance shortcomings I noticed that nearly every single class has a static method of some sort or another. My understanding is that this is clearly a bad idea as, if for no other reason, those objects, having a static method, will exist during the entire lifetime of the application and are not candidates to be GC'd. Furthermore these objects contain many String instances which, if the object that contains them isn't ever eliminated, will remain as huge memory hogs as well.
So, in essence, what are the general thoughts of the architects and developers on this board regarding the use of the 'static' keyword and it's effect on Object design and the implications for performance and memory? Any feedback would be greatly appreciated. I have looked through numerous books on OO design but nobody seems to speak directly to the implications and "best practices" of designing with the 'static' keyword, where, when and how it's most effectively used, etc.
Thanks!

Answer 1

Hi,
would you consider that the primary motivation for use of static, that the method in question use only class member variables?Often yes, but not always. The example given by jschell above is typical of a static method, but you can't always make methods static like this. If isDefined(String s) were specified by an interface (it couldn't be private in this case though), to implement different variants of what it means for a String to be 'defined', then you couldn't make the method static even if it did not depend on the object you are calling it on.
However I am still looking for a good "rule of thumb" that will help me to determine what the most appropriate use of the static keyword is/should be.For methods you should ask yourself "How will the method be called?" If it only makes sense to call it on an instance of the object then DON'T make it static, even if it could be. Static methods should only be called like this:
   ClassName.staticMethod();and not like this:
   instanceOfClass.staticMethod();as this second style of invocation is very misleading (and it really winds me up when I see it!).
As for fields - in my own code I tend to have private static final objects for constants or 'collections' that are used by many instances, or which are available through public static utility methods. Immutable static final fields I often make public. Pretty much everything else is non-static. I have no idea whether this is 'best practice' though.
You may also want to look at the java.util.Collections and java.util.Arrays classes. These cannot be instantiated and provide only static utility methods for manipulating other objects. It can sometimes help to split off the static 'utility' functions into another class like this, especially if common functions can be applied to an interface.
Ol.