|
|
|
|
|
by zbentley
2817 days ago
|
|
Many use cases want to make a whole lot of pretty similar (URI, creds, method) requests that vary only in a single way ( e.g. a POST parameter) or don't vary at all (e.g. polling). A builder is a convenient way to wrap up those common settings so that they can be handed to other parts of the code that don't care about them/want to override specific parts and leave the rest in common. Now, there are other ways to do that (instantiating a concrete class with common settings and mutable fields for customizations in a function, and then passing references to that function to everything that wants the common-config-defaulted output object). The choice between that kind of strategy (or an instantiate-and-freeze-early and pass your mutators in, or a refactor-all-your-code-to-not-mutate strategy etc...) and a builder pattern is a subjective and debatable one. But the approach taken here is certainly defensible. |
|