Constants: "final static" vs. "final"

Question

In a GUI object, I have some class constants that are only used internally. Example 1:
private final int PREFERRED_WIDTH = MainWin.MAX_WINDOW_WIDTH;
private final int PREFERRED_HEIGHT = 50;Example 2:
private final JButton helpButton = new JButton("Help");
private final JButton closeButton = new JButton("Close");
private final JLabel clearanceLabel = createClearanceLabel();Should the members in EX1, EX2 be static??
These items are members of a GUI object, and there is only 1 instance of this GUI object during application runtime.
The nature of my question is about the best practices of when to use the "static" modifier for private class constants.
Thank you
Message was edited by:
PatrickFinnigan

Answer 1

and "static" as sparingly as possible -- Disagreement here. First, of course, use it when
appropriate. Second, though, my customers coding
guidelines urge to use static for all methods that
aren't accessing non-static members; there might be a
reason for that although I don't know. But it's
basically no problem declaring those as static.I can see the logic of declaring them static if they don't access anything instance-level; at least it makes it more obvious what it's doing. I suppose you might want to keep it non-static if you think that at some point the implementation will change and you don't want users of the API locked into a way of calling it which won't work, but such thinking can be dangerous.
On a related note, a bad design choice I sometimes see is an excessive use of objects in which there is absolutely no state being maintained; the code in question doesn't need to be non-static at all. Making things objects when they don't have to be can make things too complicated.
On the other hand, when you're doing object-oriented programming and you find that you're never creating objects, then something is seriously wrong.
I think the best rule of thumb is: keep a clear understanding of what's an object, what isn't, and why; keep objects and non-objects clearly built as such, don't make things that are basically static utility methods into objects just because you can; and if you find that you're throwing the keyword "static" around a lot, then it's a red flag that you've probably got something wrong in your design.