How to deal with repetitiveness and flexibility when implementing Go interfaces? - go

Question

I have a project that uses a structure like so:
type I interface {
GetName() string
DoSomething()
}
//
// A implements I
//
type A struct {
Name string
}
func (a *A) GetName() string {
return a.Name
}
func (a *A) DoSomething() {
...do something
}
//
// B implements I
//
type B struct {
Name string
}
func (b *B) GetName() string {
return b.Name
}
func (b *B) DoSomething() {
...do something
}
func (b *B) DoSomethingElse() {
...do something else
}
//
// Both
//
func UseAorB(T I) {
name := T.GetName()...
}
Is using GetName the best way to get the name field from either struct A or B when called in a function that takes interface I?
Do I have to redefine DoSomething every time for each thing that is meant to implement the interface? Or is there a better way to do this if DoSomething is the same every time where I can define it just once?
Struct B has a method that the interface does not define (DoSomethingElse). Do I need to use reflect to be able to pass Struct B to a function that takes interface I to call DoSomethingElse? Or should I be defining a new interface that includes this method?
I want to improve my code quality and write a solid library, but I have to say it feels like I am fighting the language and making my life more difficult.

Answer 1

Yes, GetName() is a good way of doing that
If you have similar implementations of a method, you can usually move it to a common struct and embed that:
type Common struct {}
func (c Common) DoSomething() {...}
type A struct {
Common
Stuff
}
type B struct {
Common
Other stuff
}
Above, both A and B have DoSomething method, and they share the implementation
Do not use reflect. There are two ways:
Use type assertion:
func f(in I) {
if b, ok:=in.(B); ok {
// b is of type B, so:
b.DoSomethingElse()
}
}
Use an interface and type assertion:
type DoesSometingElse interface {
DoSomethingElse()
}
func f(in I) {
if x, ok:=in.(DoesSomethingElse); ok{
x.DoSomethingElse()
}
}
If you feel like you're fighting with the language, then either you are modeling something incorrectly, or you don't know the right way to do something in that language. There are good and bad ways of doing things in all languages, and many times these are different for each language. If you are coming to Go from another language, you should first stop trying to think in that other language and translate to Go, and try to work with Go alone.