Where Do I Store Hash Table or Dictionary Key Names

Question

When I'm working with Hash Tables/Dictionaries I sometimes struggle with how to specify keys.

For example: if I create a simple Dictionary (using Python for this example),

foo = {'bar': 'baz', 'foobar': 'foobaz' }

I can access values (in other modules) with the key values: (foo['bar']) and get baz back.

In the words of Dr. Evil, "pretty standard, really."

Unfortunately, using static strings for keys tightly couples any modules using this Dictionary to its implementation. Of course, this can also apply when using other key types (e.g. Enums, Objects, etc.); anyway you slice it, all modules which access the Dictionary need to know the values for the keys.

To resolve this, I typically use static constant string values (or Enums if available in the language) for keys, and either store them publicly in the local class/module, or in a separate module/class. Therefore any changes to the dictionary keys themselves are kept in a single location.

This usually looks like this:

BAR_KEY = 'bar'
foo[BAR_KEY] = 'foobar'

Are there better ways of specifying keys such that the use of the Dictionary doesn't necessarily couple a module/class to its implementation?

Note: I've seen a few responses in SO which address this (e.g. property-to-reference-a-key-value-pair-in-a-dictionary), but the topics didn't seem to address this issue specifically. The answers were helpful, but I'd like a wider range of experience.

Answer 1

Why not make a class for this, which only contains properties? This is done nicely with Python (from what I know), and works well with other languages, too. Refactoring the names is trivial with today's tools, too.

Answer 2

Personally, I use your method. It's pretty sensible, simple, and solves the actual problem.

Answer 3

I usually do the same thing; if the key is always going to be the same, make a 'constant static' in whatever language to hold the key.

Answer 4

I sometimes create a separate class to hold the dictionary keys. That gives them their own namespace, as well as the regular benefits of having the keys be in const strings, namely that you don't have the risk of typos, you get code completion, and the string value is easy to change. If you don't want to create a separate class, you get all of the benefits except a namespace just from have const strings.

That said, I think you're getting close to soft coding territory. If the keys in the dictionary change, it's OK for code using the dictionary to change.

Answer 5

In cases where I'm passing the object around and I've got known keys, I'd always prefer adding an attribute to an object. IMO, the use case of dictionaries is when you don't know what the keys are.

Python is trivial:

foo.bar=baz

Java is pretty much the same:

class Foo { public String bar="baz"; }

The Python performance would be pretty much identical, since a property lookup is just a dictionary lookup and the Java performance would be better.