Logo 
Search:

Java Forum

Ask Question   UnAnswered
Home » Forum » Java       RSS Feeds

why they chose to use int parameters for some classes in java to pass in variable options for m

  Asked By: Ella    Date: Dec 05    Category: Java    Views: 679
  

I've been wondering for quite some time now why they chose to use int
parameters for some classes in java to pass in variable options for
methods, say for instance JOptionPane's method showConfirmDialog
where the 4th parameter is of type int and you have to pass in one of
the static JOptionPane member variables to call that method. Why
wouldn't they create some type of internal class that can handle
these situations in what seems to me a more logical way. I've created
2 test classes, Test and it's test driver Test2, to show what I'm
thinking. Test is a class that needs a parameter passed into the
constructor that is one of it's static member variables, but I'm
choosing to use an instance of a static private class for that
variable instead of an int. Is there something that I'm missing that
wouldn't make this a better approach? Any comments would be
interesting because it's just basically a pondering of mine.

public class Test{
public static ConsoleType GUI = new ConsoleType(1);
public static ConsoleType CONSOLE = new ConsoleType(2);

Test(ConsoleType init){
if(init.equals(Test.GUI))
System.out.println("gui");
else
System.out.println("console");
}

private static class ConsoleType{
private int number;

ConsoleType(int number){
this.number = number;
}

public boolean equals(Object test){
if(test instanceof ConsoleType && this.number ==
((ConsoleType) test).number)
return true;
else
return false;
}
}
}

public class Test2{
public static void main(String args[]){
Test myTest = new Test(Test.CONSOLE);
}
}

Share: 

 

4 Answers Found

 
Answer #1    Answered By: Percy Morgan     Answered On: Dec 05

I think that the main reason is laziness. Personally I prefer a system similar
to what you describe. Here is an example:

public final class  ConsoleType{

public static  final int  GUI_TYPE = 1;
public static final int CONSOLE_TYPE = 2;

public static final ConsoleType GUI = new ConsoleType(GUI_TYPE);
public static final ConsoleType CONSOLE = new ConsoleType(CONSOLE);

private static final HashMap typeToStringMap = new HashMap();
static{
typeToStringMap.put(GUI, "GUI");
typeToStringMap.put(CONSOLE, "Console");
}

private int value = -1;

private ConsoleType(int value){
this.value = value;
}

public int getValue(){
return value;
}

public String toString(){
return (String)typeToStringMap.get(this);
}

}


The nice thing about this "type" class is that:

a.) you can not create  unknown types because you cannot directly instantiate
the class
b.) you still have access to an int value and constant representations so you
can do switch statements:

switch(type.getValue()){
case ConsoleType.GUI_TYPE:
// do something
break;
case ConsoleType.CONSOLE_TYPE:
// do something else
break;
default:
throw new IllegalArgumentException("Invalid type: " + type);
}


But as you can see creating these types of classes  does take more effort than
just passing an int.

 
Answer #2    Answered By: Aaron Kennedy     Answered On: Dec 05

There was a small typo in my example.

public static  final ConsoleType CONSOLE = new ConsoleType(CONSOLE);

Should read:

public static final ConsoleType CONSOLE = new ConsoleType(CONSOLE_TYPE);

 
Answer #3    Answered By: Ana Silva     Answered On: Dec 05

Well, it costs resources to instanciate a class, and then later garbage
collect it... an int  wont cost the same ammount of resources as a class  do.

Of course... resource usage and clarity of the API are sometimes two
opposite factors that needs to be delicately balanced between.

 
Answer #4    Answered By: Dustin Dean     Answered On: Dec 05

You are absolutely correct, there is almost always a tradeoff between resource
usage and clarity of an API. My personal opinion is to get clarity first and
then deal with performance. Often I have found that focusing on the clarity of
code first results a system which naturally performs well enough. If it doesn't
you can always go back and refactor.

 




Tagged: