vault backup: 2025-12-10 11:37:35

Quellen/IT/Optional Parameters in Go.md

@@ -0,0 +1,58 @@
+---
+title: Optional Parameters in Go?
+source: https://stackoverflow.com/questions/2032149/optional-parameters-in-go
+tags:
+  - IT/Development/Go
+---
+
+For arbitrary, potentially large number of optional parameters, a nice idiom is to use **Functional options**.
+
+For your type `Foobar`, first write only one constructor:
+
+```go
+func NewFoobar(options ...func(*Foobar) error) (*Foobar, error){
+  fb := &Foobar{}
+  // ... (write initializations with default values)...
+  for _, op := range options{
+    err := op(fb)
+    if err != nil {
+      return nil, err
+    }
+  }
+  return fb, nil
+}
+```
+
+where each option is a function which mutates the Foobar. Then provide convenient ways for your user to use or create standard options, for example :
+
+```go
+func OptionReadonlyFlag(fb *Foobar) error {
+  fb.mutable = false
+  return nil
+}
+
+func OptionTemperature(t Celsius) func(*Foobar) error {
+  return func(fb *Foobar) error {
+    fb.temperature = t
+    return nil
+  }
+}
+```
+
+[Playground](http://play.golang.org/p/3HB9KJ7m2D)
+
+For conciseness, you may give a name to the type of the options ([Playground](http://play.golang.org/p/il93GYGtFL)) :
+
+```go
+type OptionFoobar func(*Foobar) error
+```
+
+If you need mandatory parameters, add them as first arguments of the constructor before the variadic `options`.
+
+The main benefits of the _Functional options_ idiom are :
+
+*   your API can grow over time without breaking existing code, because the constuctor signature stays the same when new options are needed.
+*   it enables the default use case to be its simplest: no arguments at all!
+*   it provides fine control over the initialization of complex values.
+
+This technique was coined by [Rob Pike](https://commandcenter.blogspot.fr/2014/01/self-referential-functions-and-design.html) and also demonstrated by [Dave Cheney](https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis).