Shoutout to David Arno for teaching me about the builder design pattern via this thread!
I have since used that pattern althroughout the code base to abstract out creating models from data stores, ready to use in the test cases. See the link to the other question for example on how we're using it.
However, model creation is not entirely abstracted out. On special-scenario test cases and the sanity test cases, we are still creating models by hitting their constructors directly. For example, in one of the sanity tests, we create the model like:
ContractModel model = new ContractModel(SMDDateUtils.toDate('08-16-2021'), SMDDateUtils.toDate('08-16-2021'), 3, 'dummyContractLabelName', Frequency.QUARTERLY, 45, 5, true, 26, SMDConstants.URL, Signatory.PHYSICIAN, new BankDetailModel(3) )
What a nightmare! (What if we wanted to add to, remove from, or change up that model class, for whatever reason...?!)
We do have a
ContractBuilder already, but its job is to create
ContractModels from the contracts data store.
Upon delving into the builder design pattern, I know that it is most commonly implemented another way. This have the benefit of making that happy-path
ContractModel creation like:
ContractModel model = ContractModel.builder() .signDate(SMDDateUtils.toDate('08-16-2021')) .startDate(SMDDateUtils.toDate('08-16-2021')) //... .build()
which would be way the hell easier to instantly understand and maintain. Even better, there's convenient third-party library for that.
The question is: would it be a code smell to have both types of builder going on (or even for the first to use the second)?