Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After looking at the core data type for frameworks that deal with unstructured data in java:

the common theme seems to be that data are first de-serialized into Map, then transformed into an given class by reflection.
So this raises the question, why not just work with these Map (or sub-type of map) directly? You can extend Map and create your own sub-type, and you will still have all the benefit of OO programming.

Edit I am not concerned with the cost of deserialization, but the flexibility that Map offers when dealing with unstructured data. By this, I mean not having to define a class that the data can be deserialized into.
Edit 2 I am more interested in the "why not (disadvantages)", since the framework I mentioned already demonstrated that it could be done.

share|improve this question
It doesn't beg the question it raises the question. Begging the question is a logical fallacy in which one assumption depends on another being true that depends on the first being true. – Michael Brown Feb 21 '12 at 16:38
duly noted, updated accordingly. – ltfishie Feb 21 '12 at 17:16
up vote 6 down vote accepted

The convenience of working with a strongly typed object sometimes outweighs the cost of serializing to/from that object. For instance I usually use JSON to transmit MVVM ViewModels over the wire. Once the data is deserialized, I can take advantage of the functionality embedded in the ViewModel class that works on the data. If I were just passing around dumb data, then I agree it probably makes sense to forgo that extra step.

What is dumb data? To me dumb data is a class that has nothing on it but simple properties/fields and any logic is provided by other classes that consume them (cf. Anemic Domain Model or Data Transfer Object).

If instead you are (de)serializing intelligent objects (like my ViewModel example), there is much more to gain. This goes beyond just validation. If you look at the argument for Rich Domain Models versus Anemic Domain Models, the case is that we are putting the logic that operates on the data with the data itself. That's the entire point of using an Object Oriented language. Presumably you're passing the data around to have some function performed on it. Serialize it into a rich object and put the function on that object so all you have to do is invoke the function. I've touched on the idea in a blog post here.

share|improve this answer
Thanks for your answer. Can you expand on what you mean by "dumb data"? – ltfishie Feb 21 '12 at 17:22
Thanks for the update. So would unstructured data be the same as dumb data? Can you list some other gains besides validation? – ltfishie Feb 21 '12 at 18:00

... why not just work with these Map (or sub-type of map) directly? You can extend Map and create your own sub-type, and you will still have all the benefit of OO programming.

Good question. Why indeed? In dynamic OO languages (e.g. Ruby, LUA, Javascript, Python, Perl, and others) every object is basically just a map. You can add new properties and methods to objects at run-time. It's very powerful, but you give up compile-time validation of method calls. It's just not the Java way.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.