Registering Primitives in the Spring Container

I just got back from attending EKON 19 in Köln, Germany. I had a really good time and learned a lot. In fact, I learned the most in one of the sessions I gave – a three hour workshop on Dependency Injection.  Stefan Glienke was there – he maintains and enhances the Spring Framework – and he showed me something that the Spring Container can do that I didn’t know it could do — resolve primitive values by name and an anonymous method.

Here’s how this works.  First, we’ll take a look at a simple class:

This is a simple class — so simple that I won’t bother showing you the implementation, which I know you can figure out.

What is cool, however, is that you can inject both Name and Age properties.  I’ll demo one as a constructor-injected parameter, and the other as a field-injected value.

First, we’ll register the Name property.  We’ll get the name property using the following function that gets the user’s Windows Name:

This is just a wrapper around the Windows API call GetUserName.  The real fun is here:

First, we register the TPerson class so that the container can resolve things for it. Then we register a string with the name ‘name’, and delegate its “construction” to an anonymous function that calls our GetLocalUserName function. The point here is that we now have a “handle” – the string ‘name’ – to a string value that can resolve at runtime. We do the very same thing for the FAge field. That might seem like over-controlling things, but in effect it is quite powerful.  We can use it to ensure that both interface and primitive values in a class are resolved with the Container.  Imagine a constructor that requires not only interface dependencies, but a string value as well.  You can let the container resolve the values for the entire class.

Now, all we need to do is to change the above class to have these attributes:

Now, the Name property of the TPerson class will automatically be filled with the Windows user name without actually writing any more code to make it do that. The FAge field will be set with our favorite number ’42’.

(The code for this application can be found here.)

Now, at this point I bet you are asking “Why would I do that?”

It does, on the surface, seem like a bit of overkill.  But, in the world of Dependency Injection, being able to resolve all the dependencies of a given class – interfaces, classes, and primitives  — is golden.  Not having to write code, and centralizing the resolution of constructor parameters, properties, and fields –no matter what the type — are very useful indeed.  Remember, the more you can decouple your code via the Container, the better.

And you don’t even need but the one call to the ServiceLocator.

Flotsam and Jetsam #104

  • Stefan chastises me for making another one of my pronouncements on “evil” programming techniques.  I admit to a bit of hyperbole, but it’s not without a point.  The argument against my pronouncements is that the wise and judicious use of these so-called “evil” features or techniques is good.  I don’t agree.  I think that if a “feature” has the ability to be *easily* abused, then it should be avoided.  For instance, some make the argument that there places where the with statement makes sense.  Well, my counter argument to that is if you allow the with statement in a few places, it’s very easy to use it in just a few more places, and then the next thing you know, your code is full of with statements.  It’s a slippery slope that you should never start down.  The same is true for nested procedures.  Sure, there might be places where they “make sense”, but if you allow them in one place, what is to stop a junior programmer from getting the wrong idea and go crazy with them?  This is especially true for features that simply need not be used at all – such as with and nested procedures.  You can write beautiful code without them, so why risk sliding down the slope?  Better to ban their use altogether.  (Cue the “Then why don’t we all just use assembler” comments in 3..2…1….)
  • I’m a big user and proponent of the Spring for Delphi framework. If you are, too, then you might consider donating to the project.  The website now has a PayPal donate button.
  • I recommend that you give a very careful read to Marco’s post about what was going on at the Microsoft BUILD conference last week.  Lots of interesting stuff there for us Delphi developers, both in the Windows and cross-platform realms.
  • is for sale.  Hat tip to Olaf Hess in the non-tech group for this piece of information.