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

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.

Answer 2

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 3

You should see this as a "design" issue before performance. No need to do upfront premature optimization in favour of good design. So, the question is: "do you need to go through an intermediary collection to populate your domain object ABC?" In most cases I wouldn't do it but it's hard to say a definitive yes or a definitive no without knowing the larger context.

UPDATE: 30-40K: Number of records is irrelevant for the Object vs HashMap comparison because they're going to be handled in a loop (disclaimer: irrelevant in terms of design not in terms of performance). However the number of columns in your spreadsheet is important as this is going to be reflected directly as the number of attributes in your object.

If this is just a data migration or data transfer exercise then I'd go with the HashMap approach. Assuming that ABC will be a short-lived, throwaway data container object without behaviour, there's no need to create it. Then I'd test the performance of the system and if it doesn't satisfy the acceptance criteria then I'd profile it and optimize it only if necessary.