"Value" member field can be one of four different types - best design?

Question

I have a class called "DataModel" or something, which is basically a unit of data which can be either a string or a number or a date or a boolean with various (identical) attributes.

What is the best way to write this model?

1. Have the value be of type Object

   interface DataModel {
      Object getValue();  // cast to whatever is needed
      int getValueType(); // uses four constants
   }
   

2. Have four different implementations "StringModel", "NumberModel", etc., each with their own typed "getValue()" method. This means if you had a DataModel, you'd have to cast to the correct Model to get to the value.

   interface DataModel {
      int getValueType();
   }
   interface NumberDataModel extends DataModel {
     Integer getValue();
   }
   ...
   

3. Have four different methods, each throwing an exception if called for a wrong value type:

   interface DataModel {
     String getStringValue();
     Integer getIntegerValue();
     ...
     int getValueType();
   }
   

4. Use generics. This has the downside that I theoretically could have any object of any type...on the other hand I could just throw an IllegalStateException in the constructor if T was not one of the 4 allowed types...

   interface DataModel<T> {
     T getValue();
   }
   

5. It doesn't matter. Any of the above. ;)

Answer 1

4 seems the best - even if you don't want to implement any old type there's no particular reason why you shouldn't theoretically allow it - it won't interfere with anything else you're doing.

Answer 2

1 is fine if you don't plan to add many/any new types AND you don't need to allow 3rd parties to add their own types. I would probably use an enum rather than an int.

I don't see much advantage of doing 2 over 4. 4 is generic, tho you may want to include the getValueType() even in the generic case so that you can have code interrogate the type at runtime, often useful.

I don't think 3 is the right way to go unless the content of your model supports being retrieved in different ways (like JDBC does somewhat) but I don't think that is the case here.

From past experience I would do 4 and add the getValueType() to it.

Answer 3

None of the above.

Since you need to know the class to do something sensible with the result of getValue(), there is nothing to be gained from having a common interface containing getValue()-like methods in this case.

Have a base class with the common parts, then subclass and add what you need. You can use instanceof instead of having getValueType(), but if you really want a getValueType, it can be added to the base class as an abstract method. If you go with the getValueType, i'd suggest it returns an enum, not int.

Answer 4

4 is the best answer. You'll get flexibility and convenience.

On the other hand, if you really want to restrict the type, you can do with combination of 4 and 2. Like this:

interface DataModel<T> {
   T getValue();
}
interface NumberDataModel extends DataModel<Number> {
   // empty
}
class NDM implements NumberDataModel {
   Number getValue() { return ... }
}

Then you can make the DataModel interface protected/default.

Answer 5

As a generic alternative, you can use Class Literals as Runtime-Type Tokens and use newInstance() to get type-safe instances of your data elements. This allows compile-time checking via generic parameters and runtime checking via isAssignableFrom().