{"id":18153,"date":"2018-05-03T08:37:50","date_gmt":"2018-05-03T13:37:50","guid":{"rendered":"https:\/\/stackify.com\/?p=18153"},"modified":"2024-04-10T05:56:40","modified_gmt":"2024-04-10T05:56:40","slug":"optional-parameters-java","status":"publish","type":"post","link":"https:\/\/stackify.com\/optional-parameters-java\/","title":{"rendered":"Optional Parameters in Java: Common Strategies and Approaches"},"content":{"rendered":"

Introduction to optional parameters in Java <\/strong><\/h3>\n

Unlike some languages such as Kotlin and Python, Java doesn’t provide built-in support for optional<\/a> parameter values. Callers of a method must supply all of the variables defined in the method declaration.<\/p>\n

In this article, we’ll explore some strategies for dealing with optional parameters in Java<\/a>. We’ll look at the strengths and weaknesses of each approach and highlight the trade-offs involved with selecting one strategy over another.<\/p>\n

Example overview<\/strong><\/h3>\n

Let’s consider a simple MultiVitamin <\/i>class for our use here:<\/p>\n

public class MultiVitamin {\n\n    private String name;    \/\/ required\n    private int vitaminA;   \/\/ in mcg\n    private int vitaminC;   \/\/ in mg\n    private int calcium;    \/\/ in mg\n    private int iron;       \/\/ in mg\n\n    \/\/ constructor(s)\n}\n<\/pre>\n
The logic responsible for creating new instances of a MultiVitamin<\/em> for men may, for example, need to supply a larger value for iron. Instances of a MultiVitamin<\/em> for women might require more calcium. Essentially, each variant supported by the system might require values for some parameters but would prefer to supply known default values for the optional ones.<\/p>\n
Constraining how instances can be created can generally lead to APIs that are easier to read and use as intended.<\/p>\n
Method overloading \/ telescoping constructors<\/strong><\/h3>\n
When working with optional parameters, method overloading is one of the more obvious and common approaches available.<\/p>\n
The idea here is that we start with a method that only takes the required parameters. We provide an additional method which takes a single optional parameter. We then provide yet another method which takes two of these parameters, and so on.<\/p>\n
The methods which take fewer parameters supply default values for the more verbose signatures:<\/p>\n
static final int DEFAULT_IRON_AMOUNT = 20;\n\n\/\/ instance fields\n\npublic MultiVitaminOverloading(\n  String name) {\n    this(name, 0);\n}\n\npublic MultiVitaminOverloading(\n  String name, int vitaminA) {\n    this(name, vitaminA, 0);\n}\n\npublic MultiVitaminOverloading(\n  String name, int vitaminA, int vitaminC) {\n    this(name, vitaminA, vitaminC, 0);\n}\n\npublic MultiVitaminOverloading(\n  String name, int vitaminA, int vitaminC, int calcium) {\n    this(name, vitaminA, vitaminC, calcium, DEFAULT_IRON_AMOUNT);\n}\n\npublic MultiVitaminOverloading (\n  String name, \n  int vitaminA, \n  int vitaminC, \n  int calcium, \n  int iron) {\n    this.name = name;\n    this.vitaminA = vitaminA;\n    this.vitaminC = vitaminC;\n    this.calcium = calcium;\n    this.iron = iron;\n}\n\n\/\/ getters<\/pre>\n
We can observe the telescoping<\/em> property of these signatures in this example; they flow to the right as we’re adding more parameters.<\/p>\n
The simplicity and familiarity of the method overloading approach make it a good choice for use cases with a small number of optional parameters<\/strong>. We can extract default values for any optional parameters to a named constant to improve readability as we’ve done here with DEFAULT_IRON_AMOUNT<\/em>.<\/p>\n
Also, note that using this approach does not prevent us from making the class immutable. We can ensure that instances of the class are thread-safe and always in a consistent state by declaring the instance fields as final and only providing getters.<\/span><\/p>\n
The main downside of using this approach is that it does not scale well – as the number of parameters increases.<\/strong> MultiVitaminOverloading<\/em> is already difficult to read and maintain with only four optional parameters. <\/span><\/p>\n
This only gets worse with the fact that our optional parameters are of the same type. Clients could easily order the parameters wrongly – such a mistake would not be noticed by the compiler and would likely result in a subtle bug at runtime.<\/p>\n
Consider using this if the number of optional parameters is small and if the risk of callers supplying parameters in the wrong order is minimal.<\/p>\n
Static factory methods<\/strong><\/h3>\n
Joshua Bloch, in his book – Effective Java, recommends in Item 1, to “…consider static factory methods instead of constructors.” With this approach, static methods with particular names can be used instead of public constructors to clarify the API<\/strong> used for instance creation:<\/p>\n
\/\/ constants\n\n\/\/ instance fields\n\npublic static MultiVitaminStaticFactoryMethods forMen(String name) {\n    return new MultiVitaminStaticFactoryMethods(\n      name, 5000, 60, CALCIUM_AMT_DEF, IRON_AMT_MEN);\n}\n\npublic static MultiVitaminStaticFactoryMethods forWomen(String name) {\n    return new MultiVitaminStaticFactoryMethods(\n      name, 5000, 60, CALCIUM_AMT_WOMEN, IRON_AMT_DEF);\n}\n\nprivate MultiVitaminStaticFactoryMethods(\n  String name, \n  int vitaminA, \n  int vitaminC, \n  int calcium, \n  int iron) {\n    this.name = name;\n    this.vitaminA = vitaminA;\n    this.vitaminC = vitaminC;\n    this.calcium = calcium;\n    this.iron = iron;\n}\n\n\/\/ getters<\/pre>\n
The idea here is to carefully pair method names with signatures so that the intention is obvious<\/strong>. We define one or more private constructors, and call them only by the named factory methods.<\/p>\n
By making our constructors private, the caller must make an explicit choice of signature based on the desired parameters. The author then has complete control over which methods to provide, how to name them, and what defaults will the parameters, that are not supplied by the caller, have.<\/p>\n
While simple to implement and understand, this approach also does not scale well<\/strong> with a large number of optional parameters.<\/p>\n
This strategy is often the best choice if the number of optional parameters is small and if we can choose descriptive names for each variant.<\/p>\n
The Builder pattern approach<\/strong><\/h3>\n
The Builder pattern is another way of handling optional parameters but takes a little bit of work to set up.<\/p>\n
We start by defining our class with a private constructor but then introduce a static nested class to function as a builder. The builder class exposes methods for setting parameters and for building the instance.<\/p>\n
Creating instances of the class involves making use of the builder’s fluent API – passing in the mandatory parameters, setting any optional parameters, and calling the build()<\/em><\/strong> method:<\/p>\n
MultiVitaminWithBuilder vitamin \n  = new MultiVitaminWithBuilder.MultiVitaminBuilder(\"Maximum Strength\")\n    .withCalcium(100)\n    .withIron(200)\n    .withVitaminA(50)\n    .withVitaminC(1000)\n    .build();<\/pre>\n
We can now define our MultiVitaminBuilder<\/em> as a static nested class of the enclosing type.<\/p>\n
This allows us to keep the constructor of the enclosing type private and forces callers to use the builder:<\/p>\n
public static class MultiVitaminBuilder {\n    private static final int ZERO = 0;\n    private final String name; \/\/ required\n    private final int vitaminA = ZERO;\n    \/\/ other params\n\n    public MultiVitaminBuilder(String name) {\n        this.name = name;\n    }\n\n    public MultiVitaminBuilder withVitaminA(int vitaminA) {\n        this.vitaminA = vitaminA;\n        return this;\n    }\n    \n    \/\/ other fluent api methods\n\n    public MultiVitaminWithBuilder build() {\n        return new MultiVitaminWithBuilder(this);\n    }\n}<\/pre>\n
One of the main advantages of the builder pattern is that it scales well with large numbers of optional and mandatory parameters<\/strong>.<\/p>\n
In our example here, we require the mandatory parameter in the constructor of the builder. We expose all of the optional parameters in the rest of the builder’s API.<\/p>\n
Another advantage is that it’s much more difficult to make a mistake<\/strong> when setting values for optional parameters. We have explicit methods for each optional parameter, and we don’t expose callers to bugs that can arise due to calling methods with parameters that are in the wrong order.<\/p>\n
Lastly, the builder approach cleanly provides us with a finely grained level of control over validation. With our builder, we know the instance we create is in a valid state and we won’t be able to alter it.<\/p>\n
The most obvious downside to using a builder is that it’s way more complicated to set up<\/strong>. The purpose of the construct might not be immediately apparent to a novice developer.<\/p>\n
The builder pattern should be considered for use cases involving a large number of mandatory and optional parameters. Additionally, consider this strategy when supplied values are well-served by fine-grained validation or other constraints.<\/strong><\/p>\n
For detailed sample code and a more thorough walkthrough of this strategy, check out this article on creational patterns<\/a>.<\/p>\n
Mutability with accessors<\/strong><\/h3>\n
Using standard getters and setters is a simple way to work with an object that has optional instance parameters.<\/p>\n
We’re using a default constructor with mandatory parameters to create the object.<\/p>\n
We’re then invoking the setter methods to set the value of each optional parameter as needed. We can set the default values for optional parameters within a constructor, if necessary:<\/p>\n
public class MultiVitamin {\n\n    private String name;    \/\/ required\n    private int vitaminA;   \/\/ in mcg\n\n    \/\/ other instance params\n\n    public MultiVitamin(String name) {\n        this.name = name;\n    }\n\n    public String getName() {\n        return name;\n    }\n\n    public int getVitaminA() {\n        return vitaminA;\n    }\n\n    public void setVitaminA(int vitaminA) {\n        this.vitaminA = vitaminA;\n    }\n\n    \/\/ other getters and setters\n}<\/pre>\n
This approach is the ubiquitous JavaBeans <\/em>pattern and is likely the simplest strategy available for working with optional parameters<\/strong>. There are two key strengths this approach has over alternatives.<\/p>\n
The pattern is arguably the most familiar of them all. Nearly all modern IDE’s can automatically generate the necessary code given the class definition.<\/p>\n
There are, unfortunately, serious drawbacks to using this approach, especially if thread safety is a concern<\/strong>. The use of this pattern requires that the object is mutable since we can change it after its creation.<\/p>\n
Since the creation of the instance and setting of its state are decoupled and do not occur atomically, it’s possible that the instance could be used before it’s in a valid state. In a sense, we’re splitting the construction of the object over multiple calls.<\/p>\n
You can consider this pattern when thread safety and creating a robust API isn’t a primary concern.<\/p>\n
Allowing nulls<\/strong><\/h3>\n
It’s typically a bad idea to allow method callers to supply null values and this widely considered an anti-pattern.<\/p>\n
For the sake of demonstration, let’s see what this looks like in practice:<\/p>\n
MultiVitaminAllowingNulls vitamin \n  = new MultiVitaminAllowingNulls(\"Unsafe Vitamin\", null, null, null, null);<\/pre>\n
The strategy of allowing nulls for optional parameters offers nothing when compared to alternatives. In order to be sure that nulls are allowed, the caller needs to know the implementation details of the class. This fact alone makes this strategy a poor choice.<\/p>\n
Also, the code itself does not read well. Simply put, you should avoid this pattern whenever possible.<\/strong><\/p>\n
Varargs<\/strong><\/h3>\n
Java 5 added variable-length arguments to<\/span> provide a way of to declare that a method accepts 0 or more arguments of a specified type. There are certain restrictions on the usage of varags that are in place to avoid ambiguity:<\/p>\n