Psychedelic Panorama of Foo

Static Imports and Constants in Java

아녕하세요. What are static imports? Well it only exits in Java 5.0 and later. It was originally intended as way around Constant Interface Antipattern. For more information see Sun's explanation of Static Imports.

Here's an example.

Even though static imports exist to solve an antipattern, many developers regard them as being bad. I have decided to officially stamp my opinion on the matter and take a stance in support of static imports. That means this post is biased towards static imports.

To be fair, I first want to make a case against static imports and describe why many disapprove. The largest complaint is that it makes the code difficult to read. Take the aforementioned example. There could be a lot of code between the actual import statement and the place(s) where it is used. This means that if you are a noob and you want to know where BLANK is, you have to scroll all the way to the top of the file. Also, there are possible namespace issues. If a constant name is common through your application and third-party libraries, but is different in any of those cases, then static imports may not even be possible to use.

Now let me say that static imports actually improve the readability of code literally. "Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names." from Static Imports.Let me explain. Take the following quote from Edgar Allen Poe's "To Helen":

Clad all in white, upon a violet bank
  I saw thee half-reclining; while the moon
  Fell on the upturn'd faces of the roses,
  And on thine own, upturn'd--alas, in sorrow!

Now let's rewrite it using Kuali code which doesn't use the Constant Interface Antipattern, but puts all the constants in a single class.

Now here is the case where static imports is used to simplify things.

You can see in the first example, the readability is greatly limited by KraServiceLocator, Constants, and GlobalVariables allover the place. Static imports in the next part greatly reduces this and makes it much more readable literally. Keep in mind though, that this really only makes sense because of the number of times KraServiceLocator and Constants are used. If there are only 2 cases in the code, then it would be really silly to use a static import. It's almost a waste of time. However, the most common case is the one illustrated above where Constants and KraServiceLocator are used a lot. For you it may be different classes, but if you are doing any of the following:

• Sticking all your constants in a central file
• Using a large number of constants from a single class
• Using one constant again and again.

... then, you definitely need static imports.

I have a solution for those that have trouble with static imports because they don't like to scroll. If you're using Eclipse, you can just hold the Ctrl with your mose over the constant. It will highlight and take you directly to where it is declared at the top of the code. Follow the same procedure again, and it will then take you to the source file where the constant is cross-referenced. If you hold the Alt button and press the back arrow, it will take you back. Press it again, and it will go back again to where you originally were. Very fast for browsing code. Of course, if you followed the rules outlined above, then you don't need to know where the constant is defined. You should already know because it is used everywhere.

I have further problems with needing to know where the constant is defined. Why does a developer need to know straight away without thinking where the constant exists. I think it is more important to know what the constant represents than where it is defined. Take for example, Constants.ZERO. I care more that it is "ZERO" than whether Constants.ZERO = "0" or Constants.ZERO = "0.0" or that Constants.ZERO is in org.kuali or org.apache. What I care most about is that it is "ZERO." My above information is a solution to that in both cases whether you are using static imports or not. Not that this is always the case. I can understand that if something is showing 0.0 and it should be 0, then it would probably matter where that is, but that's what logging and debuggers are for. But if we can rely on constants being in the same class, we shouldn't need to qualify that class. Just like we don't need to qualify the package name the class is in.

I think that if a constant is encountered that isn't in Constants, then it should probably be qualified for clarity. Take for example, Math.PI vs. Constants.PI. I think Constants.PI should probably not be qualified, but if someone decides they want to use Math.PI (for example:) if (PI == Math.PI) ...

Static imports aren't bad. They're actually good, but keep in mind that they can be abused. Please don't ruin it for the rest of us.

레이블: java, programming, software

작성자: r351574nc3  # 5:54 오후