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?
Supposed arg1 is mandatory and rest (arg2 and arg3) are optional.
we can have methods such as :
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 ?
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.
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.
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.
Monica Shiralkar wrote: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.
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.
My approach to optional parameters is usually to only add one extra parameter per overload, and keep the order fixed:
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:
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.
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
The last would be better in a language with named parameter invocation, e.g. Kotlin's
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.
How do they get the deer to cross at the signs? Or to read this tiny ad?
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth