This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Java in General and the fly likes Regarding type safe enum design pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Regarding type safe enum design pattern" Watch "Regarding type safe enum design pattern" New topic
Author

Regarding type safe enum design pattern

praveen raaj
Greenhorn

Joined: Nov 30, 2009
Posts: 11
Hi Friends,


The preceding code is 'type safe enum' design pattern,then Why should we go for java.lang.Enum?
John de Michele
Rancher

Joined: Mar 09, 2009
Posts: 600
Praveen:

The type-safe enum pattern was designed in the pre-1.5 days. Now, you can just use the enum keyword, and get the same thing.

John.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19649
    
  18

Plus enums are easier to write. Consider the equivalent of your code as an enum (maintaining the same style):
The same functionality, plus more*, in just 5 lines instead of 15.

* Enums are automatically Serializable and Comparable, can be used in switch statements, and give you the static values() and valueOf(String) methods.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
praveen raaj
Greenhorn

Joined: Nov 30, 2009
Posts: 11
Hi Friends,
Thanks For Your Replies.

I have "Java 2 Performance and Idiom Guide" by Craig Larman and Rhett Guthrie. They declared the typesafe enum constants in an interface.something like this.
my Question is will we have any drawbacks using this design?and this is also typesafe enum design pattern Right?

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37890
    
  22
Too difficult a question for "beginning Java" Moving.

That last bit of code looks a bit like a constant interface, but I am not sure and other people will be better able to tell you that.
Ulrika Tingle
Ranch Hand

Joined: Nov 24, 2009
Posts: 92
praveen raaj wrote:
my Question is will we have any drawbacks using this design?and this is also typesafe enum design pattern Right?


This pattern is obsolete for Java. It has been replaced by the enum feature which has everything this pattern has (and then some).

To be specific, never use a work-around for a feature that's built into the language. I didn't say you shouldn't know about this design pattern. It can come in handy to understand old code written by others. But don't use it in new, post version 5, code. It's just square.
praveen raaj
Greenhorn

Joined: Nov 30, 2009
Posts: 11
Hi ulrika,
Thanks For Your Reply,

java.io.ObjectStreamConstants is constant interface in the Java 1.6, why sun has not used java.lang.Enum for defining constants?


Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2982
    
    9
Basically, because Sun is extremely reluctant to risk breaking backward compatibility, even for poor designs. Some parts of Java were written rather quickly, and early in the language's history - perhaps before the pitfalls of certain designs were well-understood. ObjectStreamConstants is an example of this. But it's possible that some programmers have extended ObjectInputStream or ObjectOutputStream in their own code and made use of ObjectStreamConstants - Sun doesn't want to break their code, so they won't change the existing OIS/OOS/OSC classes. Not at the API level, at least.

Note that ObjectStreamConstants is not a typesafe enumeration; it's a constant interface. Two related concepts, but not the same thing. Typesafe enumeration was generally preferable to constant interface, but typesafe enumeration was not generally known when Java was first released. Later when JDK 1.5 came out, the new Java enums were much like typesafe enumerations, but much easier to write. But you will still find examples of all three in Java's standard libraries; Sun won't generally replace old APIs, though they may change classes internally if this can be done without significantly changing behavior in ways that might break existing code. What this means is, don't expect Sun's code, especially older code, to always follow best practices.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

praveen raaj wrote:java.io.ObjectStreamConstants is constant interface in the Java 1.6, why sun has not used java.lang.Enum for defining constants?

Note that interface java.io. ObjectStreamConstants has been in Java since version 1.1 (according to the documentation). Sun does not change it to a Java 5 enum, because that would mean that old programs would not work anymore on the new version.

This is just one example - there is lots of old stuff in the standard Java library which isn't changed because of backward compatibility issues; for example using Enumeration instead of Iterator, using legacy collection classes such as Vector instead of ArrayList and not using generics.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
praveen raaj
Greenhorn

Joined: Nov 30, 2009
Posts: 11
praveen raaj wrote:
I have "Java 2 Performance and Idiom Guide" by Craig Larman and Rhett Guthrie. They declared the typesafe enum constants in an interface.something like this.
my Question is will we have any drawbacks using this design?and this is also typesafe enum design pattern Right?



still I have not cleared doubt regarding preceding design pattern.I don't know why I worry so much about these things.
Has anybody else here read the above code and if so, what are your thoughts? Jesper... ?Rob...?
John de Michele
Rancher

Joined: Mar 09, 2009
Posts: 600
Praveen:

I'll echo previous posters' comments and just say to stop worrying about it. If you're using JDK 1.5 or later, just use the enum keyword to create your enums. Simple as that. You can ignore the various pre-1.5 patterns.

John.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

Ok, if you absolutely want to get an answer to the question "what are the drawbacks of this code": One drawback is that it's much more complicated to write that code and to read and understand that code than when you'd use a Java 5 enum. Because it's more complicated, you're more likely to create a bug in it, and it will be harder for other programmers to understand the code.
Ulrika Tingle
Ranch Hand

Joined: Nov 24, 2009
Posts: 92
praveen raaj wrote:
Has anybody else here read the above code and if so, what are your thoughts?


You mean my secret thoughts? Okay I think that code is like a cold, dark and smelly outdoor toilet. The enum on the other hand is like a comfortable indoor water toilet with soft paper and automatic flushing and music coming from the wall. It's used for the same purpose and with the same result but it certainly is a different user experience. It's your choise.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Regarding type safe enum design pattern
 
Similar Threads
Enum's doubt from Java Beat
Doubt in K&B SCJP 5: p62. semicolon after the declaration of enum
getSelectedItem() selects nothing
AbstractMethodError
Enums