The builder patten is often used to construct objects with many properties. It makes it easier to read initialisations by having parameters named at the callsite, while helping you only allow the construction of valid objects.<\/p>\n
Builder implementations tend to either rely on the constructed object being mutable, and setting fields as you go, or on duplicating all the settable fields within the builder.<\/p>\n
Since Java 8, I find myself frequently creating lightweight builders by defining an interface for each initialisation stage. <\/p>\n
Let’s suppose we have a simple immutable Person type like <\/p>\n
\r\nstatic class Person {\r\n public final String firstName;\r\n public final String lastName;\r\n public final Centimetres height;\r\n\r\n private Person(String firstName, String lastName, Centimetres height) {\r\n this.firstName = firstName;\r\n this.lastName = lastName;\r\n this.height = height;\r\n }\r\n}\r\n<\/pre>\nI’d like to be able to construct it using a builder, so I can see at a glance which parameter is which.<\/p>\n
\r\nPerson benji = person()\r\n .firstName(\"benji\")\r\n .lastName(\"weber\")\r\n .height(centimeters(182));\r\n<\/pre>\nAll that is needed to support this now is 3 single-method interfaces to define each stage, and a method to create the builder<\/p>\n
The three interfaces are as follows. Each has a single method, so is compatible with a lambda, and each method returns another single method interface. The final interface returns our completed Person type.<\/p>\n
\r\ninterface FirstNameBuilder {\r\n LastNameBuilder firstName(String firstName);\r\n}\r\ninterface LastNameBuilder {\r\n HeightBuilder lastName(String lastName);\r\n}\r\ninterface HeightBuilder {\r\n Person height(Centimetres height);\r\n}\r\n<\/pre>\nNow we can create a person() method which creates the builder using lambdas. <\/p>\n
\r\npublic static FirstNameBuilder person() {\r\n return firstName -> lastName -> height -> new Person(firstName, lastName, height);\r\n}\r\n<\/pre>\nWhile it is still quite verbose, this builder definition is barely longer than simply adding getters for each of the fields.<\/p>\n
Suppose we wanted to be able the give people’s height in millimetres as well as centimetres. We could simply add a default method to the HeightBuilder interface that does the conversion.<\/p>\n
\r\ninterface HeightBuilder {\r\n Person height(Centimetres height);\r\n default Person height(MilliMetres millis) {\r\n return height(millis.toCentimetres());\r\n }\r\n}\r\n<\/pre>\nWe can use the same approach to present different construction “paths” without making our interfaces incompatible with lambdas (which is necessary to keep it concise)<\/p>\n
Let’s look at a more complex example of a “Burger” type. We wish to allow construction of burgers, but if the purchaser is a vegetarian we would like to restrict the available choices to only vegetarian options.<\/p>\n
The simple meat-eater case looks exactly like above<\/p>\n
\r\nBurger lunch = burger()\r\n .with(beef())\r\n .and(bacon());\r\n<\/pre>\n\r\nclass Burger {\r\n public final Patty patty;\r\n public final Topping topping;\r\n\r\n private Burger(Patty patty, Topping topping) {\r\n this.patty = patty;\r\n this.topping = topping;\r\n }\r\n\r\n public static BurgerBuilder burger() {\r\n return patty -> topping -> new Burger(patty, topping);\r\n }\r\n\r\n interface BurgerBuilder {\r\n ToppingBuilder with(Patty patty);\r\n }\r\n interface ToppingBuilder {\r\n Burger and(Topping topping);\r\n }\r\n}\r\n<\/pre>\nNow let’s introduce a vegetarian option. It will be a compile<\/em> failure to put meat into a vegetarian burger.<\/p>\n\r\nBurger lunch = burger()\r\n .vegetarian()\r\n .with(mushroom())\r\n .and(cheese());\r\n\r\nBurger failure = burger()\r\n .vegetarian()\r\n .with(beef()) \/\/ fails to compile. Beef is not vegetarian.\r\n .and(cheese());\r\n<\/pre>\nTo support this we add a default method to our BurgerBuilder which returns a new VegetarianBuilder which dissallows meat.<\/p>\n
\r\ninterface BurgerBuilder {\r\n ToppingBuilder with(Patty patty);\r\n default VegetarianBuilder vegetarian() {\r\n return patty -> topping -> new Burger(patty, topping);\r\n }\r\n}\r\ninterface VegetarianBuilder {\r\n VegetarianToppingBuilder with(VegetarianPatty main);\r\n}\r\ninterface VegetarianToppingBuilder {\r\n Burger and(VegetarianTopping topping);\r\n}\r\n<\/pre>\nAfter you have expressed your vegetarian preference, the builder will no longer present you with the option of choosing meat.<\/p>\n
Now, let’s add the concept of free toppings. After choosing the main component of the burger we can choose to restrict ourselves to free toppings. In this example Tomato is free but Cheese is not. It will be a compile option to add cheese as a free topping. Now the divergent option is not the first in the chain.<\/p>\n
\r\nBurger lunch = burger()\r\n .with(beef()).andFree().topping(tomato());\r\n\r\nBurger failure = burger()\r\n .with(beef()).andFree().topping(cheese()); \/\/ fails to compile. Cheese is not free\r\n<\/pre>\nWe can support this by adding a new default method to our ToppingBuilder, which in turn calls the abstract method, meaning we don’t have to repeat the entire chain of lambdas required to construct the burger again.<\/p>\n
\r\ninterface ToppingBuilder {\r\n Burger and(Topping topping);\r\n default FreeToppingBuilder free() {\r\n return topping -> and(topping);\r\n }\r\n}\r\ninterface FreeToppingBuilder {\r\n Burger topping(FreeTopping topping);\r\n}\r\n<\/pre>\nHere’s the full code from the burger example, with all the types involved.<\/p>\n
\r\nclass Burger {\r\n public final Patty patty;\r\n public final Topping topping;\r\n\r\n private Burger(Patty patty, Topping topping) {\r\n this.patty = patty;\r\n this.topping = topping;\r\n }\r\n\r\n public static BurgerBuilder burger() {\r\n return patty -> topping -> new Burger(patty, topping);\r\n }\r\n\r\n interface BurgerBuilder {\r\n ToppingBuilder with(Patty patty);\r\n default VegetarianBuilder vegetarian() {\r\n return patty -> topping -> new Burger(patty, topping);\r\n }\r\n }\r\n interface VegetarianBuilder {\r\n VegetarianToppingBuilder with(VegetarianPatty main);\r\n }\r\n interface VegetarianToppingBuilder {\r\n Burger and(VegetarianTopping topping);\r\n }\r\n interface ToppingBuilder {\r\n Burger and(Topping topping);\r\n default FreeToppingBuilder andFree() {\r\n return topping -> and(topping);\r\n }\r\n }\r\n interface FreeToppingBuilder {\r\n Burger topping(FreeTopping topping);\r\n }\r\n\r\n}\r\n\r\ninterface Patty {}\r\ninterface BeefPatty extends Patty {\r\n public static BeefPatty beef() { return null;}\r\n}\r\ninterface VegetarianPatty extends Patty, Vegetarian {}\r\ninterface Tofu extends VegetarianPatty {\r\n public static Tofu tofu() { return null; }\r\n}\r\ninterface Mushroom extends VegetarianPatty {\r\n public static Mushroom mushroom() { return null; }\r\n}\r\n\r\ninterface Topping {}\r\ninterface VegetarianTopping extends Vegetarian, Topping {}\r\ninterface FreeTopping extends Topping {}\r\ninterface Bacon extends Topping {\r\n public static Bacon bacon() { return null; }\r\n}\r\ninterface Tomato extends VegetarianTopping, FreeTopping {\r\n public static Tomato tomato() { return null; }\r\n}\r\ninterface Cheese extends VegetarianTopping {\r\n public static Cheese cheese() { return null; }\r\n}\r\n\r\ninterface Omnivore extends Vegetarian {}\r\ninterface Vegetarian extends Vegan {}\r\ninterface Vegan extends DietaryChoice {}\r\ninterface DietaryChoice {}\r\n<\/pre>\nWhen would(n’t) you use this?<\/h2>\n
Often a traditional builder just makes more sense.<\/p>\n
If you want your builder to be used to supply an arbitrary number of fields in an arbitrary order then this isn’t for you.<\/p>\n
This approach restricts the order in which fields are initialised to a specific order. This is can be a feature – sometimes it’s useful to ensure that some parameters are supplied first. e.g. to ensure mandatory parameters are supplied without the boilerplate of the typesafe builder pattern<\/a>. It’s also easier to make the order flexible in the future if you need to than the other way around.<\/p>\nIf your builder forms part of a public API then this probably isn’t for you.<\/p>\n
Traditional builders are easier to change without breaking existing uses. This approach makes it easy to change uses with refactoring tools, provided you own all the affected code and can make changes to it. To change behaviour without breaking consumers in this approach you would have to restrict yourself to adding default methods rather than modifying existing interfaces.<\/p>\n
On the other hand, by being restrictive in what it allows to compile, this does help you help people using your code to use it in the way you intended.<\/p>\n
Where I do find myself using this approach is building lightweight fluent interfaces both to make the code more readable, and to help out my future self by letting the IDE autocomplete required field\/code blocks. For instance, when recently implementing some automated performance tests, where we needed a warmup and a rampup period, we used one of these to prevent us from forgetting to include them.<\/p>\n
When things are less verbose, you end up using them more often, in places you might not have bothered otherwise.<\/p>\n","protected":false},"excerpt":{"rendered":"
The builder patten is often used to construct objects with many properties. It makes it easier to read initialisations by having parameters named at the callsite, while helping you only allow the construction of valid objects. Builder implementations tend to either rely on the constructed object being mutable, and setting fields as you go, or… Read more »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8],"tags":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n