I found this article and the comments very interesting -I just read many- and, as a java beginner, I wondered if a name convention for the “String objects” like NameString (for the Bookticket object) would be a good idea to explain this way of thinking ?

Emilien.

bye
Antonio

I agrre with that, and will reread Fowler.

But this being such an old post, I was amazed that no-one mentioned “Primitive obssesion” code smell from Martin Folwer’s book. Jeff Atwood comments on this as well: http://www.codinghorror.com/blog/2006/05/code-smells.html.

Howerver I considerthat like all rules for good design, more important than merely applying them it to know them, know when to apply them, why to apply them and how to apply them. But I am a TDD/agressive refactoring/XP fan, therefore I do not fear old bad design decisions.

On the other hand, primitive obsession is very damaging to DDD, as it really defies the purpose of ubiquitous language and business readable code (at least for business rules). And not only to static languages, but on dynamic languages as well (for instance, Folwer kept the code smell on his Refactoring Ruby with Jay Fields), even though the looser coupling due to lack of type annotations focus more on good names than on good types (and makes it easier to refactor).

//THE PROBLEM
//Concrete classes
class User
{
private int id; //strong typed int, messy primitive
…

class Role
{
private int id; //strong typed int, messy primitive

Instead of using a simple int as ID we created this class:

//THE SOLUTION
public class ID
{
private int id;

public ID(int id)
{
this.id = id;
}

public void setId(int id)
{
this.id = id;
}

public int getId()
{
return id;
}
}

but now we have:

class User
{
private ID id;//Strong typed ID
…

class Role
{
private ID id;
…

This is a really nice enforcement of types. Now we can have:

List<ID> usersID = ….
List<ID> roleID = ….

instead of

List usersID = …..
List roleID = ….

An even more Generic Solution:

//THE SOLUTION
public class ID
{
private R id;

public ID(R id)
{
this.id = id;
}

public void setId(R id)
{
this.id = id;
}

public R getId()
{
return id;
}
}

Here is a idea you can use “KISS”.
(K)eep (I)t (S)imple (S)tupid

Over complicating a simple data holding object is a waste of time, memory, and processing.

Of course, a non-final String would be evil in many other aspects, so what we’d really need would be a langauge change that made it legal to extend final classes whenever the implementation is not changed:

[code]class Name extends String; //empty implementation![/code]

or, for more complex cases:

[code]class Name extends String implements OneOfMyEmptyInterfaces; //empty implementation![/code]

Guess this will be left to languages like scala.

I’ve read your post and I found it _really_ interesting in terms of OO programming. That’s the kinda things I love to learn and understand. So thx for this :-)

Still, I wonder what the consequences are on O/R mapping. I haven’t had the time to read all the comments, I just saw some people asking about mapping with Hibernate, and didn’t find any anwser on that topic. If you define Name and FirstName classes that can be used by several other classes, handle the O/R mapping will be a nightmare, won’t it? (I guess you won’t create a specific table for Name and another one for FirstName, as you would have too many joints) Do you then have to handle the persistance layer by yourself without a O/R mapping framework? (or you just use object databases ;-))

Cheers!
Fab

And I’m not sure either what you consider “experienced” – because you don’t give a definition. I’ve written code for around 30 years in around 20 programming languages.

For more information see the link label “About me” at the top.

Have you ever worked on some big projects or only toy programs with ten classes?

For example, if I follow your apprach, mapping hundreds of hibernate entities, I would end up with thousands of new classes.

It’s simply impossible to code, read and mantain.

For one, I completely agree with the opening post. I find the mocking replies to this post frankly offensive, on a few levels. The author does not suggest to meaninglessly wrap primitives simply to do so to make life harder. His suggestion is to not use ambiguous types where specific ones are more appropriate. String, double, int, and so forth, have no real context, no rules governing their use or mutability. (Beyond those introduced in the declaration through modifiers and visibility)

Primitives imply no meaning and leave it up to the developer to determine what is in fact valid and what is not. I mean, some replies said that doing this pattern “simply [so] your IDE will do a better job of helping you understand the code.” As though that is some travesty!

To say that the indirection is meaningless seems to assume that all values that a String can hold are also valid for someone’s name. For example, Strings can be null, ” “, “”, “$@##%%@%#&^$%”, “a”. Are these all suitable names? They must be, since using String directly for the name is apparently the trendy thing to do.

After listing those, to use TDD as an example that String is in fact the best data-type is simply absurd. The tests you make must have dreadfully poor coverage.

Of course, the easy solution to my scenario is to test for these cases in the setter, and throw IllegalArgumentException’s whenever these situations occur. Indeed, one can jury-rig all kinds of conditions into this BookTicket class to assure validity. A previous reply by Xavier explains the reasons why this is a bad idea (Centralized validation, throwing exceptions at the logical place where the exception occurred, and so forth)

After all, it’s highly unlikely this is the only place in this project where you would have a name – most likely, you’d use it many places, and each would be vulnerable to the same invalid test-cases described above. An ‘agile’, YAGNI-inspired solution of ‘using strings because its ez’ would waste time and force the developer and tester to ensure everywhere a name is used, that it’s correct.

Beyond these practical concerns, a more pressing concern would arise. The BookTicket class’s responsibility lies in accurately representing the state of a BookTicket. It should not have to worry about making sure someone’s name doesn’t consist of only letters. It should not have to worry about whether the orderID is already in use. It’s a simple class, and should be made simply.

The idea of responsibility-driven design is an old one, and I think one that’s often forgotten by people. It’s become second-nature to just pile features and functionality unto one class, under the convenient guise of YAGNI to belie a hidden sense of downright laziness.

I doubt I am alone in finding a few, small classes _easier_ to understand, than one monolith, whose implementation must span the gamut between name validation, orderID validation, and BookTicket representation. This defiles the true intent of the class, and makes maintenance, extensibility, testing, and understanding the code a nightmare.

An analogy to this concept that comes to mind is HTML tables. I remember reading a post about how they’re flagrantly abused to layout pages, when in fact they’re simply intended to (surprise!) represent tabular data. Now, getting a consistent layout can be difficult, so I can understand being lax on that point, but there is *no* excuse for being amateur when it comes to Java.

A String should be used to represent arbitrary text. An integer should be used to represent an arbitrary integer value. If these are sufficient (e.g. can be null, random symbols, Chinese characters, etc. in the case of String), then by all means, but to assume that just because a name consists of letters means that it should be a String is madness.

public interface SocialSecurityNumber extends Property
{}

which can then have constraint rules added to it centrally;

@Constraints( SocialSecurityNumberConstraint.class )
public interface SocialSecurityNumber extends Property
{}

I am pretty convinced that this technique will make apps a lot more robust in the long run.

I definitely agree with your overall ideas, but for this particular part I tend to think that you’re not likely to really or often need to know what’s inside of a ProjectId or TaskId class; it could be a single primitive, or a salmagundi of things. And that’s good.

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.

“The metaphor of the silver bullet applies to any straightforward solution perceived to have extreme effectiveness.” -Wikipedia

I consider it more of a “Best practice” post.

“Having one class per String usage (which is the extreme case) sounds like ‘class explosion’ to me, not doable in large domains.”

You will notice that there are not that many String-types as you think there are. Most of the time the Strings are of the same “type” – Name, Description, Titel and so on. Which more or less proves my point when developers cannot or do not categorize Strings into types but perceive all of them different.

Having one class per String usage (which is the extreme case) sounds like ‘class explosion’ to me, not doable in large domains. But selective use of ‘domain types’ makes sense to improve readability.

That aside, yes there will be more classes.

I don’t think it’s too much, I think it helps read code:

(String, String, String) as a signature

versus

(Name, Firstname, Description)

I find the second one more readable and being more clear.

public class Name{

}

I tend to disagree: The “bloat” is rather small but the benefits are great, 5 years into development it makes development much faster and productive and less error prone.

- Named method arguments, so you could write:
new Customer(firstName=”Stephan”, name=”Schmidt”);
This would be great for DI, also.

- Having special constructs for such value objects, like Scala case classes.
Note that getters, setters, equals & hashCode are constructed automatically by the compiler:
case class Name(name: String)

What you propose adds way to much bloat, and Java already has enough of that. Oh, and btw.: you can actually perform validation in setters, you don’t need a separate class for that…

Stephan, could you blog at some suitable time your ideas on rule 8 in Object Calisthenics: “Use First Class Collections”.

I wonder whether it is really worth the extra effort or what are concrete benefits in that.

I’ve mentioned Qi4J in other posts like

http://stephan.reposita.org/archives/2008/01/09/qi4j-the-next-java-forget-scala/

Classes are Dead, Long live Interfaces.

To give this audience a teaser;

public interface Person extends HasName, HasAddress, HasSpouse
{}

and no more coding is required. No magic, pure Java, clever runtime….

@Stephan: Yes, your primary message was to make type check stronger. My primary objection to this is, that you say “never, never, never”. When a system gets over a certain size, you need to create tools that handle various kinds of information the same way – so that the code really doesn’t know if the string is a name, a zip code or a product ID.

Interesting what you think that I’m saying.

I do think it’s good to have validation on object creation, though this topic is miles away from the post which was not to use Strings instead of classes.

If performance is an issue because of validation, have a Valid interface with an isValid() method. If you have different contexts of validation, change the validation code. If that’s not possible, habe a ValidatorService. As the title of the post – which noone seems to read – suggests, do the right thing don’t follow a dogma.

People just don’t seem to get that if their objects need logic, it should be encapsulated in that class.

E.g. instead of:

Collections.sort(users, new Comparator(){ etc etc}

it should be:

Collections.sort(users, User.COMPARE_FULL_NAMES);

There are many, many reasons for this, but the primary is that all logic for the object should be as close to the object as possible, at worst in another class in the same package.

I have been stuck with codebases of my own design that used the former. What happens when the customer wants to change the sorting method? Code search. We may as well use ruby in that case.

I welcome you to an average enterprise project, where code is not being written as the books and best practices would have it. 8-)

Jokes aside, I think too much emphasis on this thread has been placed on validation (but it is a large part of business applications), and the original blog post tries to make a point on domain modeling.

The original blog post argued that domain modeling needs to occur at the lowest possible level. At some point, every project, starts introducing domain model.

That concept, ’shields’ (in a way) developers from thinking about low level implementation, and let’s them focus on higher level constructs and interactions within the system.

For illustration purposes, somewhere in the code, one WILL eventually have classes named Order, Person, Customer, Report (depending on what the application does, of course).

When does one start introducing the domain objects? At what level?

Stephan’s post argues that domain starts at the very bottom, at the lowest possible level. The rest should then build on top of it.

He chose to illustrate his point with the simpler examples of Names, and some comments jumped on that. My comment was that I agree with him, even for those simpler examples, and wanted to support his view with a real life example.

I would say, if there are business rules around the thing you are modeling, it becomes a domain class.

- Date of birth for a person in your application needs to be within certain date range? You just got yourself a DateOfBirth class.

- Password is between 6 and 8 characters, and has to have 2 digits and a special character? Guess what, the model just got a Password class.

Domain classes allow for better immutability, reuse, and yes, they should encapsulate their values, as well as their behaviour. Validation? In most cases, it should probably be a part of the domain class, as it is the place that has the most knowledge on what is being validated.

Is it an overkill to model even the Names in such a way? Maybe in simpler cases. However on larger projects, where the data may come from several databases, mainframes, web services, you as a developer, really need to rely on something telling you what that String/int/long really IS. Domain model lets you do that.

Now, the biggest problem actually is not writing this code properly, but to get the business stakeholders actually agree on the business domain. Is contact address the same as principal residence address? Does it have the same fields and which values should be in those fields? What is a ‘valid’ mailing address? What ‘is’ a Person?

I’ve never worked on such a project that had domain constructs at such low level, but after seeing the issues we are encountering, and having recently read Domain Driven Design and blog entries like this, I really want to try use such concepts on the next projects.

There is a push back from nearly all developers I’ve worked with, and that’s why I welcomed reading this blog entry. Most developers are arguing against such modeling, but they will happily use java.util.Date (for now, let’s put aside the suckage of that class), instead of a String, or long, or three Strings/ints (day, month, year), or 6 Strings/ints (day, month, year, hour, minute, second).

When you look at it, Date IS a domain model, raising above the primitives to model a real world concept (with some internal validation and ‘business’ rules).

Finally, to comment on your points:
1) [increasing the number of places that the validation code is executed, impacting application performance]

I am not sure if the domain modeling increases the number of places validation code is executed. As you are accepting the data in your application, you have to validate the data anyway. On some projects, just because you are reading data from the database, does not mean it’s good (valid). Some other application sharing the database might have put the wrong data in.

As for the performance impact, who knows. Profile the code and see where the problem lies. Then fix it. Anything else is just an assumption.

2) [co-locating the validation code with a class that is used to contain the data, adding dependencies that may be unwanted]

