Typesafe registry of key-value pairs

Have you ever seen or used this pattern of code:

Map attributes = getAttributes(); Object value = attributes.get("attr.key"); if (value instanceof SomeType) { SomeType typedValue = (SomeType) value; // do something useful with the value }
I've seen the above code and many variations of this pattern scattered all over the various java code bases I've read and it has always nagged me that although we have had the power of generics and the associated type-safety guarantees available at our fingertips for a long time now, this type of general registries of key-value pairs still involve this type of cast-heavy boilerplate.

It stroke me then how often I have I seen just this pattern appear and re-appear so many times that I have all but stopped thinking about it.- "Of course, if you need an extensible registry of values, you use a Map of key-value pairs (or a Dictionary)".

And usually you either engineer your registry around same type of objects or you throw the generic typesafety out with a proverbial bathwater and map your keys (usually of the type String) to values of type, well .. Object.

Would'nt it be nice if we could actually make key-value pairs themselves be type-safe?
One day I got thinking, what would be needed to make this possible.

Given the following general interface:
 
public interface Registry { public interface Key { T getValueType(); } V put(Key key, V value); V get(Key key); }

We could re-write the snippet in the beginning as follows:
Registry registry = getAttributes(); SomeType value = registry.get(Keys.ATTR_KEY); if (value != null) { // do something with the value }

Although the difference is not all that huge, the last snippet looks much cleaner and the meaning is much easier to read and understand.

Also, as I've learned to associate explicit type casts with a potential code smell, the latter snippet has a much cleaner feel to it. I know exactly what type of the value I am getting from the registry and the API contract ensures that I will always get the type of the value I am asking for.

To test out this idea, I've started a little project on GitHub. Check it out and let me know what you think...

Comments

Post a Comment

Popular posts from this blog

Musings about build systems

I was just hacking the other day our somewhat horrible hairball of an ant build to try to mold it to my understanding of how a build should work when I had a sort of an epiphany about why on earth I dislike Ant so much. Apart from the syntax (and I think it is universally agreed by now, that XML is a horrible, horrible language for scripting like tasks), what hit me is that while ant is okay for simple one-shot single project builds, it really falls on it's knees as soon as you start building complex modularized systems where you need some sort of dependency management. Now, before I go on, I must mention that I have heard of alternatives like make, Maven , Buckminster , b3 and the ilk, but I really don't know much about any of those (well, by the time I started to write this piece, I had taken a peek at Buckminster). I am not really what you would call a "build person" - I'm using Ant, because it's what comes with most of the projects I've been invol
Read more

Comparing Jenkins vs TeamCity - Part 2

Image
This is a second installment in a series of posts that tries to compare two continuous integration and build automation server products. In my previous post I briefly introduced the contenders open source developed Jenkins and a commercial offering from JetBrains called TeamCity and compared their respective installation experience. This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them. Configuration No server software is usually useful out of the box in and by itself. You almost always need to tweak and configure it before you can really reap the benefits. Continuous integration is just another type of server and it needs to be configured before it becomes really useful. TeamCity After you've installed your copy of TeamCity and opened up it's web interface for the first time, it greets you with a nice little license agreement, you need to agree to in order to be able to continue.
Read more

Comparing Jenkins vs TeamCity - Part 1

As some of my closest friends already know, I decided to bite the bullet and switched jobs recently. As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming. One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product. Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product. The next alternative I had had any exposure to was Hudson ( now renamed to Jenkins ) and JetBrains's TeamCity , which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild. I settled on Jenkins and TeamCity as the two major contenders. I would like to point out that this post is ful
Read more