Question

I was just reading a Java 7 preview presentation (pdf) and there was a slide on Chained Invocation. Here is the example used in the slide:

// Construction with setters
DrinkBuilder margarita = new DrinkBuilder();
margarita.add("tequila");
margarita.add("orange liqueur");
margarita.add("lime juice");
margarita.withRocks();
margarita.withSalt();
Drink drink = margarita.drink();

// Construction with chained invocation
Drink margarita = new DrinkBuilder()
    .add("tequila")
    .add("orange liqueur")
    .add("lime juice")
    .withRocks()
    .withSalt()
    .drink();

And I have mixed feelings about this. One shouldn't chain too many method invocations into one statement. On the other hand, writing margarita.this() and margarita.that() isn't too convenient either.

Now, I am coming to Java from Delphi world. And in Delphi there is the with language construct. This is cherished by a few and loathed by many (or is it the other way around?). I find with to be more elegant than the idea of chained invocation (which I believe works on the basis of void method returning reference to object on which it has been invoked - and this is the part I don't like, as void should return nothing).

I would appreciate the with language feature being adopted by Java, so the example code could be written like so:

Drink margarita = null;
with (new DrinkBuilder()) {
    add("tequila");
    add("orange liqueur");
    add("lime juice");
    withRocks();
    withSalt();
    margarita = drink();
}

Am I the only one who would prefer this solution to the chained invocation? Anyone else feels that with could be a useful extension to Java language? (Reminds me of someone's question about the need of "Java++"...)

Was it helpful?

Solution

the with statement can be translated in Java using anonymous classes with initializer:

Drink margarita = new DrinkBuilder() {{
    add(“tequila”);
    add(“orange liqueur”);
    add(“lime juice”);
    withRocks();
    withSalt();
}}.drink();

the downsides of using this idiom are well documented here.

Chained Invocation is an alias for Method Chaining. That is well known idiom and works with any version of Java:

class Chained {

    public Chained withFoo() { 
        // ...
        return this;
    }

    public Chained withBar() { 
        // ...
        return this;
    }
}    

a proposal for JDK 7 is allowing of chaining method also for void return type:

class ChainedJava7 {

    public void withFoo() { 
        // ...
    }

    public void withBar() { 
        // ...
    }
}    

OTHER TIPS

This might interest you.

I quite like with statements of that form but I prefer the VB version of them:

With testObject
    .Height = 100
    .Text = "Hello, World"
    .ForeColor = System.Drawing.Color.Green
End With

As each attribute in the With block still has to be preceded by a . you know that you're referencing an Object property and not, say, a local variable, reducing any namespace collisions.

If we take your example:

with (new DrinkBuilder()) {
    add(“tequila”);
    add(“orange liqueur”);
    add(“lime juice”);
    withRocks();
    withSalt();
    margarita = drink();
}

there's no easy way to tell if withSalt() is a method of DrinkBuilder or a method in local class. If you only allow methods of the with-ed object in the with block then I think they become much less useful.

I'm not a fan of this use of with; I much prefer the Python with statement. I do agree with you that void should mean void, though. In the example you provide, if a person really wants to be able to chain method invocations they should just change the return types on their methods so they're chainable.

Maybe the many many calls to one object are the sign that some code needs to be moved around?

Joshua Bloch in Effective Java Item #2 strongly recommends the use of a Builder when you have a constructor with a lot of arguments. One reason is that it can be written to guarantee that the built object is always in a consistent state. It also avoids having complex "telescoping constructors" in the built object's class. Still another is that if you want the built object to be immutable (eg, for thread safety), it can't have setter methods.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top