I don’t know what dependencies are you having in mind, but you will have them in your code anyway. Just because you use a String for a password on your Account class, and have a separate class named PasswordValidator in a separate package, does not mean they don’t depend on one another.

Actually, I am arguing that having such code close to one another actually makes the dependency visible, tangible, easily understandable, exposing business rules and making developers aware of it, stopping them from writing yet another password validation somewhere else.

Huh. Time to go home.

However, what Stephan is advocating, is not to reduce the number of places in your source code, where you write validation code, but to:

1) Increase the number of places that the validation code is executed, even to places where the check would reduce the app performance maybe 100 times or more.

2) Co-locate the validation code with a class that is used to contain the data, adding dependencies that may be unwanted

You can achieve much better validation with better performance and better maintainability in other ways.

I am so happy to know that I am not alone in this ‘fully domain development’ way of thinking you are describing in your blog entry.

Maybe the people got hung up on the FirstName and Name examples, which, at first, do not sound like good candidates for wrapping Strings into Domain objects.

But we actually had a problem with the last names on the project I am currently on. The business wanted to limit the last name length to minimum 2 characters, and of course, the code was littered with length checking, from the ui level to the database.

A couple of months later, they dropped that requirement, and it took us ages to find all the checking throughout the code and remove it.

Yes, you can argue that we could have created a LastNameValidator, but the situation was not that simple, because of the way presentation, business and integration tier handled last name for their purposes.

