Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are there any situations where having a "data model" in which all of the entities are instances of a Map<String, Object> would make any sense?

How do you explain to someone why having such a "data model" is not such a good idea? It seems like it's an absurd approach to me, could I be missing something?

share|improve this question
2  
It does seem odd, but no-one can answer until we hear what were the considerations for choosing to model your entities as maps. Maybe they make sense, who knows? (Probably not, but we need more info!) –  Andres F. May 18 '12 at 12:27
1  
-1 for not explaining what is specifically "absurd" –  gnat May 18 '12 at 15:28
1  
when you are creating a cache implementation ? –  NimChimpsky Jun 6 '12 at 10:14
    
It smells of object denial. –  Joachim Sauer Jun 6 '12 at 10:15
2  
Basically, that's how objects in JavaScript work (plus prototype-based inheritance). In Java, I assume this to be an example of the en.wikipedia.org/wiki/Inner-platform_effect –  user281377 Jun 6 '12 at 11:28
show 3 more comments

4 Answers

It isn't necessarily a bad idea to have a data model that's a map of key strings to values. However it often is a good idea to abstract that behind something domain specific, both to give some meaning to the strings and objects and to offer somewhere to impose any constraints that aren't evident from the underlying data structures.

share|improve this answer
add comment

If you're mapping Maps then sure. But generally you want to ask what is it a Map of that you're modelling? A Map of Cats? a Map of Nodes? etc.

share|improve this answer
add comment

Well few examples I found are:

  • in Apache Camel documentation for CSV data format
    Map<String, Object> body = new HashMap<String, Object>(); //...
  • in Atlassian Java cookbook, Converting a Map to JSON
    Map<String, Object> data = new HashMap<String, Object>(); //...
  • in Spring JDBC API, queryForMap API docs
    Map<String,Object> queryForMap(String sql, Object... args) //...

The way I see it, it boils down to a pretty simple question.

1234 - what type is it? is it... Integer? or String, or Long, or maybe, Double?

When there is a context one can learn about semantics of the data, above question is easy to answer. But what if there is no such context? this seem to be pretty common case in data passing frameworks.

Imagine writing a library that passes data from various sources to different consumers. One source can pass 1234 as String, another as Integer - you just have no reason to prefer one over another. As for the consumers, they "know" what type they expect from particular source, but why would they "tell" you?

If you slavishly follow the never an Object dogma, you might be tempted to arbitrarily cast everything to some type you just happen to prefer, like say String. The problem is though, this will make your library harder for clients to understand, not easier - they will break their mind trying to figure why did you use that type and what could be consequences.

Why String? I plan to plug data source that passes Double, what will happen? Will you convert? or will you break? Also, my consumer expects Double, does that mean I have to convert back? by the way how do you convert - does locale matter? Oh and another thing, in my other module I plan to use data source that passes Long and consumer that expects Long, too - could there be problems with that?

I did not use CSV, JDBC, JSON libraries mentioned in examples below, but in one of my past projects there has been Map<String, Object> used in a proprietary data passing framework and have to admit, as its client I've got nothing to complain against.

One interesting thing I noticed about that proprietary framework is that they did not intrude their untyped Objects into my client code. They exposed data through some API layer that presented it to me using the types I needed.

Actually I only learned about Map<String, Object> through one auxiliary "escape hatch" method in their API. I don't remember if method javadocs explicitly mentioned that it is for debugging purposes, but that was my understanding of why it's there.

If I mis-configure data source so that it passes String where I expect Integer, I would prefer to test the Object that is being passed under the hood instead of staring at cryptic ClassCastException. For that, I'd use "escape hatch" API.


Summing up, (1) I can imagine a library where using untyped Object makes better sense than pulling arbitrary type out of thin air and (2) at client code, I'd be be OK with that library as long as (2a) library API presents data with needed type and (2b) there is a convenient way to debug stuff when things go wrong.

share|improve this answer
add comment

Using a Map<String, Object> container means storing pairs <key,value> in which the key can NOT appear twice, whereas the value could reappear.

Designing a class whose objects would be instances of the above-mentioned map would make your class a container of containers. I don't think there would be a problem with this, but I personally wouldn't use it because I don't want to get stuck in using too many pointers and references. Keep it clean and simple!

share|improve this answer
add comment

Your Answer

 
discard

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.