http://codemonkeyism.com/the-best-markup-builder-i-could-build-in-java/

I had a go at this (love a challenge) and couldn’t come up with a solution I would be happy with. My approach involved a (G)eneric builder that would allow the population of the properties in-line upon creation of a new object. However, this approach would use use reflection and proxies and therefore would suffer in terms of runtime performance.

I like the approach LambdaJ and JMock’s DSL (2.x) take to the syntax of these sorts of problems. However, with Java, sometimes I guess you just have to accept verbosity (and imperfection in general) as being part of the deal.

Neither comments nor the named, do-nothing methods seem a good solution to named parameters, in my opinion.

In effect, the result is the variables/arguments having annotations (with a small ‘a’) that add semantics that the compiler knows nothing about. You are essentially creating a custom language outside Java and therefore outside the scope of most IDEs.

Inevitably (over time) comments will become stale or separated from what they annotate and methods that simply return a given value will be misused (e.g. using address(“Steve”) for a name argument would be perfectly valid syntactically but completely misleading semantically)

I think any implementation of semantic candy should make use of Java’s type safety in order be useful and maintainable.

Bend too far and things break.

E

P.S. Another great article Stephan, thanks.

J.B. Rainsberger and Corey Haines talk about Primitive Obsession in this video: http://blog.thecodewhisperer.com/post/424488983/corey-haines-interviewed-me-at-the-golden-tulip

The thing about having a Name class is, that functionality that is specific only to Names now have a natural place to live. If Name just ends up wrapping a final reference to a String, then that is also fine because that is now publicly tagged with a type from the problem domain.

That’s the short of it. Corey and Joe go into a lot more detail in the video.

William

I couldn’t help but wonder whether Java 5 annotations would work for this somehow.

Customer c = new Customer( “John” /*firstname*/,
“Smith” /*lastname*/,
87 /*age*/);

Introducing a method called firstname() or lastname() is so necessary?
When the type or the name of a property change you have to change also the method.

And what about the method name resolution? Using your method technique you have to import static all the methods do use it.

However I see a good thing of this idea. It can stimulate thinking about Java syntax and possible improvements to it.

@James: Yes, I like named parmeters

@Nick: Yes, this does work for small parameter lists, but breaks down for longer ones. It also doesn’t help with larger code bases where developers start to rename parameters. The difference between renaming String name and name() is that the first renaming is only local, the second is global and does therefor scale much better.

@Uri: Hmm, need to try that.

@Casper: Looks nice too.

I was using names parameters the first time during the 80 I guess with a programming language called E on the Amiga (or was it the 90s?). I like the idea since then, but Java regretfully doesn’t have them.

def cust = new Customer(name:”James”)

class Utils {
$(“name”, name)
public static T $(String name, T value) {
return value;
}
}

then:

Customer c = new Customer($(“name”, “Stephan”));

I guess it’s the closest you can get to: new Customer (name: “Stephan”);

cheers,
Uri

Here’s another traditional solution that doesn’t need methods:

String name = “Stephan”;
Customer customer = new Customer(name);

Some parameters might be deserving of an object type, like the OrderId in your previous post on this topic, but you should carefully consider how methods will look _when they are actually used_.

For instance, the following is common, and makes the method signature less relevant since context is provided in other ways.

Customer customer = new Customer(htmlForm.name);

Cheers,
Nick.

Customer customer = new Customer(){ name=”Stephan”, salary=65.000};

…then again, a little easier to do in C# than Java since it has native properties rather than mundane manual set/get mechanics.

Customer customer = Customer.name(“Stephan”).phoneNumber(“12345″)

or

Customer customer = Customer.withName(“Stephan”).withPhoneNumber(“12345″)

i think it looks better

I can’t imagine doing that for every class that calls constructors, but maybe as statically imported methods from a utility class? Like:

NamedParameterUtils.name()
NamedParameterUtils.country()
NamedParameterUtils.age()
…

new Customer(new FirstName(“Stephan”), new Name(“Schmidt”));

Another benefit of this approach is that is ’semantic’.
That is, it has the benefits of being able to precisely defining the semantics of each and every property, like in RDF.

I suppose that guy that thinks that modelling is doing more with less would be happiest with no model at all :-).

——————–

BTW, I really like your posts on Java syntax, modeling, etc. Keep them coming please…