I’ve tried this too lately, and I really like it. It makes code more readable than using int/long/String for IDs. As you’ve saif, ProjectId is something different than TaskId. And with a growing code base, problems will arise if every Id is String/Int/Long. (mostly because developers - if you take enough of them - won’t name every ProjectId the same, some call it ProjectId, some PID, etc. all being Longs. They can’t screw up with a ProjectId type)

Thanks for your long comment, thanks for the insights.

We are Java developers and we are using a statically typed language. By defining types at compile time we are giving the compiler the information it needs to make certain guarantees. We can not use booleans where Strings are expected. We can not use Strings where doubles are expected. When a method accepts an integer parameter, we know it is receiving one; the compiler makes and keeps that promise.

The question is, how much information do we want to give the compiler to gain this benefit? A lot of people here seem to be arguing that we should only create classes for compound types, and for value types we should just use whatever classes are available, because (I guess) creating classes is too much work.

I haven’t read Domain Driven Development (though I may, now) but this is something I’ve been thinking about lately. To use an example from my project, a task ID is not a project ID, even though they’re both stored in the database as number(10,0) and represented in Java by an int. I think there is value in creating a ProjectID class and a TaskID class so that the compiler can guarantee, not just that the ID I have received is an integer, but that it is an integer representing the ID of a task, and not the ID of a project.

It is true that the IDs are populated somewhere using an integer, but it still greatly reduces the number of places in code that the knowledge that the ProjectID is implemented by an integer is embedded. Lots of people have been saying, “YAGNI”. I don’t see this as a question of building something you ain’t gonna need. That principle as I understand it is to avoid building something because you think it might add value later. Creating these ‘domain primitive’ classes adds value today, the moment they are written, in the form of those compiler guarantees. Also in the form of IDE assistance etc. which is definitely nice to have but secondary. Less repetition, easier refactoring, and knowing that you have a ProjectID are also real benefits.

As far as saying that the code is =less= readable when using domain primitives … I find that baffling. How many times do I have to look up TaskID to know it is ‘really’ an integer? In fact, I never have to look that up. I know it is an integer. Everyone working on this system knows it is an integer. And if we have a new developer, he will have to look at the TaskID class once to see it is an integer.

Every time a developer looks at a TaskID, he will know it is an integer. But the converse is not true. I can be looking at an integer. Is it a task ID? I don’t know. Even if the variable is called taskID, I don’t know. You bring up method declarations with many variables of the same type. It is trivially easy to mix up arguments of the same type.

The cost of this approach … well, I will have to write a TaskID class. I expect that to take one minute. Developers will have to look at the TaskID class to comprehend that it is represented by an integer, if they are working on a system boundary where they care how it is implemented. I expect that to take ten seconds. If it saves two minutes of debugging, it’s worth it.

I liken it to using generics. When Java 5 was released, I added generics to parts of our code base and found many bugs that had been lurking there.

Thanks for this post, Stephan. You’ve really given me something to think about. I’m going to try this, so that I can more fully exploit the strict type system that is after all one of the reasons I am using Java.

@Gabriel: Yes, I also think it makes code less error prone.

bookTicket( new Name( “Apocalypse Now” ), new Film(”Gabriel” ), new Count(1) );

;-)

The Strings are coming from “somewhere” and they can be messed up along the way, no matter what you come up with…

In the first case, nothing prevents me to book a ticket to see the “Gabriel” movie in the name of “Apocalypse Now”… is very easy to mix up the parameters. To catch that I have to actually write a unit test for something the compiler is giving me for free!
Even if wrapping the parameters takes the same amount of code than the test, I don’t need to run it to have the result.

I believe that for non trivial projects, having the (type) contract enforced by the compiler is a good thing :)

I’m happy people like you exists!

No I don’t you’re right.

“I just try to say, ‘Balance’”

Yes, as the title is “Never, never, never use String in Java (or at least less often :-)” which was my amateur attempt to balance it :-) I totally agree with you, most often it’s not an “Either/Or” choice.