Inheritance and interfaces - go

Question

I want to express the extends behavior many languages possess.
In my Go Code I have a few structs that look like so:
type Base struct {
// Some fields
}
type BaseExtender struct {
Base
// Unique fields
}
type AnotherBaseExtender struct {
Base
// Unique fields
}
Now, I want to write a function that takes any Base since I only need it's "similar fields".
func UseTheBase(b Base) {
testVal := b.thingICareAbout
}
However, this doesn't work. I've done some digging into interface and thought I could do something like:
type Base interface {
// Some fields
}
Except it appears that Go automatically infers interfaces by method implementation. Is there a way to mimic this behavior so I can pass any Base into my function, and not have to implement some nop method on the Base struct and all of it's extenders?
Thanks!

Answer 1

Base implies you want inheritance in Go, Go deliberately eschews inheritance, don't try to recreate it. You can embed types but think of this as embedding behaviour, not just data (as you might be tempted to in an inheriting language).
You're on the right lines with your solution but need public methods and yes interfaces are defined in terms of methods. Just define the interface where you call it as:
type Doer interface {
DoSomething()
}
...
func doit(d Doer) {
d.DoSomething()
}
doit doesn't care what its argument is as long as it has a DoSomething method. Obviously this is a trivial example and there's no point in it, but if you need to override something in all extenders, ask yourself why Base exists, if it is just to add some fields, that's probably not enough reason for a separate type, just add the fields where you need them.
Try to avoid the vast taxonomies of types that you might construct in other languages.

Answer 2

To add on, a common pattern I use is:
type Base interface {
SomeFunction() int
}
type SimpleBaseImpl struct {
// Unique fields
}
func (s SimpleBaseImpl) SomeFunction() int {
return 0
}
type SomethingMoreComplicated struct {
SimpleBaseImpl
// Unique fields
}
Then you could treat SomethingMoreComplicated as "type" Base – but again, its important to note the golang preference for composition (shown here) over inheritance.