Author Archives: Eric Gregory

There’s a common anti-pattern in software design that I call “association by hash map.” Rather than explain this in words, let me illustrate it in Vala:

HashMap<MyClass, string> name_map =
    new HashMap<MyClass, string>();

name_map.set(an_object, "Foo");
name_map.set(another_object, "Bar");

stdout.printf("an_object's name is %s\n",
    name_map.get(an_object));

“But wait,” you’re saying, “Couldn’t we just add a name field to MyClass and remove the hash map?”

YES! That is exactly what you should do — if you can.

But what if you can’t?  Adding a field isn’t always an option.  Perhaps MyClass is someone else’s API.  Or even if it’s contained entirely in your code, the name field might only make sense for a single use-case.  No reason to add an extra field to your class if it doesn’t truly belong there.

So what to do? Is there a better way? If your class is based on GObject, you’re in luck.

During a recent code review, Jim pointed out to me that GObject has methods for attaching arbitrary named data to an object.  In our example, we can use the simplest of these methods, gobject_set_data() and gobject_get_data() which use simple key/value pairs.

const string NAME_PROP = "name";

an_object.set_data(NAME_PROP, "Foo");
another_object.set_data(NAME_PROP, "Bar");

stdout.printf("an_object's name is %s\n",
    an_object.get_data(NAME_PROP));

Isn’t that better?  No more extraneous hash maps, all the data is stored right in the object itself where it belongs.  And you didn’t even have to modify the class!

In closing, if you’ve dealt with the association by hash map pattern before you now know a way to avoid it with GObject.  And if you haven’t, I envy you.