variable number of fields with different types

[Sir G.]

I need to create a class which offers a variable amount of fields. These fields might be String or int.

Example:

myObject1 might have as fields:
description - String
idNumber - int
authorName - String

myObject2 might contain
description - String
idNumber - int
authorName - String
year - int

myObject1 and myObject2 should be objects of the same class.
This needs to be completely transparant. I should be able to get the values using:

myObject.getValue("description") ... which should return a string
myObject.getValue("year") ...which should return an integer

I assume the underlying datastructure should have a hashmap-like structure, so I can map the name of the field to it's value, however, I seem to be unable to figure out how let getValue return an String in the first case, and an Integer in the second.

note that I do not want to return Object. I want to have a clear distinction between String or integer. I have no clue which fields might occur, or how many string-fields or int-fields it might have.

any help would be appreciated.
Thanks

[JosAH]

I need to create a class which offers a variable amount of fields. These fields might be String or int.

Example:

myObject1 might have as fields:
description - String
idNumber - int
authorName - String

myObject2 might contain
description - String
idNumber - int
authorName - String
year - int

myObject1 and myObject2 should be objects of the same class.
This needs to be completely transparant. I should be able to get the values using:

myObject.getValue("description") ... which should return a string
myObject.getValue("year") ...which should return an integer

I assume the underlying datastructure should have a hashmap-like structure, so I can map the name of the field to it's value, however, I seem to be unable to figure out how let getValue return an String in the first case, and an Integer in the second.

note that I do not want to return Object. I want to have a clear distinction between String or integer. I have no clue which fields might occur, or how many string-fields or int-fields it might have.

any help would be appreciated.
Thanks

Have two maps, one for the String type 'variables' and one for the Integer type 'variables'?

kind regards,

Jos

[Sir G.]

that would leave me with two inspectors (one for each map), one returning ints, the other strings.

I would like to make it completely transparant that I have two maps. I would like only one inspector getValue(key) that would return an integer if key is the name of a field that holds an integer and return a string when the key is the name of a string-type field.

The only way I see of doing that directly would be like this:

public [B]Object[/B] getValue(String key){
      if (stringmap.containsKey(key))
              return stringmap.get(key);
      else
              return intmap.get(key);
}

But, like I mentioned above, I don't want to return objects.
So I'm guessing I'm in the need of some sort of generics/inheritance/polymorphism-trick I fail to see.

[JosAH]

I would like to make it completely transparant that I have two maps. I would like only one inspector getValue(key) that would return an integer if key is the name of a field that holds an integer and return a string when the key is the name of a string-type field.

The only thing in common of a String type and an Integer type is an Object type but you don't want that and a method can only return one type (if not a void method). Using exceptions for one of the types is ugly and not done. Defining a class like this:

public class ReturnType {
   public Integer intReturn;
   public String stringReturn;
}

is clumsy at best because the receiver of such an object still has to inspect the members of that object in order to determine the actual type of the original return value.

kind regards,

Jos

[Sir G.]

The only thing in common of a String type and an Integer type is an Object type but you don't want that and a method can only return one type (if not a void method). Using exceptions for one of the types is ugly and not done.

kind regards,

Jos

I am fully aware of that. I do not intend to use exceptions in any way. I have been looking for solutions using generics, inheritance and overriding or even the creational design patterns of the Gang of Four. I have always encountered a dead end. I am starting to belief there is no way of pulling this of in java (in a clean way). Can you confirm that?

If so, I will probably stick to two seperate inspectors. This will render the interface less simple, since all classes using this class will have to develop logic to know which inspector to use..

Thanks

[JosAH]

I am fully aware of that. I do not intend to use exceptions in any way. I have been looking for solutions using generics, inheritance and overriding or even the creational design patterns of the Gang of Four. I have always encountered a dead end. I am starting to belief there is no way of pulling this of in java (in a clean way). Can you confirm that?

Not yet ;-) A caller of your String/Integer map has to either process an Integer or a String; define an interface for it:

public interface Processor {
   public void processInteger(Integer theValue);
   public void processString(String theValue);
}

have your calling class(es) implement this interface and define a getter in your Integer/String map class like this:

public boolean get(String key, Processor p) {
   Object theValue= map.get(key);
   if (theValue == null) return false; // nothing found
   if (theValue instanceof String) p.processString((String)theValue);
   else p.processInteger((Integer)theValue);
   return true; // signal that something was found
}

All the nasty casting is done in your map-class. Does that help you out a bit?

kind regards,

Jos

[Sir G.]

That might be a solution. Thank you very much.

[JosAH]

That might be a solution. Thank you very much.

You're welcome. The solution I proposed is called "double dispatch" or "visitor" in the GoF book.

kind regards,

Jos

[Sir G.]

Ah, visitor. I'll have to reread that one. I'll look it up right away. Thanks.

[pbrockway2]

Also posted at bytes.com.

@SirG: Could you please alert people if you must do this? (Ie, could you link from each part of the discussion to the others?). See, for instance, JavaRanch's guidelines.

[Sir G.]

ofcourse, will do

[pbrockway2]

Thanks for that.