Chain style method design

Question

I wrote a simple class to demonstrate a chain style method design:

public class Cal {

    private Cal(){}

    private boolean isCheckArguments = false;

    public static Cal useAbs() {
        return new Cal(){   
          @Override int check(int i) {
                return Math.abs(i);
            }};
    }

    public static Cal useNormal() {
        return new Cal();
    }   

    public Cal checkArguments() {
        isCheckArguments =true;
        return this;
    }

     int check(int i){ return i;}

     public int plus(int i, int j) {    
        if(isCheckArguments && i<j){
            throw new IllegalArgumentException("i<j!");
        }
        return check(i+j);
    }
}

So the client code can be:

Cal cal = Cal.useAbs().checkArguments();
int sum = cal.plus(100,2);//IllegalArgumentException occurs

Cal cal2 = Cal.useAbs();
int sum2 = cal.plus(-100,2);//98

Cal cal3 = Cal.useNormal();
int sum3 = cal.plus(-100,2);//-98

My question is: Is it a reasonable design? comparing to: int plus(int a, int b, boolean useAbs, boolean checkArguments). Thanks!

score 5 · Accepted Answer · answered Apr 25 '11 at 15:30

Sounds like you want a fluent interface to build a service class. Guava does similar things. You'd do something like this:

public interface Cal {
   int plus(int a, int b);
}

public class CalBuilder {
    class InternalCal implements Cal {
       boolean useAbs;
       boolean checkArgs;
       public int plus(int a, int b) {
          if(checkArgs) {
             // blah, blah blah
          }
          if(useAbs) {
             // doodle bug, doodle darn
          }
          return a+b; // whatevs
       }
    }
    boolean absSet=false;
    InternalCal holder=new InternalCal();
    public CalBuilder useNormal() {
        if(absSet) { throw new IllegalArgumentException(); } // already called
        holder.useAbs=false;    
        absSet=true;
        return this;
    }

    public CalBuilder useAbs() {
        if(absSet) { throw new IllegalArgumentException(); } // already called
        holder.useAbs=false;    
        absSet=true;
        return this;
    }

    public CalBuilder checkArguments() {
       if(holder.checkArgs) { throw new IllegalArgumentException(); }
       holder.checkArgs=true;
       return this;
    }

    public Cal build() {
       return holder;
    }
}

Usage would look like this:

Cal cal=new CalBuilder().useAbs().checkArguments().build();
int sum=cal.plus(1,2);

Pretty sure that `CalBuilder` should be a `static` class, then it would be called like this: `Cal cal = new Cal.Builder()...` — Matt Ball, Apr 25 '11 at 15:59
You could do it a lot of ways, sure. You wouldn't normally want a builder to be static, however, because then you wouldn't be able to call it from multiple threads and you'd have things colliding with each others' state. — Joseph Ottinger, Apr 25 '11 at 16:05
I think you misunderstand me. The builder objects wouldn't be static, the `Builder` _class_ would be. See [Effective Java, Item 2](http://books.google.com/books?id=ka2VUBqHiWkC&lpg=PP1&dq=effective%20java&pg=PA11#v=onepage&q&f=false) (and/or [this answer](http://stackoverflow.com/questions/5007355#5007435)) — Matt Ball, Apr 25 '11 at 16:26

score 3 · Answer 2 · answered Apr 25 '11 at 15:27

3

This is called a fluent interface, and looks pretty reasonable to me.

One thing I might suggest changing is the name of the class: Calc is more obviously a calculator than Cal (which could be a calendar instead of a calculator).

answered Apr 25 '11 at 15:27

Matt Ball

354,903
100
647
710

1

`Calculator` would be even better. Full words are generally easier to read. If you want to name an instance of it `calc`, that's fine, but don't name the type that. – ColinD Apr 25 '11 at 16:01

Gabriel Llamas · Answer 3 · 2011-04-25T15:37:54.543

2

The best design is a simple design. What you are doing is obfuscating the code. It's more difficult to read and fix errors than the "plus(a, b, useAbs, checkArguments)". Also, in useNormal you are returning the same object than "new Cal ()" because you are overrididing the check(int) method and returning the parent's implementation with super.check(int)

edited Apr 25 '11 at 15:37

answered Apr 25 '11 at 15:31

Gabriel Llamas

18,244
26
87
112

Yes. In post, new Cal() is returned in useNormal. – 卢声远 Shengyuan Lu Apr 25 '11 at 15:40

score 1 · Answer 4 · answered Apr 25 '11 at 15:28

IMHO, this "chaining" approach is not that commonly used in Java, except in the case of Builders or things that are essentially builders.

What you're describing here is actually a calculator builder.

You should probably have a CalculatorBuilder class, which you instantiate, set multiple things (e.g., useAbs, checkArguments, etc.), and eventually call "build". Build will return a calculator that knows nothing about how it was built except for the state it was initialized with.

Also, I don't personally like a design that mixes builder-style logic (e.g., "useAbs"), and things that affect the state of the underlying object (such as checkArguments). I'd say pick one. Either generate a default calculator and set everything later, or have a builder that sets everything and then creates instances whose functionality and behavior cannot be changed.

The builder pattern is usually used to construct immutable objects and/or replace constructors with many (possibly optional) arguments. I don't see either of those here. — Matt Ball, Apr 25 '11 at 15:30
I disagree - at least from his example it seems like each calculator operates in a completely different way, there is no benefit for letting a calculator change its state — Uri, Apr 25 '11 at 16:16

Chain style method design

4 Answers4