Yes, it is right when there is only one such function. But when there
are many such functions, I think the wrapper style will be better. For
example, matrix.Interface just implement any functions that will be
overridden by different matrix types, and we leave the common functions
on all matrix types to Matrix:
type Interface {
Size() (r, c int)
At(r, c int) float64
Set(r, c int, v float64)
}
type Matrix {
Interface
}
func (m Matrix) Add(n Matrix) Matrix { ... }
func (m Matrix) Mult(s float64) Matrix { ... }
...
In this case, it will convenient to define functions on Matrix and expose Matrix to public, instead of a list of independent functions that accept Interface.
While in the traditional OOP (java, c++), we would define a basic Matrix class with the virtual functions, and some common functions, and the subclasses will override the virtual functions of basic Matrix. While in Go, we can do it by the way above.