I think that makes a bad assumption that _you are constructing bad states_ when that isn’t true. You most likely don’t have all the data you need at construction time and the state of the object is still valid. Some data can be null, but later when it is set you want to validate that the data is correct.
For instance when making a person or user you most likely only have their email when you initially create them and then it’s the users job to complete the rest of the data at a later time. Some might want to fill in their age or some might want to fill in their sex. You may never get this data because it’s optional, but when you set it you’ll want to validate it.
And as always in programming _it depends_. It depends on your workflow, requirements, and domain. Being dogmatic about anything is just going to result in worse code.
I personally don’t really like builders. They work in some situations. But if I’m pulling the record from the DB and I only need to set some data on it that is overkill and more complex than need be. The object is already constructed in a valid state.
> The object is already constructed in a valid state.
But that's the entire value proposition of do-not-allow-construction-of-invalid-state!
If a User is actually a User, then you can say "the object is already constructed in a valid state".
If you decide to be 'less dogmatic' and instead construct Users-which-may-or-may-not-be-users-just-throw-an-ex-if-theyre-no-good, then you cannot say that the object is already constructed in a valid state.
That's not the situation described above where data is partial.
In your case I would copy rather than mutate, unless I'm actually getting noticably higher profits from lower memory usage during the time between getting the object and GC. This hasn't happened to me yet.
Maybe I'm not getting what you're saying but the data is partial? In the situation above we have a valid record created by someone else. This is pseudocode obviously, but I genuinely don't know what copying or building or immutability is going to buy me here other than being more complex. There is no worrying about the record being in an invalid state because it could have never gotten to the database in an invalid state.
class User {
Long? id;
String email;
String? name;
Integer? age;
Sex? sex;
Avatar? avatar;
User(String email) {
this.email = email;
}
}
record ProfileVm(String? name, Integer? age, Sex? sex, Avatar? avatar) {}
// some ui controller
var user = findById(id)
if (user == null) {
return notFound();
}
var vm = ProfileVm.fromJson(request.json());
user.setName(vm.name());
user.setAge(vm.age());
user.setSex(vm.sex());
user.setAvatar(vm.avatar());
user.save();
return ok();
For instance when making a person or user you most likely only have their email when you initially create them and then it’s the users job to complete the rest of the data at a later time. Some might want to fill in their age or some might want to fill in their sex. You may never get this data because it’s optional, but when you set it you’ll want to validate it.
And as always in programming _it depends_. It depends on your workflow, requirements, and domain. Being dogmatic about anything is just going to result in worse code.