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

ENUM'S

mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Hi everyone,
I made deep researches about Enum's however there are still some questions which make me confused.

1)What are the differences between classes and enum's ?
2)Does it have any function except creating output ?
And lastly, it is said that enum class types consist of objects but this objects represents the outputs. So how can be said that they are objects.

Regards


Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by mert �zkaya:
1)What are the differences between classes and enum's ?


Enums are special kinds of classes, that make it easier to implement the Typesafe Enum pattern.

What makes them special is that they always have a fixed number of instances, defined at compile time.


2)Does it have any function except creating output ?
And lastly, it is said that enum class types consist of objects but this objects represents the outputs. So how can be said that they are objects.


I don't understand this. Nothing in enums is specific to "creating" or "representing output".


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Enums can be used in switch statements. I think this is one of their most important functions.

Layne


Java API Documentation
The Java Tutorial
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by mert �zkaya:

2)Does it have any function except creating output ?
And lastly, it is said that enum class types consist of objects but this objects represents the outputs. So how can be said that they are objects.


Perhaps what you might mean is that each enum member compiles to a reference of the enum type referring to a new instance of the enum type. They are not objects. In fact, it is is very difficult to say "<something> is an object", since objects have no name, therefore, what plausible value for <something> can legitimately exist? References do have a name, and can be used to describe an object since they refer to objects - maybe you mean that.


Tony Morris
Java Q&A (FAQ, Trivia)
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Layne Lund:
Enums can be used in switch statements. I think this is one of their most important functions.

Layne


I think Sun acknowledge that this is not a recommended approach, but have failed to admit it publicly. Instead, they introduced the EnumMap type to persuade and maintain users' optimistic view of the language. Of course, it is poorly designed - in fact, worse than the already very low average. It could even be argued that it offers no value at all - purely replicating java.util.Map spiced with some superficial detail. So why does it exist? I have offered an optimistic explanation (as opposed to questioning the competence of the author(s) being a pessimistic and "last resort" explanation).

Speculation of course, but I just can't imagine that everybody at Sun is completely ignorant to what appears obvious - at least to me - avoid switch/case indiscriminately. On the flip side, I work for a large corporation on the J2SE spec. with a bunch of... er... "engineers" who wouldn't have half a clue about why switch/case is inherently flawed (total subscription to doctrine and not reasoning) - so it may just be a possibility within the Sun camp as well.
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
Emum's not just for switch statements anymore.

Seriously though, one can define methods for enums, and even allow them to exhibit a certain kind of polymorphism (I don't know if it is true polymorphism or not bc I'm not sure if the binding is done at compile-time or run-time).


Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Hi everyone,
In the following codes, there is an enum type which is "Size" and it has objects. Is not it?
Then we create an instance of this enum type and make it equals any object of the Size type.

Briefly my questions is that how can we say narrow,baggy,wide,tight are objects. I think they are all variables.

Regards

Mert
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
If it helps, maybe you can think of them as final variables each of which refers to a specific instance of Size.
mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Hi,
We can only use these final variables as an output on the screen, is not it???

I ask that is there any more advantage of using ENUM'S?

Thanks,

Mert
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
With enums you can declare instance variables, methods, and constructors just like in a regular class. Take for instance this trivial class:


The enum class here has everything a normal class could, including an abstract method that must be implemented by each instance of the enum type.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by mert �zkaya:
We can only use these final variables as an output on the screen, is not it???


No, definitely not. You must be confusing something.
mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Why did you say " definitely not " ?
When I execute the codes that I sent,

System.out.println( trouser) represents baggy which is the object of the Size class type.

So CAn you explain your opinion???

Thanks,

Mert
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by mert �zkaya:
enum Size {narrow,baggy,wide,tight}; // instanstiating an object of enum class


No. This declares an enum class called size, and four instances of that enum which can be referenced through the constants narrow, baggy, wide and tight.




No object is copied here, only a reference. After that line of code, trouser2 will reference exactly the same object as trouser.

Briefly my questions is that how can we say narrow,baggy,wide,tight are objects. I think they are all variables.


They are constants each referencing a preinstanciated object. The objects themselves will per default be implemented so that getName() or toString() return the name of the constant, so it's just convenient convention to call them by the same names, too.

I agree that this can be somewhat confusing at the beginning. It's perhaps easier to understand when you take a look at how the above enum could have been implemented prior to Java 5:



The above is missing a lot of the details the Java 5 compiler will silently do for you, but it should give you a good idea about the basics...
mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Hi Gerrret,
Could you please test your Enum class for me ?
I wonder about it.

Thanks,

Mert
mert �zkaya
Ranch Hand

