We've all been there, you start with a class and a simple constructor that makes total sense. As time goes by, you keep adding features and the list of constructor arguments grows … and grows … until … it becomes unusable. This is exactly what happened with the Cache class in Ehcache.

The version 1.0 constructor looked like this:

However, with version 1.7 this turned into:

There are a lot of downsides to relying on constructor parameters like this:

• the author of the class needs to continue to overload the constructors to add new parameters
• users need to decide which overloaded constructor they want to use
• users need to figure out what sensible default values are for the values that they're not interested in
• it's very easy to accidentally put a value at the wrong place and provide wrong parameters
• reading the constructor afterwards is a nightmare and can't be done without looking at the Javadocs at the same time, for instance:

However there some advantages:

• you can enforce which parameters are mandatory
• at instantiation you can validate the constructor parameters
• at instantiation you fully set up the instance without requiring users to call an initialization method

So, we decided to change the Cache constructor approach in Ehcache 2.0 and use a builder pattern with a fluent interface, keeping the advantages of the parameters approach but solving all the problems.

The version 2.0 constructor looks like this:

We then created a constructor in CacheConfigurator with the strict minimal number of parameters that are required for a cache to function:

All the other parameters are implemented as fluent interface methods as well as regular setters and getters so that instances of the class can be used as beans:

This allows the example above to be rewritten like this:

The end results are that:

• we can continue to expand the CacheConfiguration class without ever having to change the constructors of the Cache class
• the user doesn't have to figure out the defaults for parameters he doesn't care about
• the configuration parameters are self-explanatory by simply looking at the available API methods
• anyone can read the usage of any Cache constructor and understand what each configuration value's purpose is