Also, if you are creating LastNameValidator, what better place to put it then the LastName domain object, since that’s the place that should know how last name ‘looks’ like. And once you need to soundex/reverse soundex the names, where does that go?

It’s also no fun to deal with international phone numbers as strings formatted in who knows what way (with/without dashes, braces…). Validation and formatting code all over the place.

Then again, project after project, I’ve seen this emphasis on using Strings everywhere, even in the places where Java already has nice domain representations.

Those developers have no objection on using Strings for email addresses and urls, and then fix endless stream of defects logged against their validation and parsing, even though one line use of java.net.URL and javax.mail.internet.InternetAddress would eliminate the problems before they even happened.

When entering data: Depending on the country chosen for the person, and depending on the system policies for the database, we look up the zip code in a table. For some countries, the zip code must be present in the table, and for countries that we don’t know details about, we accept anything that complies with the max length of the database field.

When importing data about a person from other places, we cannot reject zip codes that we consider wrong, so we only check that their length is ok.

In other words, our standard validator for zip codes could be described as:

bool ValidateZipCode (zipcode, country, systempolicy, nationalzipcodelists, maxfieldlength);

I wouldn’t have a clue how to call this validator from the constructor of a zipcode object. I’m also not sure if this actually belongs with a zip code object, because that would introduce dependencies from the zip code class to the country class, which might be an unwanted dependency.

