Golang and inheritance

Question

I want to provide a base struct with methods in my library that can be \'extended\'.

The methods of this base struct rely on methods from the extending struct. This

Answer 1

As mentioned in people's comments, Go encourages composition over inheritance.

To address your question about reducing code duplication, you would want to use embedding.

Using the example from Effective Go linked above, you start with very narrow interfaces that only do a few things:

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

Then you can either compose interfaces together into another interface:

// ReadWriter is the interface that combines the Reader and Writer interfaces.
type ReadWriter interface {
    Reader
    Writer
}

It works similarly for structs, where you can compose structs that implement Reader and Writer together in another struct:

type MyReader struct {}
func (r *MyReader) Read(p []byte) (n int, err error) {
    // Implements Reader interface.
}
type MyWriter struct {}
func (w *MyWriter) Write(p []byte) (n int, err error) {
    // Implements Writer interface.
}

// MyReadWriter stores pointers to a MyReader and a MyWriter.
// It implements ReadWriter.
type MyReadWriter struct {
    *MyReader
    *MyWriter
}

Basically, anything that implements a Reader or a Writer can be reused by composing them together in a struct, and that outer struct will automatically implement the ReadWriter interface.

This is basically doing Dependency Injection, and it's super useful for testing too.

Example from the struct code above:

func (rw *MyReadWriter) DoCrazyStuff() {
    data := []byte{}
    // Do stuff...
    rw.Read(data)
    rw.Write(data)
    // You get the idea...
}

func main() {
    rw := &MyReadWriter{&MyReader{}, &MyWriter{}}
    rw.DoCrazyStuff()
}

One thing to point out that's slightly different from other languages' composition paradigm is that the MyReadWriter struct can now act as both a Reader and a Writer. That's why in DoCrazyStuff() we do rw.Read(data) instead of rw.Reader.Read(data).

UPDATE: Fixed incorrect example.

Answer 2

Sorry to disappoint you, but you are asking the wrong question. I had a similar problem when I started writing Go code.

You can not simply take a class hierarchy and translate it to Go code, at least not with satisfying results. Usually there is a very elegant and simple way to solve such things in Go, but to discover them, you need to think a bit differently as you are used to.

Unfortunately, your question doesn't say anything about what problem you are trying to solve. You have just described how you would like to solve it. Therefore I am a bit reluctant to give a general answer, since it will not lead to idiomatic Go code. I understand if you are disappointed by that answer, but in my opinion, that`s the most value-able answer you can get :)