Please see the accepted answer by Space Trucker. This discusses creating a generic Builder rather than creating a specialized Builder for every class.
I haven’t seen this before and even though the post was old I was sold on it immediately. Comments are welcome, pro or con.
Person value = GenericBuilder.of(Person::new)
.with(Person::setName, "Otto").with(Person::setAge, 5).build();
vs
Person value = new Person();
value.setName("Otto");
value.setAge(5);
cons:
pros:
If all you want is to be able to chain methods together, then, probably something like this would be better:
Person value=new Person().name("Otto").age(5);
Yeah, to me builders are only necessary if you need all of the arguments to construct the object. Like an object that has to have 12 constructor parameters for some reason… or has 12 different constructors with various combinations of 4-5 arguments.
Else if you are just going to be setting a bunch of properties then add fluent methods that return ‘this’. (as @RiccardoBlb has illustrated)
Thats exactly the number of parameters and I need all to construct the object. Thats just scary.
Its a new user account object from web form.
There are no other classes that are this abnormal so I will go with the standard builder like @RiccardoBlb says.
Edit: Er, not like @RiccardoBlb says, heh, hes talking about setters. I have to enforce the null values so I will go with the builder.
This is a class from another library?
No.
So I don’t understand why it requires 12 parameters on the constructor instead of just using the setters or fluent methods directly on the object.
Even if it’s a normally immutable object, then another approach is selective immutability. ie: at some point you “validate” the parameters and don’t allow them to change after.
A separate immutable object that is constructed by a factory/builder is safer, though. Safer from developer bugs I mean.
Right, thats what this is.
The object comes from the form submission and then I have to dump its content into the vault for user details.
I am still learning this phase of this but I liked the idea of that before mentioned generic builder because I could pass a predicate to do my verifying during the build on the spring server and then do redirects if i need since I will still be in the handler method.
My general idea is to try and avoid using server scripts prior to sending the object because people will have to give the browser permissions and if they are like me they will naturally be suspicious of anything script coming from a web page.
I intend to use thymeleaf to do some things but as i am just learning it I am not sure as to how much I can use it yet.
Sometimes things are probably easier organized if they’re grouped together, too.
Colors: skin, hair, eye, etc
Measurements: height, weight, etc
Person person = new Person("Jamie", colors, measurements);
Just another option to put on the table, and allows you to easily pass various customizations around to other objects of the same type.
Thymleaf is good for injecting variables at generation time before the client recieves it. They don’t get passed to the user, but are instead used in the generation of the page. So for example “isAdmin” or “hasPermission” would be a great use of thymleaf to branch out various rendered areas of the page, and the areas that don’t qualify are never sent to the user. This is called server-side rendering, and these days is used sparingly because it’s much more efficient to render the DOM client-side.
Angular, VuejS, etc. are client-side DOM renderers. They typically take a data object, usually JSON, and make decisions based on that. The json could contain a list of saved servers or friends or whatever and generate HTML to display the list. This is what you should do as much as possible because it removes the generation burden from your server and pushes it to the client. If you have 100 users the server has to generate 100 seperate pages, but using the client-side approach means each client generates their own page on their own computer, thus “sharing the load”.
TLDR: Use thymleaf only when necessary to reduce server workload. For example to only send parts of a page that the user should see based on their permission level or something, or return a “forbidden” page instead of the admin login if the user is not an admin.
I don’t see the difference between this and the proposed “generic builder”
After writing the vault functions, I am thinking chaining setters is going to be the best option.
Thats 13 objects for one user build and a few functions need all users so that could be thousands of objects built on just a couple hundred users in the vault, even when stored in hashtable afterwards, that is alot of objects potentially.