public class Zipcode {
…
public boolean validate() { … }
}

And could you have different constructors, one that does validation and one that doesn’t?

And different validators; for example, validateOldStyle() and validateNewStyle().

Stephan, how do you do the getters when you need to use the primitives? I’m thinking that you’d use the ‘as’ style, for example, firstName.asString().

I would also like to see a more fleshed out example. I’m also curious to see how it would work with Hibernate, and Spring’s MVC with its forms.

1) Type check. It’s good to be sure that the order ID values are always order ID values, and stored the same way. I can agree on that one.

2) Debugging. By using a class for order IDs everywhere, you can build debug code into the class generation, which catches specific bugs.

3) Simple validation: Checking the value’s correctness, only by looking at the value itself. For instance, age should be between 0 and 200. If outside, it’s a bug. Doing this check everywhere will definitely harm performance, possibly in ways that makes the app not comply with user expectations.

4) Full validation: Checking that the value is a real value. We usually do full validation, checking that the value is actually in the database etc. A full validation can take 0.1 seconds. Validating 1000 values can take 100 seconds. It does not make sense to build a validation like that into the constructor of a class that handles a simple string value.

The way that Stephan chooses to write his comments, it seems that Stephan is actually recommending a full validation with database lookups, national name service lookups etc., every time you create a new piece of data in your application. Since this is totally unrealistic, I guess that this is either philosophy, not well thought through, or misunderstood by me.

Even simple validation is something we can definitely disagree on, simply because I don’t see the point of introducing new loops inside other loops that are already slow and consume 100% CPU time.

However, it doesn’t make sense to validate simple values at the time of assignment to a variable – that’s waste of CPU power. Try to imagine that you want to import a million order IDs into an array, sort them and output them again. That’s simple: find some code that can read strings, sort them and output them again.

What Stephan basically says, is that this method is not so good, because it doesn’t validate the orderIDs. Ok – let’s say that we have 3 different order ID systems, and we want really good validation. In order to solve the “sort the file of order IDs”, Stephan’s approach would then need:

- Find a way to get additional data about what kind of order IDs these are, so that we know how to validate them
- Implement a class for each kind of order ID validation
- Create one object for each object ID
etc.

It’s totally overkill. You may regard this as a special case, because your projects don’t do much of these things, but there are huge amounts of applications out there, that does these kinds of things very often. Therefore, Stephan’s recommendation may apply to his project, but it surely doesn’t apply to many huge applications deployed in public administration and big corporations.

I don’t think you get it. Validation is necessary, but implemented correctly.

Here is my thought process in code:

try{
zipCode = new ZipCode(“90210″);
insertIntoDb(zipCode); // stupid example
}catch(ValidationExceptione ){
showToUser(e); // etc
}

Compared to what I think you are proposing:

Either you are proposing no validation:

String zipCode = “badmonster”;
insertIntoDb(zipCode);

Or some, but externalised:

String zipCode = “badmonster”;

if( ! validate(zipCode) ){
showToUser(zipCode, “Error message”);
}
// somewhere else in the code:
String zipCode = “90450″;
if( doesntValidate(zipCode) ){
showToUserInDialog(zipCode, “Enter zipCode”);
}

————————————

If either of the two is what you are proposing (which I think is B) then my point is proven. By making the zipcode understand what is good data, you never have the risk of reimplementation of code. The object knows whether it’s valid or not.

All your arguments against this are meaningless. I could easily have a ZipCode that determines the type of zipcode validation (for legacy integration) or use the correct one. One object responsibility in no way guarantees failure, far from it.

I agree with your other argument though

“If you do something 0%, you probably do something wrong.
If you do something 100%, you probably do something wrong, too.”

Because of this the title of the post included

“(or at least less often :-)”

:-)

Peace
-stephan

To your question about validation: We validate a lot, and normally always in the interface where data comes in (GUI or API to external systems).

In the example I gave you, the order ID is validated because if it cannot find an order with the specified order ID, an exception is raised, telling very clearly what the problem is. Checking against a list of existing orders is probably the best validation you can get.

In a database, the same field may require different validation depending on the app that stores it and the current configuration at the time of creating a record. We usually assume that historic data is correct, even if it is created and validated under a data policy that stopped 5 minutes ago. It doesn’t make sense to apply a validation rule that only exists for 1-2 years, if you want to create a system that is in production for 10-20 years.

With regard to principles, the only thing I will dare to really generalize is this:

If you do something 0%, you probably do something wrong.
If you do something 100%, you probably do something wrong, too.

This applies to OOP, UML, unit testing and a lot of other buzzwords/religions.

Then I would use something like Crystal Reports or any other tool and not write my own code.

And validation is not needed for reporting. As isn’t a domain model.

“new Name(“John”,”Doe”); // can still handle all the validations”

So you do support a class for a name or not? I’m not sure.

“In fact to support Lars’ argument.”

So you would use String firstName = “John”; String lastName = “Doe”?

And not “new Name(…)” ?

I’m not clever enough to follow that logic.

“As you can see, it’s quite simple: You call a FetchCustomerIdForOrder (OrderId Id), and then you have the customer ID and can print everything.”

So you do not have input validation on the file? And put your orders directly into your database without validation?

Then perhaps we have two very different styles of development and discussion on validation is futile.

With all the fragmentation of classes into smaller and smaller units of coherence, as you suggest. Mapping would become counterintuitive, filled with @embedded and @oneToOne relationships.

The idea you propose is good in certain scenarios, no doubt. But the imperative tone of the article, with the strong disclaimer as the title, is a little bold ;)

— FirstName firstName –

From a pragmatic viewpoint this is just painful. There is no good argument in design to break up entities to this level. In fact to support Lars’ argument. All this would do is promote unnecessary validation, creating a restrictive, impractical system.

new Name(“John”,”Doe”); // can still handle all the validations

new Name(firstName(“John”),lastName(“Doe”)) // Is over the top.

In fact it reminds me somewhat of Scala. A very academically though out language. But far too ugly for the real world.

Ok. Please show me the code that solves this task:

You receive a tab-separated file like this:

123-456 45
2345-22 78

Now, your code has to import this file. The first column contains order IDs, the second contains some value for this order ID. That could be statistical information or something completely different.

Your code must:
- Read this file
- Write a list of customer ID, order ID and this value

As you can see, it’s quite simple: You call a FetchCustomerIdForOrder (OrderId Id), and then you have the customer ID and can print everything. According to your “no brainer” explanation, that doesn’t work, because you don’t have the date of order creation, so you cannot create an OrderId object.

In other words, your explanation is wrong, and “no brainer” is probably not the best way to describe an faulty method. You can then say that “we create a non-checked orderid class” (which would be, like, a string?!?) or “we just retrieve the date from the database, too” (which would harm performance), or perhaps something else. But I guess at this point, we already found out what the basic problem is: We’re already way beyond a reasonable level of complexity.

