Is Record feature in Java 16 is an alternative to builder classes?
Basically ... no it isn't.
Records provide immutability to an object, so does builder pattern.
That's not correct. The builder pattern can be applied to both immutable and mutable objects. It is actually about how objects are created rather than the nature of the objects themselves.
What are pros and cons of using record in place of builder?
Well, simply put, you can't use records as a replacement for the builder pattern ... because they do different (in fact, orthogonal) things. Here's a point by point comparison of conventional Java classes implemented with the builder pattern versus record types:
- Mutability:
- class + builder - either mutable or immutable objects can be created
- record - immutable only
- Validation:
- class + builder - yes ... the builder can validate the arguments incrementally or in the
build()method. - record - yes ... in constructors
- class + builder - yes ... the builder can validate the arguments incrementally or in the
- Supports optional parameters:
- class + builder - yes
- record - no ... though you can implement overloaded constructors
- Supports
extends:- class + builder - yes
- record - no ... though you can use
defaultmethods from an inherited interface.
- Supports internal state / abstraction:
- class + builder - yes
- record - no
- Less boilerplate code:
- class + builder - yes (relative to classes implemented without a builder) and no (relative to records).
- record - yes
The "less boilerplate" issue is nuanced. On the one hand a builder avoids the need for overloaded constructors or new calls with huge numbers of parameters. (But you need to implement the builder itself ... which is mostly boilerplate.) On the other hand a record can be implemented without any explicit methods and a simple record constructor with no body.
Videos
Is Record feature in Java 16 is an alternative to builder classes?
Basically ... no it isn't.
Records provide immutability to an object, so does builder pattern.
That's not correct. The builder pattern can be applied to both immutable and mutable objects. It is actually about how objects are created rather than the nature of the objects themselves.
What are pros and cons of using record in place of builder?
Well, simply put, you can't use records as a replacement for the builder pattern ... because they do different (in fact, orthogonal) things. Here's a point by point comparison of conventional Java classes implemented with the builder pattern versus record types:
- Mutability:
- class + builder - either mutable or immutable objects can be created
- record - immutable only
- Validation:
- class + builder - yes ... the builder can validate the arguments incrementally or in the
build()method. - record - yes ... in constructors
- class + builder - yes ... the builder can validate the arguments incrementally or in the
- Supports optional parameters:
- class + builder - yes
- record - no ... though you can implement overloaded constructors
- Supports
extends:- class + builder - yes
- record - no ... though you can use
defaultmethods from an inherited interface.
- Supports internal state / abstraction:
- class + builder - yes
- record - no
- Less boilerplate code:
- class + builder - yes (relative to classes implemented without a builder) and no (relative to records).
- record - yes
The "less boilerplate" issue is nuanced. On the one hand a builder avoids the need for overloaded constructors or new calls with huge numbers of parameters. (But you need to implement the builder itself ... which is mostly boilerplate.) On the other hand a record can be implemented without any explicit methods and a simple record constructor with no body.
The JDK Enhancement Proposal describes records as “classes that act as transparent carriers for immutable data”.
Use cases:
Reduces Boilerplate code: Historically, creating immutable objects in Java was rather painful work, records takes care of almost all of that work for us. Records also allows the class to be better focused on the business problem at hand by reducing boilerplate code. This makes it a compelling feature for implementing things like DDD-style Value Objects and Domain Events.
public record Address(String street, String postCode, String town, String country) {
}
Temporary containers of data: Records can be defined not only as stand-alone classes, but also locally inside a method. This makes them useful as temporary containers during data processing, for quickly creating ephemeral mock data in tests, etc. We will see an example of this below.
Data Validation: Records provide support for different validation. it reduces responsibilities from the developer to write such validation
@NonNull -> a field can not be null.
@Min() -> a min value that a field can hold.
@Max() -> a max value that a field can hold.
@GreaterThanZero -> a field can not have value less than or equal to zero.
Comparison to Builder Classes: The only advantage that a record class offers over builder classes is data validation.