Using an untyped wrapper class around objects stored in XML, is this bad?

Question

class MyThing {
    protected HashMap<String,Object> fields;

    protected MyThing(HashMap<String,Object> newFields){
        fields.putAll(newFields);
    }

    protected Object get(String key){
        return fields.get(key);
    }
}

Now a little background. I am using this class as a super class to a bunch of different classes which represent objects from an XML file. This is basically an implementation of an API wrapper and I am using this as an adapter between the parsed XML from an API and a database. Casting is delegated to the caller of the get method. If the subclasses need to do something when they are created or when they return a variable, they just call super and then manipulate what gets returned afterwards. eg.:

class Event extends MyThing {       
    public Event(HashMap<String,Object> newFields){
        super(newFields);

        // Removes anything after an @ symbol in returned data
        Pattern p = Pattern.compile("\\@.*$");
        Matcher m = p.matcher((String)fields.get("id"));
        boolean result = m.find();

        if (result)
            fields.put("id", m.replaceFirst(""));
        }
    }

    public Object get(String key){
        Object obj = super(key);

        if (key.equals("name")){
            return "Mr./Mrs. " + ((String)obj);
        }
    }
}

The reason I feel like I should do this is so I don't have to write getId, getName, getWhatever methods for every single subclass just because they have different attributes. It would save time and it is pretty self explanatory.

Now this is obviously "unJavalike" and more like a ducktyped language way of doing things, but is there a logical reason why I should absolutely not be doing this?

Answer 1

If you're going to this level of complexity and mucking up your object model just because you don't want to have getters and setters, do it in Groovy instead.

Groovy is a duck typed dynamic language on the JVM that accepts 98% of valid Java code, so you already know most of the language (you don't lose functionality)...there are "more idiomatic" ways of doing things, but you can pick those up with time. It also already has a built in XmlSlurper, which probably does most of what you're trying to do anyway.

As for the "reasons why you shouldn't", you're introducing all types of maintainability concerns.

1. New classes will always have to derive from the base class.
2. They will have to implement a constructor that always calls a base constructor
3. They will have to override get() [which you're basically using to encapsulate your getters and setters anyway, why not just add that method and delegate to those other methods] and write specific logic which is likely to degrade with time.

Why shouldn't you? It'll work, right? Sure. But it's poor engineering in that you're either creating a maintenance nightmare, or reinventing the wheel and likely to do it wrong.

Answer 2

1. Obviously, it's not type safe.
2. Future maintainers won't know what the types are supposed to be and will get generally confused as to why you're not using POJOs.
3. Instead of constant time, space complexity and performance you have the characteristics of a HashMap.
4. It become very difficult to write non-trivial getters/setters in future.
5. Most data binding systems are designed to work with POJOs/Beans (JAXB, JPA, Jackson, etc).

I'm sure there are more, but this will do. Try using some proper OXM libraries and you'll be much better off.