overloaded methods for every possible permutation combination with optional arguments

[Monica Shiralkar]

In case we have a method myMethod which has say 3 arguments out of those 2 are optional, then does one have to create overoaded methods for every possible permutation combination with the optional arguments?

void myMethod( String arg1, String arg2, String arg3)
{
//
}

Supposed arg1 is mandatory and rest (arg2 and arg3) are optional.

we can have methods such as :

void myMethod( String arg1, String arg2, String arg3)
{
//
}


void myMethod( String arg1, String arg2)
{
//
}

void myMethod( String arg1, String arg3)
{
//
}

This covers all possible combinations. Suppose the number of optional arguments is even more. Then does one have to create overloaded methods for every possible permutation combination ?

Thanks.

[Carey Brown]

Methods on lines 7 & 12 are the same from the compiler's point of view because they have "the same signature". That is, they both take two Strings as arguments. The compiler doesn't care what the argument names are only the types.

[Carey Brown]

You might consider only having the method that takes three arguments and allow some to accept null as the value.

[Jesse Silverman]

Someone's been spoiled by Default Parameters in Other Languages!

[Paul Clapham]

Do those methods (however many they are) have to be overloaded methods? I'm probably missing something but I don't see a big benefit gained from making them overloaded. Whereas making four methods with different names compiles correctly and they can be made to sort things out internally and then call a common private method to do the actual work.

[Campbell Ritchie]

Paul Clapham wrote:. . . I don't see a big benefit gained from making them overloaded. . . .

I can see a big problem; overloading those method names (the Java® Language Specification doesn't say method overloading) can cause confusion to users. Paul C is right: give the methods different names.

[Norm Radder]

Would varargs be useful here?

   void myMethod( String... args) {

[Monica Shiralkar]

Carey Brown wrote:You might consider only having the method that takes three arguments and allow some to accept null as the value.

Thanks.

This way I will have only 1 method. But inside the method will I still need to have all possible permutation combinations ?

e.g Supposed arg2 and arg3 are optional arguments which can accept null

void myMethod( String arg1, String arg2, String arg3)
{

if(arg2 ==null && arg3 ==null)
//doSomething1
else
if(arg2==null && arg3!=null)
//doSomething2

// and so on


}

As the number of optional arguments increase will the set of all permutation combination of case statements become too big?

[Carey Brown]

Monica Shiralkar wrote:

void myMethod( String arg1, String arg2, String arg3)
{
if(arg2 ==null && arg3 ==null)
//doSomething1
else
if(arg2==null && arg3!=null)
//doSomething2

// and so on
}

As the number of optional arguments increase will the set of all permutation combination of case statements become too big?

That supposes that there is a tight inter relationship between all the arguments. Often each argument deals with a single aspect of functionality.

void myMethod( String arg1, String arg2, String arg3)
{
if( arg2 != null ) {
    // do something with arg2
}

if( arg3 != null ) {
    // do something with arg3
}

// and so on
}

If you really have a combinatorial explosion like you're indicating then it's time to reanalyze your approach. At this point we are talking in generalizations, to get to anything more specific we'd need to see some requirements or some pseudo code.

[Stephan van Hulst]

My approach to optional parameters is usually to only add one extra parameter per overload, and keep the order fixed:

void doSomething(Foo mandatory1)

void doSomething(Foo mandatory1, Bar optional1)

void doSomething(Foo mandatory1, Bar optional1, Baz optional2)

This means that if you want to specify a non-default value for optional2, but not for optional1, you're out of luck. The reason I don't add another overload that takes only Foo mandatory and Baz optional2 is because it makes your API confusing to use and hard to memorize.

If you have more than two optional parameters, or you really want the user to be able to specify a non-default value for optional2 while keeping the default value for optional1, use an object that encapsulates the method arguments:

void doSomething(SomeMethodArguments arguments) {
  //
}

final class SomeMethodArguments {

  private final Foo mandatory1;

  private Bar optional1;

  private Baz optional2;

  private Qub optional3;

  SomeMethodArguments(Foo mandatory1) {
    this.mandatory1 = mandatory1;
    this.optional1  = ... ;
    this.optional2  = ... ;
    this.optional3  = ... ;
  }

  SomeMethodArguments setOptional1(Bar optional1) {
    this.optional1 = optional1;
  }

  SomeMethodArguments setOptional2(Baz optional2) {
    this.optional2 = optional2;
  }

  SomeMethodArguments setOptional3(Qub optional3) {
    this.optional3 = optional3;
  }
}

var arguments = new SometMethodArguments(foo)
  .setOptional2(baz)
  .setOptional3(qub);

doSomething(arguments);

[Campbell Ritchie]

I know I am a bit late to the party, but why would you want optional arguments in the first place? It looks very iffy design to me.
I like Stephan's approach. If you insist on multiple argument types, you are risking using varargs like foo(Object... ags) ..., but that looks to me like a recipe for trouble.

[Mike Simmons]

First,  it looks like all the examples in this thread are using combinations, not permutations.  Using different permutations of the same combination would be a very bad idea, I think - very confusing, and leading to way too many method overloads.

I agree with Stephan's approach.  Use a limited number of overloads and a very consistent order, so there's no confusion.

I would (almost) never advocate using varargs of a more general type to handle different argument orders.  With default arguments you usually want the different types of the argument to make it obvious which overload is being called - you don't want people switching the order around and still getting a valid vararg call.  That's very confusing.

Why would you want optional arguments in the first place?  Well, to avoid needing to spell out every parameter in cases where it's usually not needed.  A good example is something like Collectors.joining(), where you most always want to specify the delimiter you're joining with, but often don't want or need to specify a prefix and suffix.  So you can have things like

var string1 = stream1.collect(Collectors.joining(","));
var string2 = stream2.collect(Collectors.joining("\n"));
var string3 = stream3.collect(Collectors.joining(",","[","]"));

The last would be better in a language with named parameter invocation, e.g. Kotlin's

var string3 = stream3.join(",", prefix="[", suffix="]");

This is a case where a little more verbosity really helps readability, I think.  The later parameters in a method with defaults are usually the ones that aren't used as much, so people may not remember what they are.  It's nice to be able to spell those out if you want to.