Most apps are database applications, where data is not necessarily created by the application that reads it. In other words, you have one piece of data (a string) and multiple implementations that read and write it, maybe even in various languages (java, php, C# etc.). If you add to this, that you may even have various versions of each application, and many different installations, then you often end up in a situation where it doesn’t make much sense to let the reader validate the data in a very high detail.

Some data may even pass multiple systems. I think that the longest path of data transmission, that I have been involved in, is to transmit very precise and structured data across at least 20 applications, using XML, tab-separated files, SQL and many other techniques, transferring data from the end-user to a national database. You don’t want to update validation code in each of these systems every time the data standard changes a bit.

With regard to the other examples: The same GUI is usually used for all CPR-number registrations (requirement from users) and you wouldn’t want to make a network transmission for every time you assign a name to a new variable in your code.

“What about if a company changes it’s order ID system. That would mean that orders from before 1990 must comply to xxx-xxx, orders from 1990-2005 must comply to yyyy-xx, and after 2005 they are again xxx-xxx, but restarting from zero.”

No problem with an OrderId interface and different class implementations, depending on the date it was created. A no brainer.

With Strings? How do you validate an Id in a String without any further information? I guess that’s impossible.

“A national person identification number.”

Excellent too, having different classes for an ID with different GUI frontend and Hibernate mappings, a no brainer. With a String this is much more difficult to implement (You need to encode the county in the number or something like that).

“So I guess a name class would contain thousands of names in it’s source code? ”

Shouldn’t that come from a NameService for your country which returns Name domain objects? With the validation in the service and the only possiblity to create names from the service, so you have always valid names? Compared to Strings which need to validated in lots of places?

Thanks for the examples, I could not have thought of better ones for my arguments.

We could easily introduce a name verification, checking that first name and last name are both present, have initial caps letter etc. A University in USA once checked for presence of first name and last name, and then the son of our Queen wanted to study there, but as a royal he doesn’t have a last name… so the IT system failed to help the University. Validation is good, but it should not prevent the user from getting things done.

Another example: A national person identification number. In Denmark, we use “CPR-Numbers”. However, if you check these fully, you will find that foreigners are suddenly excluded from your system, and you might end up being able to use your IT system for 90% of your work. The rest has to be done on paper, or you have to invent fake numbers. You can then discuss how to define person IDs, but you can be sure that the customer doesn’t provide correct specs on this from the start.

What about if a company changes it’s order ID system. That would mean that orders from before 1990 must comply to xxx-xxx, orders from 1990-2005 must comply to yyyy-xx, and after 2005 they are again xxx-xxx, but restarting from zero. An orderid class can do some checks but it cannot say, whether the orderID conforms to the current standard for orderIDs.

In Denmark, a validity test for names is quite easy: We have a list of approved names, so if the name doesn’t appear in the list, it’s not valid. So I guess a name class would contain thousands of names in it’s source code? Doesn’t make sense to me. Anyway, under certain rules, a name can be accepted, even if not on the list. This typically happens when somebody immigrates. In other words, the validity test depends on the context and external decisions.

Then we could discuss SQL string conformance test. Well – doesn’t that depend on the database server? One of the big benefits with SQL is, that you can create a tool, and then use it for many different database systems, even for future database server versions that you haven’t heard of yet. Can you validate SQL if you don’t know the database server SQL standard, yet? Of course not, that would be utterly rubbish.

I could continue for a long time giving examples of where validation of strings or a stupid question: It’s not WHETHER to validate or not, it’s WHAT to validate and WHEN.

Basically, all this relates to how do you develop software. Do you use the waterfall model, agile software development or something else? Who provides the specs? How big a part of your costs goes to automating testing? If you spend close to 0% or 100% on automating testing, you’re certainly spending your money unwise. A good projects spends something in-between, and good projects don’t have unlimited access to money – because that makes them inefficient.

I guess it depends on whether you understand OO.

Lars, here is an example:

String orderId = “2343590″;

Where does the validation go? The answer is EVERY place you need it. Now your developers that want to user orderId need to put checks in everywhere. And your developers need to know how to validate an order – what was that class called again? Oh, and how are you going to retrieve it? I guess you could pass the order validator in, inject it or have a static service — NOW you understand why code mess happens in most java projects!

Compare this to:

// throws OrderInvalidException
OrderId id id = new OrderId(“2343590″);

Now, whenever your developers have an OrderId, it is guaranteed to be valid, especially if it is defined as immutable. Simplicity.

Wrapping primitive numbers has advantages but without additional language support, it’s hard to make use of numeric libraries (as was pointed out previously).

I’ll try it on code I’m working on now and see if it flies.

I think it’s more important to save manhours in the process of finding out, why a correct order ID retrieves a wrong order, than to optimize the unit tests for checking that the orders got the correct order ID.

You may construct examples where it makes sense to spend programming hours on encapsulating the data in a way that range checks, makes checksum calculations etc. every time a value is assigned, but there are surely many cases where the costs are bigger than the benefits.

The worst code you can get, is where almost everything is defined elsewhere. You don’t need to add many programmers to a project like that, and you’ll end up with huge overhead, low productivity or spaghetti code quickly.

Good code is where a new programmer, who doesn’t know about the project, can add a new feature within an hour.

Excellent point. An OrderId with validation logic, range checks etc can easily tested with unit tests to make it essentially bug free. See how much the Array bound checks in Java have helped with security problems. Because the logic is in the Array class.

A String orderId is impossible to test, you need to test every input and output path of the code, and perhaps every usage to check for correct validation etc. Keeping logic local and encapsulated results in easier to test code I believe.

OOP is very good, except when it makes source code much harder to understand for those readers, who needs to understand performance, security, find bugs etc.

Most source code is a compromise between readability, performance, productivity and safety, and it rarely makes sense to make one of these three parameters be dominate all code.

The user would get the OrderId for example by:

1. OrderId id = orderService.getNewId()
2. OrderId id = order.getId()
3. OrderId id = bookingSerivice book(Order order)

etc.

No need to know what the id is.

Or to follow your argumentation, “In order to fully understand the code” one would always be forced to look into String or StringBuffer and understand the internal implementation (as you want to understand the OrderId implementation) to fully understand the code. No one does that (except for finding bugs e.g. or to learn from the code)

1. void book(String id);
2. void book(OrderId id);

The second one is much clearer. If your system has an OrderId, the developer writing the book function needs to use the OrderId. He can then choose to poorly name the paramter “id”. In the first case if the developer chooses to name the parameter “id”, all others are lost.

“The reader has no idea what is being passed. It could be a string, an integer, or a complicated object.”

The reader doesn’t need to care. That’s the idea behind object oriented programming, which I understand is out of fashion our days (think encapsulation).

“In order to fully understand the code, you need to read in multiple places in the source code, which wastes programmer workhours.”

See above, the developer gets an Id from the GUI or a service and doesn’t care how the Id is implemented (again, encapsulation).

Whereas with the String the user a.) knows implementation details of the id b.) build his application (book method) to the implementation of the id (String), not the semantic idea (id).

