How to extend the following API function in java and not lead to ambiguous

Question

I have some existing overloading API:

1). foo(a, b) { return foo(a, b, null); }
2). foo(a, b, c) {return foo(a,b,c,null);}
3). foo(a, b, c, d) { implement of the function...; }

Where a, b, c are some data structure the value of which can be null as well. now I need to extend the APIs with a flag. i.e.

4). foo(a, b, Boolean flag)
5). foo(a, b, c, Boolean flag)
6). foo(a, b, c, d, Boolean flag)

Where Boolean can be null/false/true; the existing APIs should exist still for compatability.

The problem is: 2) and 4) are ambiguous when foo(a, b, null) is called. same thing for 3) and 5).

My question: How in general we should extent the new API?

Answer 1

If you use Java 8, you should use OptionalBoolean instead of Boolean. It is not as good as its companions Optional<>, OptionalInt, OptionalDouble etc., but in this case, it might be a real benefit.

As the mentionned OptionalBoolean is indeed from com.sun.javafx.scene.control.behavior.OptionalBoolean, there might be a better alternative.

I personally try to refrain from using null where there are better options.

Instead of

class Foo {
    Bar s; // whatever Bar is...
    Foo() {
        Foo(null)
    }

    Foo(Bar s) {
        this.s = s;
    }

    public void doStuff() {
        if (s != null) {
            bar.frobnicate();
        }
    }
}

it might be better to have

class Foo {
    Bar s; // whatever Bar is...
    Foo() {
        Foo(Bar.EMPTY_VALUE)
    }

    Foo(Bar s) {
        this.s = s;
    }

    public void doStuff() {
        bar.frobnicate();
    }
}

with Bar having a

public final static EMPTY_VALUE = new Bar() {
    // redefine it so that frobnicate() just does nothing.
    // This way, EMPTY_VALUE can be used wherever appropriate
}

This is called the Null Object pattern. While it doesn't directly address your problem, it resolves the ambiguities you have by using null here and there.

---

Another way to resolve them could be to have every constructor call the "main constructor" directly.

This way you could have

foo(a, b) { return foo(a, b, null, null); }
foo(a, c) { return foo(a, null, c, null); }
foo(a, b, c) {return foo(a,b,c,null);}
foo(a, b, d) {return foo(a,b,null, c);}
foo(a, b, c, d) { implement of the function...; }

It might as well be clearer to read.

Answer 2

a) You could give the new methods a different name. fooWithFlag

b) You could not allow null (presumably it does the same thing as the previous methods without the flag), and use a primitive boolean instead

c) You could create a sub-interface ServiceWithFlags or ServiceV2 and put the new methods only on that. New code can make use of it by using the new interface, old code still uses the old interface and won't see the methods.

d) This is only a compile-time error. This will not break things for already compiled code. So you could actually go ahead and add your new methods. Any ambiguity will be caught by the compiler and is easily fixed during development.

Answer 3

Instead of just a boolean flag you could use an Enum as Flag with the three states.

Answer 4

Answer my question:

I think calling in this way will avoid ambiguous: for 2) foo(a, b, c) and 4) foo(a, b, Boolean) if I call in this way: foo(x, y, Boolean(null)) in stead of foo(x, y, null), then ambiguous will be avoided.