• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Best practice: static import

 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I refer to the past thread regarding static import in Tiger and I feel that this feature compromise readability.

Though we're warned to use it sparingly, do you think we should even bother to use it at all?

Joyce
[ October 20, 2004: Message edited by: Joyce Lee ]
 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It seems to be a common practise for people to use interfaces to define constants (refer to "Effective Java" by Josh Bloch, Item 17 for further info). The import static should make it easier for the definition and use of constants without resorting to the spurious use of interfaces for the purpose. Thus, I think it's a worthwhile little addition to the language.
 
author
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think there's a balance that has to occur. It is indeed a nice feature, but can easily create more confusion. For example, I point out in my book that this can create all sorts of -additional- confusion (p. 126), although that's easy with regular imports as well.

In general, I only use static imports if:

1. I'm working with enum values -a lot- in my code

AND

2. The enum value names are -clear-.

If these two cases aren't true, I personally don't get into static import much. But, it's nice to have, for that odd occasion :-)

Thanks
Brett
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In some cases, I think static imports could be quite useful. For example, if you're writing a block of code that heavily relies upon a few static methods defined within Math, there's little reason to constantly write Math.whatever in your code. In fact, if you do it too much, code because long and difficult to read. Which of the following is easier to read?



Although these lines of code are quite contrived, I feel that the second line is more readable than the first. I would, of course, implore that appropriate documentation was included and that the programmer imported only the static method(s) needed and no more, to avoid namespace pollution.

But, in some instances, I think this could be an excellent benefit to Java.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


It seems to be a common practise for people to use interfaces to define constants (refer to "Effective Java" by Josh Bloch, Item 17 for further info).



I assume you meant "common and poor practice" instead of just "common practice"?

Item 17 makes this clear:
"The constant interface pattern is a poor use of interfaces" - most informed people, including myself, concur with Bloch.

The better solution is Item 21, the Typesafe Enum Pattern.
The J2SE 5.0 enum keyword is merely a shortcut to writing such a construct.

Just thought I'd clarify.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've effectively used static imports in a JUnit test class, where the code contains assertions using static constants defined in the target class. In this case the context is very clear.

-Jeff-
 
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tony Morris:


I assume you meant "common and poor practice" instead of just "common practice"?

Item 17 makes this clear:
"The constant interface pattern is a poor use of interfaces" - most informed people, including myself, concur with Bloch.

The better solution is Item 21, the Typesafe Enum Pattern.
The J2SE 5.0 enum keyword is merely a shortcut to writing such a construct.

Just thought I'd clarify.


Tony,
So does that make me uninformed

I agree that it isn't good to implement a class just to get the interfaces or use constants to represent types. But I don't see what's wrong with putting real constants in an interface and refering to them as MyConstants.MINUTES_PER_HOUR. I could see static imports being useful (and pretty clear) for this sort of thing.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeanne,
I meant that in a nice way.
Nobody knows everything


But I don't see what's wrong with putting real constants in an interface and refering to them as MyConstants.MINUTES_PER_HOUR



Well, Item 34 of Bloch makes it very apparant as to why this practice is general poor form. I have seen a lot of arguments that try to go against Bloch's suggestion, but in my opinion, they have all been arguments that are based on misinterpretation of Item 34 or failure to understand the consequences (e.g. dismissing them as academic).

This might help:
http://java.sun.com/docs/books/effective/
[ October 20, 2004: Message edited by: Tony Morris ]
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mr Bloch, who had a lot to do with the definition of J2SE 5.0, specifically intended for static import to replace the constant interface antipattern: see http://java.sun.com/features/2003/05/bloch_qa.html and http://www.theserverside.com/blogs/showblog.tss?id=JDK15
.

-j-
 
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:



Although these lines of code are quite contrived, I feel that the second line is more readable than the first. I would, of course, implore that appropriate documentation was included and that the programmer imported only the static method(s) needed and no more, to avoid namespace pollution.



Just to share my point of view on it, I feel like for those who just start to learn Java, they won't know that Math class contains round(), cos() and random()... And they need to go back to the import statements above and figure it out...

But the first code provides with the class name "Math". In this case, they don't need to go back to the import statements above to know about the class... This kinda of "easy to read and understand" matters as well...

Just sharing my opinion...
 
