When I started picking up the go language years ago, things that stood out to me immediately were the io and net/http packages. Both of those packages were extremely well done and minimal in the amount of interfaces they exposed to the user.
What I love about net/http
The two things which stand out for me are:
- Interface Design.
- Composability
Interface Design
The primary constructs you’ll interact with are pretty limited:
To build your service:
http.Handler
http.HandlerFunc
http.ServerTo handle requests:
http.ResponseWriter
http.RequestTo build a client:
http.Client
http.TransportIn total, we’re looking at 7 core primitives to build a client and server — which isn’t a lot! …
When I mention dependency injection to folks who have Java or .NET backgrounds it usually invokes a few sets of questions — to which my usual response is:
It’s likely not as sophisticated as what you’re thinking — and it doesn’t have to be!
While there are methods to use more sophisticated approaches in Go, starting off projects the simplest way possible is still the preferred approach.
Definitions
Dependency injection represents the D in SOLID principles. Quoting from wikipedia:
In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. …
One of the most prevalent patterns when managing the lifecycle of goroutines in Go is to have a done channel. Here’s a quick example showing this in action:
done := make(chan struct{})for {
select {
case <-done:
return
case job := <-jobs:
// execute job
}
}
In fact, this is pretty much how the Done channel in context is done under the hood.
Approaches to closing this done channel
Option 1: using a mutex
If we take a look at how it’s done in the context package, it simply uses a mutex to ensure that the action of closing the channel is only done once.
Here’s the relevant snippet showing…
