What are the design problems in returning a hashtable from a public method when you want to return multiple items instead of creating a class and returning object of that?

If it does have problems then under what circumstances it makes sense to do so?

How does the answer to this question change depending upon whether the language is dynamic or not?

Edit: This is to clarify that the keys would be constant and are part of code, not data. Something that we typically create a class for. The question is why would it be wrong to use hashtable instead if creating a class indeed does seem to be the right choice.

4 Answers 4


Use a better defined class as a return type than a hashtable which holds arbitrary number of values as name/value pairs.

  1. The first and fore most important point is - Maintainability. By looking at the code, a new programmer can never say what are the values the method is returning. If a new person does not understand this by looking at the code, the code is not going to be useful and prone to errors whenever someone is going to add more key/values to that data or enhance the application.

  2. Methods are contracts between the caller and the service. The most important thing in a method is their input and output. This input and output should be easily readable and understandable and self documenting. If you use a Person class as a return value which has first name, last name, age -- It is self documenting. If you generate a Javadoc for this , user can navigate between the classes to understand this better. If you use a hashtable, you have to either explain it in the comments which no one will read or update when things change.

  3. You can't use generics like HashMap<String,String> in case if you want to add a number (say age) to the return statement. If you don't use generics , then you will have to cast back and forth between the object to actual type. You may save this if you use dynamic typing.

  4. Also there are more chances of runtime failure than catching issues in compile time. e.g if someone deletes an entry from the hashmap and one of the old callers is expecting the entry, client fails during runtime. It is always better to catch this issue in compile time.

  5. It will be difficult to return a immutable type if you want to use hashmap as return type and so on. But if you use a user defined your own type, you can control this.

It will be tempting to use a hashmap as return type because you can avoid creating couple of classes at the beginning but it will be a nightmare to maintain the code in the future. Go object oriented !!!!

  • 1
    You seem to have understood the question correctly. Thanks. Commented Jan 31, 2012 at 19:52

One of the problems would be that in many cases, the key for the hash table would be a string. So the consumers of the method would have to know before hand which keys to use to extract the data. This would give the potential for errors due to mispellings when accessing the data.

Another drawback is refactorability. If you decide later on to change the name of a member, you then have a bunch of magic strings that also need to change. It's a lot simpler to rename a class member using refactoring tools provided by most good IDE's. With a hash table you'd likely have to do a find/replace operation across all source files which could be problematic.

Lastly, you will lose compile time checking of the member access - both in terms of name and type. The latter is not such a problem if your hash table only contains one type of obejct, but if it contains many (even in the same hierarchy chain) you really want to leverage the type system of your language and get compile time checking there. In most IDE's you'll have some kind of intellisense/autocomplete features - these work by looking at the type system, but they wont be able to help you with hash table keys.

As for times when it would be appropriate to return a hash table (or other such collection of key value pairs), you would use this when both the values and the keys are not known at compile time. For example, if you have a method which parses a query string and returns the keys & corresponding values, a hash table would be a good choice. In this case you would also want to think about returning some kind of immutable or readonly hash table.

Edit - Most of the points raised in this answer cease to apply when you're talking about dynamic languages :)

  • What if the language is dynamic? Commented Jan 31, 2012 at 11:59
  • I'm not an expert in dynamic languages so someone else can probably provide a better answer for that. But I do know that dynamic languages don't do compile time type checking anyway. But in that case returning an object and returning a hash table aren't so dissimilar..
    – MattDavey
    Commented Jan 31, 2012 at 12:05
  • 3
    @Hasan Khan: In that case there may actually not be any difference between a hashtable and a class instance. For example, in Javascript all objects are hashtables, and object.property is exactly the same thing as object['property'] Commented Jan 31, 2012 at 13:35
  • “With a hash table you'd likely have to do a find/replace operation across all source files which could be problematic.” Only if you've chosen poor keys and never tried to factor out the standard ones so that they're defined in one place… Commented Jan 31, 2012 at 15:16

The most important argument against this would be that you are exposing too much information to the consumer. The consuming code only needs to know that it's a key-value collection (dictionary) of some sort; whether it's implemented as a hashmap, an association list, a trie, or whatever, is relatively uninteresting. So the proper way would be to return by a suitable interface (IDictionary, or whatever your language of choice uses) instead of by actual type.

All this assuming that you actually need a dictionary to represent your data, that is, your data consists of key/value pairs, where the keys are unique among the dataset, and cannot be fixed at compile time. If you have pre-known keys, you should be creating a proper type (or several, as required) for your data. It comes down to whether you regard the keys themselves as part of the data, or part of the code.


To clarify, I'm using the term dictionary to mean the most generic type of key-value data structure here; I don't mean any language-specific implementation such as Python's dict or .NET's Dictionary.

  • 1
    +1 for "It comes down to whether you regard the keys themselves as part of the data, or part of the code." - That's a good way to put it. Not sure how universal the term 'dictionary' is as opposed to 'map' for example.
    – MattDavey
    Commented Jan 31, 2012 at 12:16
  • Returning the dictionary wasn't intended. keys were part of code not data. Commented Jan 31, 2012 at 15:25
  • The real question is the reasoning behind 'You should be creating a proper type'. Question is why? Commented Jan 31, 2012 at 15:59

One question I'd ask myself is "are the keys changing in this dictionary?" If they are constant then you should return an object or other appropriate data structure. If they are dynamic then you might want to return some sort of dictionary style structure. Finally, if there are some keys that are going to be constant and some unknown set of dynamic keys, you might wish to return a hybrid data structure including some fixed values and some sort of dictionary for the overflow.

  • Indeed your advice is correct but the question is what is wrong with chosing to use hashtable when class is a better choice. Commented Jan 31, 2012 at 15:29
  • It isn't either / or; a class can easily contain dictionary if you need it. Commented Jan 31, 2012 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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