Timeline for Why do we need a Builder class when implementing a Builder pattern?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 24, 2018 at 14:28 | history | edited | Paŭlo Ebermann | CC BY-SA 4.0 |
make it clearer that the builder methods need to do the validation
|
| Oct 24, 2018 at 14:26 | comment | added | Paŭlo Ebermann | @BillK this is what I meant with "if there is a way of getting an initial (valid/useful) object" – I assume that both the initial object and the object returned from each builder function are valid/consistent. Your task as a creator of such a class is to provide only builder methods which do those consistent changes. | |
| Oct 24, 2018 at 6:17 | comment | added | VLAZ |
@BillK true - an object with, essentially, immutable setters (that return a new object every time) means that each object returned should be valid. If you are returning invalid objects (e.g., person with name but no age), then the concept doesn't work. Well, you could actually be returning something like PartiallyBuiltPerson while it's not valid but it seems like a hack to mask the Builder.
|
|
| Oct 23, 2018 at 23:25 | comment | added | Bill K | This is true--and I think it's a very important point, but it does not solve the last problem--It does not give you a chance to validate that the object is in a consistent state when it's constructed. Once constructed you will need some trickery like calling a validator before any of your business methods to make sure the caller set all the methods (which would be a terrible practice). I think it's good to reason through this kind of thing to see why we use the Builder pattern the way we do. | |
| Oct 23, 2018 at 21:14 | history | answered | Paŭlo Ebermann | CC BY-SA 4.0 |