• 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

ENUM'S

 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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


 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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".
 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Enums can be used in switch statements. I think this is one of their most important functions.

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

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
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
mert �zkaya
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gerrret,
Could you please test your Enum class for me ?
I wonder about it.

Thanks,

Mert
 
mert �zkaya
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much. Now I think I totally understood the topic.

Regards,

Mert
 
Layne Lund
Ranch Hand
Posts: 3061
  • 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:
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • 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:
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic