File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes static and final Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "static and final" Watch "static and final" New topic
Author

static and final

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

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.

opinions?


SCJP
Visit my download page
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: static and final