"Prefer composition to inheritance" - Gang of 4
Inheritance simply wasn't designed into Golang in the first place. ;)
If you are looking for detailed explanations on the why part, I believed this has been answered on SO, hence I would just point you to it: Embedding instead of inheritance in Go.
Well, you can actually achieve the same result with adapter design pattern, which enables you to extend functionality from a built-in library, and to me, its way more flexible than inheritance.
func adapter(h http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Server", SERVER_NAME)
h.ServeHTTP(w, r)
})
}
Or pass in serverName
as parameter:
func adapter(h http.Handler, serverName string) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Server", serverName)
h.ServeHTTP(w, r)
})
}
Finally, you have the flexibility to choose which handler(s) to be 'inherited':
http.Handle("/path", adapter(your_handler))
Or if its meant for every handlers, just 'inherit' to the root-handler:
http.ListenAndServe(port, adapter(root_Handler))