Simon Baker
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Indeed I did mean "common and poor practise". I know it to be common through industrial experience, and to be poor through common sense and education. The reference to Bloch was intended as a reference to the best discussion of why this is poor practise that I have seen. I would encourage anyone who hasn't done so to read "Effective Java" - it will improve what you do badly and cement what you do well. We can all learn something, particularly from someone who is so knowledgable and such a good author.
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ko Ko Naing:

Just to share my point of view on it, I feel like for those who just start to learn Java, they won't know that Math class contains round(), cos() and random()... And they need to go back to the import statements above and figure it out...

But the first code provides with the class name "Math". In this case, they don't need to go back to the import statements above to know about the class... This kinda of "easy to read and understand" matters as well...



Notice that I did include, in my original post, the fact that I would expect such lines of code to be documented. For example, the programmer could write "Static methods, such as rand(), cos(), and min() have been imported from java.lang.Math." That way, if any "new" Java programmers look at the code, the associated comments would point them in the right direction.

As I would expect most uses of statically imported methods/constants to be commented explicitly, I think I'd tend to use them in small groups, to make certain pieces of code more readable, rather than scattered out throughout my code.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ko Ko Naing:
Just to share my point of view on it, I feel like for those who just start to learn Java, they won't know that Math class contains round(), cos() and random()... And they need to go back to the import statements above and figure it out...

But the first code provides with the class name "Math". In this case, they don't need to go back to the import statements above to know about the class... This kinda of "easy to read and understand" matters as well...



I happen to be a huge proponent of readability in code, as I feel it has a significant impact on the cost of software development. But I would never promote cluttering code for the benefit of someone who doesn't have basic understanding of the Java language.

The Math class is a given; that's why it's in java.lang. Anyone having to do advanced mathematics (really, any Java developer) should certainly be aware of its existence and should have a rough idea of the methods it contains. Also, any decent IDE will quickly tell you where the method is defined.

Having said that, I think java.lang.Math class is the rare exception. Static imports of any other classes should be used sparingly and only where it helps "unclutter" the code.

A comment might or might not be prudent, given the nature of the code. But from my standpoint, if you feel compelled to add a comment to explain a static import, then it's an inappropriate use of static import.

-J-
 
Jeanne Boyarsky
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It seems to be a common practise for people to use interfaces to define constants (refer to "Effective Java" by Josh Bloch, Item 17 for further info).


But I don't see what's wrong with putting real constants in an interface and refering to them as MyConstants.MINUTES_PER_HOUR



I'm confused now. The server side link Jeff posted states:

Static Imports

Clients must qualify static members with class name (Math.PI). To avoid this, some programmers put constants in an interface and implement it. BAD - "Constant Interface Antipattern"


This says you should not implement the interface with constants, not that you shouldn't put constants in an interface to begin with. (In my example, I refered to it as MyConstants.MINUTES_PER_HOUR.)
 
Simon Baker
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or perhaps that you should not implement constants with an interface
 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,

Is static import when you use a fully path of a class, and so, you don�t need to import it ?
Like


Regards,
 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vinicius Boson:
Hi folks,

Is static import when you use a fully path of a class, and so, you don�t need to import it ?
Like


Regards,



Vinicus, there are a couple different imports you can do with that statement.

First of all, you can do a normal import so that you don't need to prepend java.lang to String, like this:



Of course, the entire java.lang package is automatically imported for you in every Java program, but you get the idea.

Additionally, Java 1.5 will allow you to import a static field or method so that you don't even need to prepend the class name to the method invocation or field reference, like this:



As you can see, the resultant code makes it appear as if charAt is defined within the class in which it is being invoked (or otherwise visible via inheritance). Of course, that's not the case, but that's what it looks like. Obviously, there's some discussion as to whether or not this is a good thing.

With regards to the "interface defining constants" thing, I think you really just need to use common sense. If a constant value has to do with a specific interface, I think it does belong within the interface declaration. Say, for example, you've created a Circle interface. You might have various other objects implement that interface, such as SolidCircle, DashedCircle, etc. Here's some possible code:



Yeah, it's a contrived example (and I realize PI is already defined in Math), but this is a case in which the constant has to do with the interface and, therefore, I see no problem with defining it within the interface. I have, however, seen interfaces that look like this:



The interface is useless - it contains no methods. Yet any class can implement it and instantly have access to all of these constants. This is an example of the anti-pattern folks are talking about.
 
Eusebio Floriano
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:
This is an example of the anti-pattern folks are talking about.



Corey,
I got exactly your point.

Thx,
 
I knew I would regret that burrito. But this tiny ad has never caused regrets:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic