In this seventh post of my series on addressing the issue of too many parameters in a Java method or constructor, I look at using state to reduce the need to pass parameters. One of the reasons I have waited until the 7th post of this series to address this is that it is one of my least favorite approaches for reducing parameters passed to methods and constructors. That stated, there are multiple flavors of this approach and I definitely prefer some flavors over others.
Perhaps the best known and most widely scorned approach in all of software development for using state to reduce parameter methods is the use global variables. Although it may be semantically accurate to say that Java does not have global variables, the reality is that for good or for bad the equivalent of global variables is achieved in Java via public static constructs. A particularly popular way to achieve this in Java is via the Stateful Singleton.
In Patterns of Enterprise Application Architecture, Martin Fowler wrote that “any global data is always guilty until proven innocent.” Global variables and “global-like” constructs in Java are considered bad form for several reasons. They can make it difficult for developers maintaining and reading code to know where the values are defined or last changed or even come from. By their very nature and intent, global data violates the principles of encapsulation and data hiding.
Miško Hevery has written the following regarding the problems of static globals in an object-oriented language:
Accessing global state statically doesn’t clarify those shared dependencies to readers of the constructors and methods that use the Global State. Global State and Singletons make APIs lie about their true dependencies. … The root problem with global state is that it is globally accessible. In an ideal world, an object should be able to interact only with other objects which were directly passed into it (through a constructor, or method call).
Having state available globally reduces the need for parameters because there is no need for one object to pass data to another object if both objects already have direct access to that data. However, as Hevery put it, that’s completely orthogonal to the intent of object-oriented design.
Mutable state is also an increasing problem as concurrent applications become more common. In his JavaOne 2012 presentation on Scala, Scala creator Martin Odersky stated that “every piece of mutable state you have is a liability” in a highly concurrent world and added that the problem is “non-determinism caused by concurrent threads accessing shared mutable state.”
Although there are reasons to avoid mutable state, it still remains a generally popular approach in software development. I think there are several reasons for this including that it’s superfically easy to write mutable state sharing code and mutable shared code does provide ease of access. Some types of mutable data are popular because those types of mutable data have been taught and learned as effective for years. Finally, three are times when mutable state may be the most appropriate solution. For that last reason and to be complete, I now look at how the use of mutable state can reduce the number of parameters a method must expect.
Stateful Singleton and Static Variables
A Java implementation of Singleton and other public Java static fields are generally available to any Java code within the same Java Virtual Machine (JVM) and loaded with the same classloader [for more details, see When is a Singleton not a Singleton?].
Any data stored universally (at least from JVM/classloader perspective) is already available to client code in the same JVM and loaded with the same class loader. Because of this, there is no need to pass that data between clients and methods or constructors in that same JVM/classloader combination.
Instance State
While “statics” are considered “globally available,” narrower instance-level state can also be used in a similar fashion to reduce the need to pass parameters between methods of the same class. An advantage of this over global variables is that the accessibility is limited to instances of the class (private fields) or instances of the class’s children (private fields). Of course, if the fields are public, accessibility is pretty wide open, but the same data is not automatically available to other code in the same JVM/classloader.
The next code listing demonstrates how state data can and sometimes is used to reduce the need for parameters between two methods internal to a given class.
Example of Instance State Used to Avoid Passing Parameters
/**
* Simple example of using instance variable so that there is no need to
* pass parameters to other methods defined in the same class.
*/
public void doSomethingGoodWithInstanceVariables()
{
this.person =
Person.createInstanceWithNameAndAddressOnly(
new FullName.FullNameBuilder(new Name("Flintstone"), new Name("Fred")).createFullName(),
new Address.AddressBuilder(new City("Bedrock"), State.UN).createAddress());
printPerson();
}
/**
* Prints instance of Person without requiring it to be passed in because it
* is an instance variable.
*/
public void printPerson()
{
out.println(this.person);
}The above example is somewhat contrived and simplified, but does illustrate the point: the instance variable person can be accessed by other instance methods defined in the same class, so that instance does not need to be passed between those instance methods. This does reduce the signature of potentially (public accessibility means it may be used by external methods) internal methods, but also introduces state and now means that the invoked method impacts the state of that same object. In other words, the benefit of not having to pass the parameter comes at the cost of another piece of mutable state. The other side of the trade-off, needing to pass the instance of Person because it is not an instance variable, is shown in the next code listing for comparison.
Example of Passing Parameter Rather than Using Instance Variable
/**
* Simple example of passing a parameter rather than using an instance variable.
*/
public void doSomethingGoodWithoutInstanceVariables()
{
final Person person =
Person.createInstanceWithNameAndAddressOnly(
new FullName.FullNameBuilder(new Name("Flintstone"), new Name("Fred")).createFullName(),
new Address.AddressBuilder(new City("Bedrock"), State.UN).createAddress());
printPerson(person);
}
/**
* Prints instance of Person that is passed in as a parameter.
*
* @param person Instance of Person to be printed.
*/
public void printPerson(final Person person)
{
out.println(person);
}The previous two code listings illustrate that parameter passing can be reduced by using instance state. I generally prefer to not use instance state solely to avoid parameter passing. If instance state is needed for other reasons, than the reduction of parameters to be passed is a nice side benefit, but I don’t like introducing unnecessary instance state simply to remove or reduce the number of parameters. Although there was a time when the readability of reduced parameters might have justified instance state in a large single-threaded environment, I feel that the slight readability gain from reduced parameters is not worth the cost of classes that are not thread-safe in an increasingly multi-threaded world. I still don’t like to pass a whole lot of parameters between methods of the same class, but I can use the parameters object (perhaps with a package-private scope class) to reduce the number of these parameters and pass that parameters object around instead of the large number of parameters.
JavaBean Style Construction
The JavaBeans convention/style has become extremely popular in the Java development community. Many frameworks such as Spring Framework and Hibernate rely on classes adhering to the JavaBeans conventions and some of the standards like Java Persistence API also are built around the JavaBeans conventions. There are multiple reasons for the popularity of the JavaBeans style including its ease-of-use and the ability to use reflection against this code adhering to this convention to avoid additional configuration.
The general idea behind the JavaBean style is to instantiate an object with a no-argument constructor and then set its fields via single-argument “set” methods and access it fields via no-argument “get” methods. This is demonstrated in the next code listings. The first listing shows a simple example of a PersonBean class with no-arguments constructor and getter and setter methods. That code listing also includes some of the JavaBeans-style classes it uses. That code listing is followed by code using that JavaBean style class.
Examples of JavaBeans Style Class
public class PersonBean
{
private FullNameBean name;
private AddressBean address;
private Gender gender;
private EmploymentStatus employment;
private HomeownerStatus homeOwnerStatus;
/** No-arguments constructor. */
public PersonBean() {}
public FullNameBean getName()
{
return this.name;
}
public void setName(final FullNameBean newName)
{
this.name = newName;
}
public AddressBean getAddress()
{
return this.address;
}
public void setAddress(final AddressBean newAddress)
{
this.address = newAddress;
}
public Gender getGender()
{
return this.gender;
}
public void setGender(final Gender newGender)
{
this.gender = newGender;
}
public EmploymentStatus getEmployment()
{
return this.employment;
}
public void setEmployment(final EmploymentStatus newEmployment)
{
this.employment = newEmployment;
}
public HomeownerStatus getHomeOwnerStatus()
{
return this.homeOwnerStatus;
}
public void setHomeOwnerStatus(final HomeownerStatus newHomeOwnerStatus)
{
this.homeOwnerStatus = newHomeOwnerStatus;
}
}
/**
* Full name of a person in JavaBean style.
*
* @author Dustin
*/
public final class FullNameBean
{
private Name lastName;
private Name firstName;
private Name middleName;
private Salutation salutation;
private Suffix suffix;
/** No-args constructor for JavaBean style instantiation. */
private FullNameBean() {}
public Name getFirstName()
{
return this.firstName;
}
public void setFirstName(final Name newFirstName)
{
this.firstName = newFirstName;
}
public Name getLastName()
{
return this.lastName;
}
public void setLastName(final Name newLastName)
{
this.lastName = newLastName;
}
public Name getMiddleName()
{
return this.middleName;
}
public void setMiddleName(final Name newMiddleName)
{
this.middleName = newMiddleName;
}
public Salutation getSalutation()
{
return this.salutation;
}
public void setSalutation(final Salutation newSalutation)
{
this.salutation = newSalutation;
}
public Suffix getSuffix()
{
return this.suffix;
}
public void setSuffix(final Suffix newSuffix)
{
this.suffix = newSuffix;
}
@Override
public String toString()
{
return this.salutation + " " + this.firstName + " " + this.middleName
+ this.lastName + ", " + this.suffix;
}
}
package dustin.examples;
/**
* Representation of a United States address (JavaBeans style).
*
* @author Dustin
*/
public final class AddressBean
{
private StreetAddress streetAddress;
private City city;
private State state;
/** No-arguments constructor for JavaBeans-style instantiation. */
private AddressBean() {}
public StreetAddress getStreetAddress()
{
return this.streetAddress;
}
public void setStreetAddress(final StreetAddress newStreetAddress)
{
this.streetAddress = newStreetAddress;
}
public City getCity()
{
return this.city;
}
public void setCity(final City newCity)
{
this.city = newCity;
}
public State getState()
{
return this.state;
}
public void setState(final State newState)
{
this.state = newState;
}
@Override
public String toString()
{
return this.streetAddress + ", " + this.city + ", " + this.state;
}
}Example of JavaBeans Style Instantiation and Population
public PersonBean createPerson()
{
final PersonBean person = new PersonBean();
final FullNameBean personName = new FullNameBean();
personName.setFirstName(new Name("Fred"));
personName.setLastName(new Name("Flintstone"));
person.setName(personName);
final AddressBean address = new AddressBean();
address.setStreetAddress(new StreetAddress("345 Cave Stone Road"));
address.setCity(new City("Bedrock"));
person.setAddress(address);
return person;
}The examples just shown demonstrate how the JavaBeans style approach can be used. This approach makes some concessions to reduce the need to pass a large number of parameters to a class’s constructor. Instead, no parameters are passed to the constructor and each individual attribute that is needed must be set. One of the advantages of the JavaBeans style approach is that readability is enhanced as compared to a constructor with a large number of parameters because each of the “set” methods is hopefully named in a readable way.
The JavaBeans approach is simple to understand and definitely achieves the goal of reducing lengthy parameters in the case of constructors. However, there are some disadvantages to this approach as well. One advantage is a lot of tedious client code for instantiating the object and setting its attributes one-at-a-time. It is easy with this approach to neglect to set a required attribute because there is no way for the compiler to enforce all required parameters be set without leaving the JavaBeans convention. Perhaps most damaging, there are several objects instantiated in this last code listing and these objects exist in different incomplete states from the time they are instantiated until the time the final “set” method is called. During that time, the objects are in what is really an “undefined” or “incomplete” state. The existence of “set” methods necessarily means that the class’s attributes cannot be final, rendering the entire object highly mutable.
Regarding the prevalent use of the JavaBeans pattern in Java, several credible authors have called into question its value. Allen Holub’s controversial article Why getter and setter methods are evil starts off with no holds barred:
Though getter/setter methods are commonplace in Java, they are not particularly object oriented (OO). In fact, they can damage your code’s maintainability. Moreover, the presence of numerous getter and setter methods is a red flag that the program isn’t necessarily well designed from an OO perspective.
Josh Bloch, in his less forceful and more gently persuasive tone, says of the JavaBeans getter/setter style: “The JavaBeans pattern has serious disadvantages of its own” (Effective Java, Second Edition, Item #2). It is in this context that Bloch recommends the builder pattern instead for object construction.
I’m not against using the JavaBeans get/set style when the framework I’ve selected for other reasons requires it and the reasons for using that framework justify it. There are also areas where the JavaBeans style class is particularly well suited such as interacting with a data store and holding data from the data store for use by the application. However, I am not a fan of using the JavaBeans style for instantiating a question simply to avoid the need to pass parameters. I prefer one of the other approaches such as builder for that purpose.
Benefits and Advantages
I’ve covered different approaches to reducing the number of arguments to a method or constructor in this post, but they also share the same trade-off: exposing mutable state to reduce or eliminate the number of parameters that must be passed to a method or to a constructor. The advantages of these approaches are simplicity, generally readable (though “globals” can be difficult to read), and ease of first writing and use. Of course, their biggest advantage from this post’s perspective is that they generally eliminate the need for any parameter passing.
Costs and Disadvantages
The trait that all approaches covered in this post share is the exposure of mutable state. This can lead to an extremely high cost if the code is used in a highly concurrent environment. There is a certain degree of unpredictability when object state is exposed for anyone to tinker with it as they like. It can be difficult to know which code made the wrong change or failed to make a necessary change (such as failing to call a “set” method when populating a newly instantiated object).
Conclusion
Even some of the approaches to reducing parameters that I have covered earlier (such as custom types and parameters objects) can be implemented in such a way that there is (optional) mutable state, but those approaches do not require mutable state. In contrast, the approaches covered in this post to reducing parameters to methods and constructors do require mutable state.
Some of the approaches covered in this post are highly popular despite their drawbacks. This may be for a variety of reasons including prevalence of use in popular frameworks (forcing users of the framework to use that style and also providing examples to others for their own code development). Other reasons for these approaches’ popularity is the relative ease of initial development and the seemingly (deceptively) relatively little thought that needs to go into design with these approaches. In general, I prefer to spend a little more design and implementation effort to use builders and less mutable approaches when practical. However, there are cases where these mutable state approaches work well in reducing the number of parameters passed around and introduce no more risk than was already present. My feeling is that Java developers should carefully consider use of any mutable Java classes and ensure that the mutability is either desired or is a cost that is justified by the reasons for using a mutable state approach.
