I was watching a video regarding design patterns and the youtuber made an example of the builder pattern…
I didn’t know about the pattern(there is a reason why I was watching the videos); But I had encounter the same type of problems so what I usually did was to return null to the fields I didn’t had their data.
Is it wrong what I was doing?
At the end the builder will make the object with a null data and realistically it takes the same amount of code…
You remind me that I suck at design patterns. IMHO, the patterns are only theoretical, and it doesn’t cover all the details of every language. Sometimes it will be null, empty, or can throw an exception if your team decides that it’s better.
If null is a valid value for the field there is no reason why a builder should not construct an object where the field is null.
The only thing i dislike about the pattern is that a class utilizing the builder to retrieve the object has to know a lot about how the object has to be constructed, however it makes for very readable code imho.
So the builder pattern is supposed to solve the problem of: if you have a large number of optional fields that may or may not need to be set to construct your object. Then once the dev has called all of the setters that they require, they call build to fully realize that object.
Some rules that all builders should follow:
All setters SHOULD represent optional parameters. (Or ones that have a default value). If a parameter is required for all instances, include it in the constructor of the Builder itself.
All setters SHOULD return a copy of the Builder. This way you can chain calls off of each other.
Setters SHOULD do nothing more than store the provided value in a field local to the builder itself and then return itself (or a copy of itself).
You MUST expose a .build() method that will return the fully realized object. This method should essentially call the constructor for your target object using all of the parameters, regardless if a setter was called or not. Obviously any value where the setter wasn’t called will be null or some default value.
Contrieved examples you usually see in design pattern tutorials do not properly highlight the use case and usefulness of a specific pattern.
What you did might have been fine. You only rarely need the builder design pattern.
It’s useful when the object you want to build has a complex constructor, or several ones, or you want to more easily enforce the self consistency of the created object (some languages make it hard to share initialization code) or you want to hide some internal details (I.e., you are at an API boundary and want to be able to freely change the objects your main object is composed of).
In short, Builder is a way to have a handy interface to an object constructor. It’s nice for users of a library, or if you find yourself repeating a complex constructor invocation often, but you usually do not want to have to maintain such an interface that is, at the end of the day, mostly boilerplate code.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
You remind me that I suck at design patterns. IMHO, the patterns are only theoretical, and it doesn’t cover all the details of every language. Sometimes it will be null, empty, or can throw an exception if your team decides that it’s better.
If null is a valid value for the field there is no reason why a builder should not construct an object where the field is null.
The only thing i dislike about the pattern is that a class utilizing the builder to retrieve the object has to know a lot about how the object has to be constructed, however it makes for very readable code imho.
So the builder pattern is supposed to solve the problem of: if you have a large number of optional fields that may or may not need to be set to construct your object. Then once the dev has called all of the setters that they require, they call build to fully realize that object.
Some rules that all builders should follow:
.build()method that will return the fully realized object. This method should essentially call the constructor for your target object using all of the parameters, regardless if a setter was called or not. Obviously any value where the setter wasn’t called will be null or some default value.Contrieved examples you usually see in design pattern tutorials do not properly highlight the use case and usefulness of a specific pattern.
What you did might have been fine. You only rarely need the builder design pattern.
It’s useful when the object you want to build has a complex constructor, or several ones, or you want to more easily enforce the self consistency of the created object (some languages make it hard to share initialization code) or you want to hide some internal details (I.e., you are at an API boundary and want to be able to freely change the objects your main object is composed of).
In short, Builder is a way to have a handy interface to an object constructor. It’s nice for users of a library, or if you find yourself repeating a complex constructor invocation often, but you usually do not want to have to maintain such an interface that is, at the end of the day, mostly boilerplate code.