1) scatter that logic in the ui AND the entity (Person.setName) or
2) create a value object Name with the validation Logic.

In the end, I chose the second solution as it clearly had 2 advantages over the first one:

1) the validation was defined once and for all in one place (the Name class) and
2) when a wrong name was entered, the error was raised immediately when the Name object was created (in the ui), not when the entity was persisted (which is 2 layers deeper and harder too debug). I think this is related to the ‘Fail fast’ principle: if the name is wrong, don’t wait until you persist the Person to know about it.

1. void book(String orderId);
2. void book(OrderId order);

The first one:

- The reader understands immediately, that a string is passed, which represents an order ID
- Whereever this order ID is used inside the function, there is no doubt that it’s an order ID

The second one:

- The reader has no idea what is being passed. It could be a string, an integer, or a complicated object.
- In order to fully understand the code, you need to read in multiple places in the source code, which wastes programmer workhours.
- Whereever the order variable is used, the code doesn’t reveal that it contains an Order ID.

Therefore, it is quite obvious that the first of these two are the best choice.

public class Address {
boolean multiline, virtual;
String address;
public Address(String add, boolean mul, boolean vir)// cant be bothered typing
}

I hate such code as it’s hard to remember what the booleans mean some times. So I use now:

public class Address {
enum Lines;
enum Reality;
String address;
// you get the idea
}

This means you can create objects with meaningul names instead of booleans.
Eg. new Address(addr, Lines.MULTILINE, Reality.VIRTUAL);

Perhaps you are right, but then it really doesn’t matter for FirstName, because you are mostly using the object only to construct a customer object you will use a dozen times.

Look at another example, zip code. I bet most people in this thread use a primitive for zip code which creates a lot of problems when going i18n. And all those primitive defenders will use

Customer {
   String name;
   String street;
   String city;
   String zip;
}

instead of

Customer {
   String name;
   Address address;
} 

Address {
   ZipCode code;
}

Are you still on the primitive side?

“The main issue here is that the rest of the Java world uses primitives, and avoiding their use makes interacting with this world very difficult.”

If you are using primitives all over, then your doing something wrong. Your methods should mostly use value objects and entities from the beginning (See parameter object pattern and others).

So we’re only talking about 20 percent or less of primitives in method calls which I propose to replace with wrappers.

“My advice (and what I understand to be a best practice) would be to choose the simplest possible solution.”

Ah, but using a wrapper is simplier within your IDE than using String. And it is simpler to understand. You’re against the idea because one time you need to write a little bit more code, say 10 lines. But code is written once (most of the time) by one develper but read a thousand times by dozens of developers. I do know that currently writing less code is the hype, see Rails et al. But this is also wrong. It’s not about writing less code, it’s about writing maintainable code. 80% of costs will arise in maintenance, not in development.

So with a rapid development is the most important thing mindset, we will always disagree.

I think the issue of semantics is a bit of a red herring. If a parameter is poorly named and is undocumented, it’s hardly the fault of the primitive. It’s sloppy coding. I think it’s fair to say that someone who won’t go the extra inch to JavaDoc their code isn’t going to go the extra mile and wrap their parameters.

The main issue here is that the rest of the Java world uses primitives, and avoiding their use makes interacting with this world very difficult.

For example, if I want to modify an ID’s value using the Apache StringUtils class, I can’t just pass the ID object. I need to extract the String value from the ID, pass it to the StringUtils method, and finally construct a new wrapper using the result…

…that, or extend the ID class to include this functionality. Now, multiply this sort of problem by each framework or utility that you use.

My advice (and what I understand to be a best practice) would be to choose the simplest possible solution. Use primitives whenever you can. Like Visa, primitives are accepted everywhere. When you outgrow one, just accept that you’ll need to refactor and move on. ;-)

And I stand by my opinion: Using primitves (and as said before I consider String a primitive) as method paramters more often is a bad idea than not.

“[...] the name of the variable is already semantic.”

Yes, sometimes it is, sometimes it isn’t. I’m always for well named parameters and sometimes think about a parameter name for 10 minutes, and then change it again because I’ve found something better. Having a object instead of a String/Long conveys the semantic better though – and I think it prevents bugs this way.

BUT reading all this comments bashing my post – most likely I’m wrong :-)

(I’d still use a Price class instead of double, and a PriceRange and a Money class, and – when there is semantic to a name – a Name class).

If it doesn’t promote the use of Name objects, then perhaps I’ve misunderstood the promotion of value objects in that book. From the definition in the book, Name looks very much like a value object to me.

@Clark: You’re right, this isn’t black or white, “(or at least less often :-)”

