Hi everyone!
Today's objective is to describe and document a bunch of golang patterns.
As you know from my previous posts (go concurrency and go lambdas), I have recently entered the Go-land and found out quite soon that common idioms I knew from my previous experience did not quite apply to golang.
Well, I found out that there are some patters that are so common that in my humble opinion should be presented as part of any beginner guide about golang.
All the code in the examples is on github.
Group constants
The title said it all, we want to group common constants in the same namespace.
// Package constants shows a pattern to group constants together | |
package constants | |
// Endpoint contains the endpoint configuration | |
var Endpoint struct { | |
Hostname string | |
Port int | |
} | |
func init() { | |
Endpoint.Hostname = "some-endpoint" | |
Endpoint.Port = 9090 | |
} |
Chain
A chain of suppliers that returns as soon as one of the suppliers returns a non-zero result or an error.
The code shows an example in which we need to load a configuration value from one of the possible sources: env variable, config file or a database.
We want to stop searching for the config value as soon as a non-zero result is returned.
package chain | |
import "fmt" | |
func ExampleChain() { | |
endpoint, _ := chain( | |
loadEndpointFromConfigFile, | |
loadEndpointFromEnvVariables, | |
loadEndpointFromDatabase, | |
).get() | |
fmt.Println(endpoint) | |
// Output: some-endpoint | |
} | |
func loadEndpointFromEnvVariables() (string, error) { | |
return "", nil | |
} | |
func loadEndpointFromConfigFile() (string, error) { | |
return "", nil | |
} | |
func loadEndpointFromDatabase() (string, error) { | |
return "some-endpoint", nil | |
} |
Code for the chain here.
Options
Options shows a flexible way to construct an object.
The major benefit is being able to add more parameters in the future to the object constructor without breaking the clients.
In other languages, you would probably use an overloaded constructor or fall back to the builder pattern.
Context("Greeting with no Name option", func() { | |
It("returns default greeting", func() { | |
greeting := NewGreeting() | |
Expect(greeting.get()).To(Equal("Hello Stranger")) | |
}) | |
}) | |
Context("Greeting with Name option", func() { | |
It("returns custom greeting", func() { | |
greeting := NewGreeting(Name("Mickey")) | |
Expect(greeting.get()).To(Equal("Hello Mickey")) | |
}) | |
}) |
Code for the option here.
Maybe
Maybe is a container which may or may not contain a non-null value.
Context("User present", func() { | |
var greeting string | |
MaybeUser(getUser(1)).IfPresent(func(u *User) { | |
greeting = "Hello " + u.name | |
}) | |
It("greets the user", func() { | |
Expect(greeting).To(Equal("Hello Mickey")) | |
}) | |
}) | |
Context("User absent", func() { | |
var greeting string | |
MaybeUser(getUser(-1)).WhenAbsent(func() { | |
greeting = "Hello stranger" | |
}) | |
It("greets the user", func() { | |
Expect(greeting).To(Equal("Hello stranger")) | |
}) | |
}) |
Function type
Functions are first class citizen in Golang. They can be used as a type whenever we want to easily implement a Strategy pattern or similar.
This pattern is heavily used in the golang http package.
package functiontype | |
import "fmt" | |
type Greeting func(name string) string | |
func GreetingService(request Request, greeting Greeting) string { | |
return fmt.Sprintf("Service says: %s", greeting(request.user)) | |
} | |
func ExampleFunctionType() { | |
request := Request{user: "Mickey"} | |
fmt.Println( | |
GreetingService(request, func(name string) string { | |
return fmt.Sprintf("Hola %s!", name) | |
}), | |
) | |
// Output: Service says: Hola Mickey! | |
} |
Conclusions
Thanks for reading!
Let me know if you found it useful and if there is a key pattern that should really be part of this list.
Top comments (2)
This does not quite fit all use cases, this
constants
package introduces an inter package/module dependency which not always great especially in service oriented envsNewGreeting(Name("Mickey"))
Actually is relatively harder to read and implement comparing to building pattern
NewGreeting().WithName("Mickey")
Hi! Thanks for the feedback. I named the package after the example I wanted to show (I.e. maybe package, options package etc.). It is not required to have the constants in a different package (neither is required to name it constants in case you want to have a different package).
As for Options, it s a really valid point and I think the reason why options is more popular than builder(despite the fact that builder is slightly more readable) may be the lack of library like Lombok for example, which generates boiler plate code for you. Options is a bit more light from this point of view, but like you pointed out, might loose a bit in readability.