Class Object vs Hashmap

Question

Is it good to use hashmap instead of using the object class...... Using Hashmap....

Map<String, String> cellMap = new HashMap<String, String>(); int j = 0; while (cellIter.hasNext())  {    HSSFCell myCell = (HSSFCell) cellIter.next();    cellMap.put(columnMap[j], myCell.toString());    j++; } 

And using object class.....

ABC abc= new ABC();  abc.setA(myRow.getCell(0).toString()); abc.setB(myRow.getCell(1).toString()); abc.setC(myRow.getCell(2).toString()); 

Please tell me in the context of application health, memory requirement etc ...

Answer 1

An object has fields (data) and methods (behaviour). If your data consists in a fixed set of cells (A, B and C), then definitely use an object.

Java is an OO object, and OO design, encapsulation etc. are there to help you build robust, maintainable and fast programs.

A Map is useful when you must associate a variable number of keys and values. But it's simply a data structure, and doesn't allow you to encapsulate additional behavior.

For example, you might have a getAAndB() method in your object that returns A concatenated with B. Or you might have methods to transform or query the fields. Or you could pass ABC instances to other objects that make use of them. Using an object ABD with well-defined methods is much easier than using a Map<String, String>. What are the keys of the map? What are their values? Where is it documented? What if you want to change the keys? How will you detect all the places in the code where these keys are used?

Answer 2

This depends a lot on what you are trying to achieve: for flexibility, hash map is better. But the flexibility comes at a price: hash map is also larger and slower than a class with the identical number of strongly-typed fields.

• Hash map has larger memory footprint than a class with identical number of fields
• Hash map forces boxing on primitives
• Hash map is slower to create and access

There is also an impact on readability: when you business logic is specific to a class with a fixed number of fields, a special-purpose class clearly wins; when the fields are configured dynamically, hash table is your only option. You could also have a hybrid design, when an object uses a hash map for its storage internally, presents nicely named fields externally, and exposes semantics to add more "fields" as you go.

To summarize, before you decide to go with a hash map for its flexibility, you should decide if you really need all that flexibility in your design. Sometimes, the answer is "yes", and sometimes it is "no"; there is no "one size fits all" solution to this.