Dysfunctional Options Pattern in Go(rednafi.com)
rednafi.com
Dysfunctional Options Pattern in Go
https://rednafi.com/go/dysfunctional_options_pattern/
5 comments
Optional types don't fix this. The problem here is not having default (or named) function arguments. With optionals, you still have to pass every arg explicitly.
Languages with both of these features like Python don't end up using the builder pattern or reinventing it like this author.
Languages with both of these features like Python don't end up using the builder pattern or reinventing it like this author.
I like this write up. Nicely done! One think I have enjoyed doing is using named parameters as the options, but it does require a second struct only for the option parts:
NewObject(
required1,
required2,
&ObjectOptions{
Option1: “foo”,
// Option2 skipped
Option3: “bar”,
})
What are the downsides of just adding new methods on the `Config` structure?
func (c *Config) WithFizz(...) {...}
func (c *Config) WithBazz(...) {...}Isn't it essentially doing exactly that? The only difference is that it returns a pointer to the struct from each method. The advantange of doing that is it allows you to compose it as such `WithFizz(...).WithBazz(...)`.
If you don't need the composition, you can just add the methods as above and call it a day.
If you don't need the composition, you can just add the methods as above and call it a day.
Looks cleaner and simpler. I like this pattern!
To solve this problem, a language have to disallow null/nil as a bottom type and provide nice syntax to initialize types with optional types.
[1]: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...