Golang and inheritance

空扰寡人 提交于 2019-11-30 01:37:30
Addison

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.

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 :)

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!