The count class is very contrived, I would use an int too, not a Count class. Having an inc() method would be handy though and on a higher semantic level than the int count++ version. And as written in the post, Order or something like that would be best. As would a be a Customer class.

Your point on it being more semantic is valid. But 1) it’s usually wasted effort and 2) the name of the variable is already semantic 3) there is sometimes an advantage to knowing exactly what you’re working with without having to do any research. For example, when I see private String firstName;, I know exactly how to set and get its values.

The point is, you shouldn’t need to care what it is.

@B.Waite: I consider you lucky for never having come across am method with 4 Strings which you do not know what they mean and you do not have somewhere to go and look them up. I’ve come across a lot of code in the last decade which was written this way and was really hard to understand.

As I’ve written, the example is no real world example because one would use an order domain object instead of several parameters.

@youneededtohearthis: Considering the semantics of String and comparing it with int, String is a primitive just like int. As I wrote there is no semantic to a String, it could be anything. Compare this to Person, Name or Point which do have a semantic meaning. String doesn’t.

“You don’t maintain them, ever. “

You do have to maintain them. Over the life cycle of several years those “things” often need to change. The need to transfer more information for example. When using a String your’re out of help and need to refactor every method which uses your String with additional information. Say your String is an ID. After some time your business user decides that IDs should become invalid. With and ID class it’s easy to model a valid state into the ID. With String, as you’ve said “You can’t extend them.” you need to refactor a lot of methods.

The reason I sit here, boggled, is probably because I’ve never heard of anyone having problems with unwrapped Strings and primitives.

Ever.

Your examples that use Strings and primitives look like every Java method I’ve ever encountered. They’re so conventional they’re boring.

I can’t imagine encountering a method like any of these, and being confused.

On the other hand, if I encountered a method like your second bookTicket example, I *would* be confused. Not for long, but your unconventional approach would take some time to understand.

So now I have this API with a billion methods with strange class-names … how do I create a damn Price object? What’s that? Is it a String? a Double? a Long ? A composite class with lots of fields? (price in dollars, pounds, yens … with taxes without taxes).

I just don’t get how is having to investigate dozens of classes in order to know which primitive types I need, going to help me.

“Never, never, never use (unwrapped) String or long or int. Why? Those primitive types have no semantic meaning.”

You are laying down rules you expect Java programmers to follow, but you are quite ignorant of the language. String is an object, not a primitive.

The name of the variable, get/set method or the method/constructor parameter name provides the semantics.

“They are hard to understand, hard to maintain, and hard to extend.”

They are easy to understand. You don’t maintain them, ever. You can’t extend them.

I would hate to have to maintain code you have written, because I bet it is full of pointless layers of indirection.

The idea is interesting but just looking at your examples here it looks like this would not scale well to large projects.

I’d prefer:


public void bookTicket(
Customer,
Film film,
int count,
Cinema cinema);

or if your a real purist :-)

public void bookTicket(
ICustomer,
IFilm film,
int count,
ICinema cinema);

In a domain discussion with end users, Customer, Films and Cinemas would the typical domain objects. First name and last name are simply attributes of the Customer.

Anyway, you seem to have your mind already set. Good luck with that.

“I don’t think this is a matter of team or project size, really.”

I do think it’s a matter of team size:
- bigger teams have a higher probability of having sub-average developers (if you don’t do hard recruiting)
- the more people, the higher the probability that you will need to read and understand (and fix and refactor) code which you didn’t write. So there is a need for clearer code

“You are adding classes for your IDE, and that’s wrong.”

You’re taking one sentence from several dozens ones. But even if you’re right, even if it would be the only reason – and it isn’t – I think you should go that way. Sometimes the choice of your IDE is limited, sometimes the only company option is Eclipse (a bad choice on it’s own, but I don’t want to fan the flames in this thread).

Please consider again some of the comments in your post, some of them strongly opinionated but most of them aligned. What you are describing here is the definition of YAGNI. You are adding classes for your IDE, and that’s wrong.

“The mind of the beginner is needed throughout Zen practice. It is the open mind, the attitude that includes both doubt and possibility, the ability to see things always as fresh and new. It is needed in all aspects of life. “

Some time ago I thought it impossible to write code without setters and getters and abide by the law of Demeter or Ask-don’t-tell. Over the years I found this guideline to result in better code. The only problem I have with this is when to have other representations of an object, like String or XML. It strikes me odd to put XML generation code into an object as it’s an orthogonal concern. Not sure how to solve such cases without getters.

My IDE is IntelliJ IDEA and most often helps with my “useless” objects. What “real” IDE would you suggest?

I do like the named parameters...communicates very well, and matches what the Ruby & Objective-C community does.

Anyway, I just wanted to point out this aspect of it. And as soon as I mention Holub on this topic, I have to brace for flames :-) His design articles are quite polarizing and I often see them criticized but it seems people often misunderstand the underlying idea–which is easy to do with his articles.