Joined: Jan 26, 2006
Posts: 33
Thank you very much. Now I think I totally understood the topic.

Regards,

Mert
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Tony Morris:
Speculation of course, but I just can't imagine that everybody at Sun is completely ignorant to what appears obvious - at least to me - avoid switch/case indiscriminately. On the flip side, I work for a large corporation on the J2SE spec. with a bunch of... er... "engineers" who wouldn't have half a clue about why switch/case is inherently flawed (total subscription to doctrine and not reasoning) - so it may just be a possibility within the Sun camp as well.


Apparently I am ignorant of this philosophy as well. I prefer switch case when I have multiple options to choose from. From my understanding it is optimized for these situations since it generates a jump (or the byte-code equivalent) directly to the code to execute. In contrast, a long if...else if...else chain has to check each option. In big-Oh notation, if..else is O(n) in the number of options where as switch/case is O(1).

Perhaps the flaw you are referring to is that each case requires a break statement to finish. This is easy to leave out, but if you use switch statements often enough, it becomes second nature. I usually type the break statement immediately after the case label then go back and put the code that does the work in between them. I don't find this much different than forgetting closing curly braces. Although, I guess the compiler will complain about a missing brace. So is there some other reason that switch/case is "inherently flawed?"

Layne
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Layne Lund:

So is there some other reason that switch/case is "inherently flawed?"


Yes.
Ignoring the potential O(n) lookup, which should be O(1) always (of course, there are cases where it is), it forces a client to a static expression of a strategy, which is always a poor abstraction. Depending on the given case, a switch/case can always be converted to an abstraction that more closely represents requirements since time moves and switch/case (and most other existing type-safe language constructs) assumes zero time, which of course is absurd (unless you travel at the speed of light relative to your software - good luck with that).

The biggest single issue of all time is retraining your mind which is perhaps contrary to intuition - the vulnerable mind has no problem with performing a similar analysis for themselves and deriving the same conclusion - at least, according to my ad hoc experiments. I say this because it should be emphasised that the biggest hurdle of all in this case (and many others) is non-technical in nature - merely, the ability to analyse objectively - for example, each time you state a premise to yourself, ask yourself again why that premise is plausible ("because Sun said so", "because everyone said so" - these are all common, but hopefully obviously flawed).

Back to the switch/case, I propose that for every time you consider using one, write yourself an interface instead. The interface will contain one method, with one parameter that is of the same type as the type that you would have otherwise used in the switch expression. The method will also have a return type, but this cannot be talked about for the general case. Merely, that it should be an appropriate abstraction for "whatever it is that you were going to do in your case blocks".

The implementation is not fixed - it may be O(1) seek, it may be backed by a Map, it may load the "strategy" (keyterm: Strategy Design Pattern) dynamically, for example, from an XML file, database or whatever. These are just some of the simple benefits - I have avoided digressing to requirements analysis, where it can be proven under a more formal axiom - one that is difficult to express using common language (or any language for that matter).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Layne Lund:
I prefer switch case when I have multiple options to choose from.


It depends. For type switches, it is often a good alternative to make use of a polymorphic method call.

In other instances, I prefer to use a Visitor - for the simple reason that the compiler than does tell me where I have to take care of the new case should another value get added to the enum.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
I agree with both Tony and Ilja that polymorphism can be used in many cases to perform the same task as a switch statement. However, I don't agree that this illustrates an "inherent flaw" in switch/case since if statements can be abused in the same manner. For example, using the instanceof operator to perform a cast and calling a method rather than refactoring to a common interface and a single polymorphic method call. In each case (if/else, switch/case, or a polymorphic method call), it seems that the programmer needs to use the correct tool for the job. I would claim that the flaw lies with the programmer not understanding the tools at hand and how to use them effectively.

Layne
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Originally posted by Tony Morris:
Back to the switch/case, I propose that for every time you consider using one, write yourself an interface instead. The interface will contain one method, with one parameter that is of the same type as the type that you would have otherwise used in the switch expression. The method will also have a return type, but this cannot be talked about for the general case. Merely, that it should be an appropriate abstraction for "whatever it is that you were going to do in your case blocks".
Abstraction is all very well, but at the end of the day you have to implement things. So would you like to have a go at implementing this advice for this switch/case block that I am guilty of writing?So far I have this:So now what? Do I write one class that implements that interface, or nine of them? And what goes in that class, or classes?
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

Abstraction is all very well, but at the end of the day you have to implement things. So would you like to have a go at implementing this advice for this switch/case block that I am guilty of writing?

Easy peasey - why don't you give it a burl, then reflect upon what you have done?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ENUM'S