Should I use a Map instead of a class for creating a flexible object?

Question

public class Person
{
    protected Map<String, String> data;

    public String getString(String key)
    {
        return getData().get(key);
    }

    public void setString(String key, String val)
    {
        getData().put(key, val);
    }
}

I want a flexible object that could change and have new fields eventually, or fields eventually go unused based on a users needs.

Say at first the user just needs the basic fields: Name, Age, Height.

But later on another user needs to capture: Hair Color, Eye Color, & Ethnicity, on top of the already used fields

Would using a String, String map be viable?

I could create all the fields

int age;
int height;
String name;
String eyeColor;
...

But my "Person" could only extend so far with just these fields. Not sure what the best practice is for this, or if the string map is the route go. Any insight would be appreciated.

Well the project is a crud application that is used for insurance purposes. Each branch company stores drivers differently and uses driver information differently, as what data fields are captured and what are not. Some capture how many accidents someone has been in, some do not. Some require years driving, and a driver grade, while some do not. I wasn't sure the best design practice to make a flexible object, that extends to the cases of each branch company, without creating multiple driver extended objects, because everytime a new carrier comes in, i need a new object for their needs

Using:

Java JSP/Struts2 MySQL as DB.

Answer 1

What you are probably doing is making a very common mistake, although there are narrow circumstances under which you could be right.

You perceive that creating a new class is adding complexity and overhead to your application and avoiding creating one is going to make it simpler. This may not be the case, and quite possibly will be the opposite. Classes are there to make life easier: that is why they were invented.

If these fields that you need to add for each branch company require you to write logic that uses them, then you are going to have to extract these fields from the map and put them in a variable and then write some logic to manipulate them. As you don't have a class, you won't have any way of encapsulating that logic (if it makes sense to do so). You will have no way of typing the field (is it a number, a string or a boolean). You won't have any way of knowing whether the Map contains the field other than explicitly checking it. You will have no easy way of seeing what type of map it is. You will have to convert everything.

For example, imagine you need to add an "age" field to your class for a branch. In Java, you create a class for that branch, add an int field and then write your logic for it. You can also use various OO techniques for handling similar classes (e.g., create an interface with getAge() method).

Also, don't assume that extending a class is always the right method of adding extra data. Sometimes having an attached class or classes with associated data is a better approach.

In the Map language you get the String, check if it is there (it might be null) convert it to an int, handle the possible parse exception. All this logic has to float around in some utility class or helper of some sort. It will look awful and you have your temporary int anyway plus you might end up with a helper for the branch logic, which is a class anyway.

The case where your Map might be appropriate is if you are simply just displaying the properties on a screen without doing any logic. In that case, it might be that it is easiest just to use name-value pairs (the general pattern for what you are doing) and write some general logic that can display anything.

Another factor influencing your choice is whether the object is persisted using some Hibernate type thing. If this is the case, then having multiple classes will tend to lead to more database tables (although it can be avoided). This might be good or bad. It will be more complicated for the DBA, but on the other hand, it will be much easier to view and search on branch specific data if it is in proper tables rather than some NVP structure.

In summary: don't assume a solution with more classes is more complicated.