Page 1 of 1

Java 1.5 Enumerations Rate Topic: -----

#1 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3124
  • View blog
  • Posts: 19,168
  • Joined: 14-September 07

Posted 06 December 2008 - 04:16 PM

Enumerations in Java (1.5)

First a generic definition:

Enumeration- In computer programming, an enumerated type is a data type (usually user-defined) consisting of a set of named constants called enumerators. The act of creating an enumerated type defines an enumeration. When an identifier such as a variable is declared having an enumerated type, the variable can be assigned any of the enumerators as a value. If the programming language allows an enumerated type to be given a name, the name usually is chosen to collectively describe the enumerators in the set. The basic syntax for declaring an enum (generally in its own .java file) is as follows:


 public enum enumName
 {
        nameOne(parameters),
        nameTwo(parameters);
    
       private type dataMember; //public/private your choice
   
       //constructor
       private enumName(parameters)
       {
               this.param = param;
              //so on and so forth
        }

        //Accessor and mutator methods as needed
        public getDataMember()
        {
                return dataMember;
        }
 }




Before the enumeration update in java 1.5, enumerations had to be declared this way:

public final class SimpleSuit {

  /**
  * Enumeration elements are constructed once upon class loading.
  */
  public static final SimpleSuit CLUBS = new SimpleSuit ("Clubs");
  public static final SimpleSuit DIAMONDS = new SimpleSuit ("Diamonds");
  public static final SimpleSuit HEARTS = new SimpleSuit ("Hearts");
  public static final SimpleSuit SPADES = new SimpleSuit ("Spades");

  //so on and so forth
  void Draw(Image, x, y); //example of a method they all might share
}



It’s not the cleanest way to go about it, but up until the update of 1.5 this was really the only way to go about it. It did not give way to expandability or repeat/ease of use (my personal opinion). Accessing it in a program would typically look like this:

public static void main(String[] args)
{
	//code for card game or such
	if(curCard.Suit.equals(SimpleSuit.CLUBS))
		//take action based on suit
}



Depending on how much data an enum needs to hold this can get cumbersome. Let’s take a look of how this would be done in 1.5 enums:

public enum Suit
 {
 	CLUB
 	{
 		//specific card per suit would go here
	},
 	DIAMOND
 	{
 		//specific card per suit would go here

 	},
 	HEART
 	{
 		//specific card per suit would go here

 	},
 	SPADE
 	{
 		//specific card per suit would go here

 	};
 	//load images here
 	abstract void drawSymbol(Graphics g);
 }



I, for one, think this is much cleaner. Each enum is effectively its own “class” just like in previous iterations, but now it is a constructor with its own data types and functions. Unllike in C++, the enum is not related to an integer value. In fact, the compiler will complain if you try to do so:

public enum SUIT { CLUB = 1, HEART = 2, ...}; //etc...



Being a C++ guy, I was put off by this at first, but as I developed programs with them I really enjoy this method of enumeration. Which coincidentally, C++ 0x is implementing features similar to this java interpretation.


Since a Suit by itself doesn't have much value to us, here is a Rank enum that illustrates the concept of an enum effectively being a class of its own, as well as a complement to our already established Suit enum. (Rank and Suit go well together in a card game program):

public enum Rank
 {
 	TWO("2"),
 	THREE("3"),
 	FOUR("4"),
 	FIVE("5"),
 	SIX("6"),
 	SEVEN("7"),
 	EIGHT("8"),
 	NINE("9"),
 	TEN("10"),
 	JACK("J"),
 	QUEEN("Q"),
 	KING("K"),
 	ACE("A");

	public String symbol;
 	
 	private Rank(String symbol)
 	{
 		this.symbol = symbol;
 	}
 	
 	public String getSymbol()
 	{
 		return symbol;
 	}
}



This design is very OOP centric. Each enum is an object of which it has distinctions (I like to call them little enums), each with their own constructor and methods. This makes writing programs that utilize them very easy to do (once the framework is set up that is). If anything, that is the crux of having all these abilities with enums. It can be a pain to set up sometimes, but once it is up and fully functional, you’ll wonder how you ever programmed without it.

To bring what we have been learning to a culmination point, I present a generic Card class that utilizes both enums (and in and of itself can be utilized in a Deck class, etc…)

public class Card
 {
 	public Suit suit;
 	public Rank rank;
	
 	//constructor called to fill in Deck object
 	public Card(Suit suit, Rank rank)
 	{
 		this.suit = suit;

 		this.rank = rank;
 	}
 	
 	//access data
 	public Suit getSuit()
 	{
		return this.suit;
 	}
 	public Rank getRank()
 	{
 		return this.rank;
 	}	
 }



We have just encapsulated quite a bit of data into a “Card”, which, if you have 52 of, makes a Deck [of Cards] and then that can be used as an entity in a card game such as poker or blackjack. The idea is to simplify the process so the programmer [that’s you] can focus on the logic, flow, and direction of your program/code, rather then the framework; although the devil is in the details :) If you don’t appreciate this now, you may later on down the road. Happy coding!

--KYA


edited for a few typos

This post has been edited by KYA: 11 December 2008 - 07:45 AM


Is This A Good Question/Topic? 0
  • +

Page 1 of 1