Meaning of a struct with embedded anonymous interface? - go

sort package:
type Interface interface {
Len() int
Less(i, j int) bool
Swap(i, j int)
}
...
type reverse struct {
Interface
}
What is the meaning of anonymous interface Interface in struct reverse?

In this way reverse implements the sort.Interface and we can override a specific method
without having to define all the others
type reverse struct {
// This embedded Interface permits Reverse to use the methods of
// another Interface implementation.
Interface
}
Notice how here it swaps (j,i) instead of (i,j) and also this is the only method declared for the struct reverse even if reverse implement sort.Interface
// Less returns the opposite of the embedded implementation's Less method.
func (r reverse) Less(i, j int) bool {
return r.Interface.Less(j, i)
}
Whatever struct is passed inside this method we convert it to a new reverse struct.
// Reverse returns the reverse order for data.
func Reverse(data Interface) Interface {
return &reverse{data}
}
The real value comes if you think what would you have to do if this approach was not possible.
Add another Reverse method to the sort.Interface ?
Create another ReverseInterface ?
... ?
Any of this change would require many many more lines of code across thousands of packages that want to use the standard reverse functionality.

Ok, the accepted answer helped me understand, but I decided to post an explanation which I think suits better my way of thinking.
The "Effective Go" has example of interfaces having embedded other interfaces:
// ReadWriter is the interface that combines the Reader and Writer interfaces.
type ReadWriter interface {
Reader
Writer
}
and a struct having embedded other structs:
// ReadWriter stores pointers to a Reader and a Writer.
// It implements io.ReadWriter.
type ReadWriter struct {
*Reader // *bufio.Reader
*Writer // *bufio.Writer
}
But there is no mention of a struct having embedded an interface. I was confused seeing this in sort package:
type Interface interface {
Len() int
Less(i, j int) bool
Swap(i, j int)
}
...
type reverse struct {
Interface
}
But the idea is simple. It's almost the same as:
type reverse struct {
IntSlice // IntSlice struct attaches the methods of Interface to []int, sorting in increasing order
}
methods of IntSlice being promoted to reverse.
And this:
type reverse struct {
Interface
}
means that sort.reverse can embed any struct that implements interface sort.Interface and whatever methods that interface has, they will be promoted to reverse.
sort.Interface has method Less(i, j int) bool which now can be overridden:
// Less returns the opposite of the embedded implementation's Less method.
func (r reverse) Less(i, j int) bool {
return r.Interface.Less(j, i)
}
My confusion in understanding
type reverse struct {
Interface
}
was that I thought that a struct always has fixed structure, i.e. fixed number of fields of fixed types.
But the following proves me wrong:
package main
import "fmt"
// some interface
type Stringer interface {
String() string
}
// a struct that implements Stringer interface
type Struct1 struct {
field1 string
}
func (s Struct1) String() string {
return s.field1
}
// another struct that implements Stringer interface, but has a different set of fields
type Struct2 struct {
field1 []string
dummy bool
}
func (s Struct2) String() string {
return fmt.Sprintf("%v, %v", s.field1, s.dummy)
}
// container that can embedd any struct which implements Stringer interface
type StringerContainer struct {
Stringer
}
func main() {
// the following prints: This is Struct1
fmt.Println(StringerContainer{Struct1{"This is Struct1"}})
// the following prints: [This is Struct1], true
fmt.Println(StringerContainer{Struct2{[]string{"This", "is", "Struct1"}, true}})
// the following does not compile:
// cannot use "This is a type that does not implement Stringer" (type string)
// as type Stringer in field value:
// string does not implement Stringer (missing String method)
fmt.Println(StringerContainer{"This is a type that does not implement Stringer"})
}

The statement
type reverse struct {
Interface
}
enables you to initialize reverse with everything that implements the interface Interface. Example:
&reverse{sort.Intslice([]int{1,2,3})}
This way, all methods implemented by the embedded Interface value get populated to the outside while you are still able to override some of them in reverse, for example Less to reverse the sorting.
This is what actually happens when you use sort.Reverse. You can read about embedding in the struct section of the spec.

I will give my explanation too. The sort package defines an unexported type reverse, which is a struct, that embeds Interface.
type reverse struct {
// This embedded Interface permits Reverse to use the methods of
// another Interface implementation.
Interface
}
This permits Reverse to use the methods of another Interface implementation. This is the so called composition, which is a powerful feature of Go.
The Less method for reverse calls the Less method of the embedded Interface value, but with the indices flipped, reversing the order of the sort results.
// Less returns the opposite of the embedded implementation's Less method.
func (r reverse) Less(i, j int) bool {
return r.Interface.Less(j, i)
}
Len and Swap the other two methods of reverse, are implicitly provided by the original Interface value because it is an embedded field. The exported Reverse function returns an instance of the reverse type that contains the original Interface value.
// Reverse returns the reverse order for data.
func Reverse(data Interface) Interface {
return &reverse{data}
}

I find this feature very helpful when writing mocks in tests.
Here is such an example:
package main_test
import (
"fmt"
"testing"
)
// Item represents the entity retrieved from the store
// It's not relevant in this example
type Item struct {
First, Last string
}
// Store abstracts the DB store
type Store interface {
Create(string, string) (*Item, error)
GetByID(string) (*Item, error)
Update(*Item) error
HealthCheck() error
Close() error
}
// this is a mock implementing Store interface
type storeMock struct {
Store
// healthy is false by default
healthy bool
}
// HealthCheck is mocked function
func (s *storeMock) HealthCheck() error {
if !s.healthy {
return fmt.Errorf("mock error")
}
return nil
}
// IsHealthy is the tested function
func IsHealthy(s Store) bool {
return s.HealthCheck() == nil
}
func TestIsHealthy(t *testing.T) {
mock := &storeMock{}
if IsHealthy(mock) {
t.Errorf("IsHealthy should return false")
}
mock = &storeMock{healthy: true}
if !IsHealthy(mock) {
t.Errorf("IsHealthy should return true")
}
}
By using:
type storeMock struct {
Store
...
}
One doesn't need to mock all Store methods. Only HealthCheck can be mocked, since only this method is used in the TestIsHealthy test.
Below the result of the test command:
$ go test -run '^TestIsHealthy$' ./main_test.go
ok command-line-arguments 0.003s
A real world example of this use case one can find when testing the AWS SDK.
To make it even more obvious, here is the ugly alternative - the minimum one needs to implement to satisfy the Store interface:
type storeMock struct {
healthy bool
}
func (s *storeMock) Create(a, b string) (i *Item, err error) {
return
}
func (s *storeMock) GetByID(a string) (i *Item, err error) {
return
}
func (s *storeMock) Update(i *Item) (err error) {
return
}
// HealthCheck is mocked function
func (s *storeMock) HealthCheck() error {
if !s.healthy {
return fmt.Errorf("mock error")
}
return nil
}
func (s *storeMock) Close() (err error) {
return
}

Embedding interfaces in a struct allows for partially "overriding" methods from the embedded interfaces. This, in turn, allows for delegation from the embedding struct to the embedded interface implementation.
The following example is taken from this blog post.
Suppose we want to have a socket connection with some additional functionality, like counting the total number of bytes read from it. We can define the following struct:
type StatsConn struct {
net.Conn
BytesRead uint64
}
StatsConn now implements the net.Conn interface and can be used anywhere a net.Conn is expected. When a StatsConn is initialized with a proper value implementing net.Conn for the embedded field, it "inherits" all the methods of that value; the key insight is, though, that we can intercept any method we wish, leaving all the others intact. For our purpose in this example, we'd like to intercept the Read method and record the number of bytes read:
func (sc *StatsConn) Read(p []byte) (int, error) {
n, err := sc.Conn.Read(p)
sc.BytesRead += uint64(n)
return n, err
}
To users of StatsConn, this change is transparent; we can still call Read on it and it will do what we expect (due to delegating to sc.Conn.Read), but it will also do additional bookkeeping.
It's critical to initialize a StatsConn properly, otherwise the field retains its default value nil causing a runtime error: invalid memory address or nil pointer dereference; for example:
conn, err := net.Dial("tcp", u.Host+":80")
if err != nil {
log.Fatal(err)
}
sconn := &StatsConn{conn, 0}
Here net.Dial returns a value that implements net.Conn, so we can use that to initialize the embedded field of StatsConn.
We can now pass our sconn to any function that expects a net.Conn argument, e.g:
resp, err := ioutil.ReadAll(sconn)
if err != nil {
log.Fatal(err)
And later we can access its BytesRead field to get the total.
This is an example of wrapping an interface. We created a new type that implements an existing interface, but reused an embedded value to implement most of the functionality. We could implement this without embedding by having an explicit conn field like this:
type StatsConn struct {
conn net.Conn
BytesRead uint64
}
And then writing forwarding methods for each method in the net.Conn interface, e.g.:
func (sc *StatsConn) Close() error {
return sc.conn.Close()
}
However, the net.Conn interface has many methods. Writing forwarding methods for all of them is tedious and unnecessary. Embedding the interface gives us all these forwarding methods for free, and we can override just the ones we need.

I will try another, low level approach to this.
Given the reverse struct:
type reverse struct {
Interface
}
This beside others means, that reverse struct has a field reverse.Interface, and as a struct fields, it can be nil or have value of type Interface.
If it is not nil, then the fields from the Interface are promoted to the "root" = reverse struct. It might be eclipsed by fields defined directly on the reverse struct, but that is not our case.
When You do something like:
foo := reverse{}, you can println it via fmt.Printf("%+v", foo) and got
{Interface:<nil>}
When you do the
foo := reverse{someInterfaceInstance}
It is equivalent of:
foo := reverse{Interface: someInterfaceInstance}
It feels to me like You declare expectation, that implementation of Interface API should by injected into your struct reverse in runtime. And this api will be then promoted to the root of struct reverse.
At the same time, this still allow inconsistency, where You have reverse struct instance with reverse.Interface = < Nil>, You compile it and get the panic on runtime.
When we look back to the specifically example of the reverse in OP, I can see it as a pattern, how you can replace/extend behaviour of some instance / implementation kind of in runtime contrary to working with types more like in compile time when You do embedding of structs instead of interfaces.
Still, it confuses me a lot. Especially the state where the Interface is Nil :(.

Related

Generic approach and recommendation how to remove dependency

I have a question regarding dependency injection.
Please consider the example below.
For example, selector() is a function that select something and guarantee return an interface
In this example
bar.node.go
type NodeTemplate struct {
Name string
}
// satisfy interface declared in db.foo.go
//but never imports anything from db.foo.go
func (node *NodeTemplate) GetUuidName() string {
if node != nil {
return node.Name
}
return
}
db.foo.go
// interface declared in db.foo.go
type Node interface {
GetUuidName() string
}
Option A
// So selector receives a map of Some interface and populate a map
func SelectSomething(nodemap map[string]Node, selectFactor string) {
// selection from db and result populate in a map
}
Option B
Another pattern SelectSomething return a Node
and it Interface
So another package will depend on importing Node
and that will introduce a dependency.
func SelectSomething(seleconsomething) []*Node {
// do selection and return a slice of SomeInterface
n := &Node{} // here it need to be concret type T
return Node
}
So based on logic I've described I see the first approach is better but in that approach, select need do concrete type allocation in order to populate a map.
Consider another example
db.foo.go
type Node interface {
GetUuidName() string
}
func inserter(node *Node) error {
// do some work
node.GetUuidName()
}
For a case like in inserter case, inserter has no external dependency, inserter just needs to receive something that satisfies the interface. Declare interfaces locally and that brake a dependancy.
But in the case of selector example, it has to do memory allocation in order to return or populate a map or return something that has concrete type T. So in both case, it has to have internal re-presentation.
So here is my question can selector somehow at run time figure out a type it receives based on the interface and instantiate an object of that type and insert to a map as an interface or return a slice of the interface. ?
By doing so selector function will have no dependancy on what it receives it just guarantee it will instantiate the same object type T
and return interface.
or can selector return interface but I guess I have to have a bi-directional interface between db package and package X or dynamic dispatcher need to do some magic ?
You want a type to behave in a certain way. That is achieved via an interface. This case is no different. Simply add the desired behavior to your interface, as demonstrated below with the Foo interface.
package main
import (
"fmt"
"reflect"
)
type Foo interface {
Bar()
TypeOf() reflect.Type
}
type Baz struct{}
func (b Baz) Bar() {
fmt.Println("I am a Fooer!")
}
func (b Baz) TypeOf() reflect.Type {
return reflect.TypeOf(b)
}
func DoSomeThing(f Foo) {
f.Bar()
fmt.Println(f.TypeOf())
}
func main() {
fmt.Println("Hello, playground")
b := Baz{}
DoSomeThing(b)
}
Run on playground

How can I implement the same function for pointers to different structs?

Suppose I have a lot of different structs, but they all share a common field, such as "name". For example:
type foo struct {
name string
someOtherString string
// Other fields
}
type bar struct {
name string
someNumber int
// Other fields
}
Further on in the program, I repeatedly encounter the situation where I get pointers to these structs (so *foo, *bar, etc.) and need to perform operations depending on whether the pointer is nil or not, basically like so:
func workOnName(f *foo) interface{} {
if (f == nil) {
// Do lots of stuff
} else {
// Do lots of other stuff
}
// Do even more stuff
return something
}
This function, which only uses name, is the same across all structs. If these were not pointers, I know I could write a common interface for each struct that returns the name and use that as the type. But with pointers, none of this has worked. Go either complains while compiling, or the nil check doesn't work and Go panics. I haven't found anything smarter than to copy/paste the exact same code for every struct that I have, so basically to implement all the functions:
func (f *foo) workOnName() interface{}
func (b *bar) workOnName() interface{}
func (h *ham) workOnName() interface{}
// And so on...
Is there a way to do this better, i.e. to only implement a simple function (or even better, no function at all) for all my structs and simply write the complicated stuff once, for all the structs?
Edit: Thank you to the answers so far, but simply using an interface of the type:
func (f foo) Name() string {
return f.name
}
for some interface that provides Name() does not work, because the pointer is not recognized as nil. See this playground: https://play.golang.org/p/_d1qiZwnMe_f
You can declare an interface which declares a function returning a name:
type WithName interface {
Name() string
}
In order to implement that interface, you types (foo, bar, etc) need to have that method - not just the field, the method.
func (f foo) Name() string {
return f.name
}
Then, workOnName needs to receive a reference of that interface:
func workOnName(n WithName) interface{} {
if (n == nil || reflect.ValueOf(n).isNil()) {
// Do lots of stuff
} else {
// Do lots of other stuff
}
// Do even more stuff
return something
}
Keep in mind that the parameter n WithName is always treated as a pointer, not an object value.
I think that's the case for reflect.
Something like:
package main
import (
"fmt"
"reflect"
)
func SetFieldX(obj, value interface{}) {
v := reflect.ValueOf(obj).Elem()
if !v.IsValid() {
fmt.Println("obj is nil")
return
}
f := v.FieldByName("X")
if f.IsValid() && f.CanSet() {
f.Set(reflect.ValueOf(value))
}
}
func main() {
st1 := &struct{ X int }{10}
var stNil *struct{}
SetFieldX(st1, 555)
SetFieldX(stNil, "SSS")
fmt.Printf("%v\n%v\n", st1, stNil)
}
https://play.golang.org/p/OddSWT4JkSG
Note that IsValid checks more than just obj==nil but if you really want to distinguish cases of nil pointers and non-struct objects - you are free to implement it.

Hidden methods in type implementations?

Going through some go sources in the net/http and related libraries, I came across something that made me curious. I'm looking at version 1.12 here.
func (p *ReverseProxy) handleUpgradeResponse(rw http.ResponseWriter, req *http.Request, res *http.Response) {
...
hj, ok := rw.(http.Hijacker)
...
conn, brw, err := hj.Hijack()
...
}
I've been seeing stuff like this in more places and also outside the standard library. What is happening here? Are some methods of an interface implementation hidden until a specific assertion happens? Why can't I just call Hijack() on the rw object?
The methods appear to be hidden, because the function takes an interface type. The interface of http.ResponseWriter does not define the Hijack() method. This is defined in the http.Hijacker interface. A concrete type may implement multiple interfaces. But even if such concrete type is passed into a scope where its type definition is an interface, additional methods will not be accessible. So in the questioned example, type assertion is performed to make make the Hijack() method available.
Some examples (playground):
package main
import (
"fmt"
)
type Ship interface {
Load(containers []string)
Condition() []string
}
type Sea interface {
Draft() int
}
// seaShip implements the Sea and Ship interfaces
type seaShip struct {
containers []string
}
// Load is only part of the Ship interface
func (ss *seaShip) Load(containers []string) {
ss.containers = append(ss.containers, containers...)
}
// Condition is only part of the Ship interface
func (ss *seaShip) Condition() []string {
return ss.containers
}
// Draft is only part of the Sea interface
func (ss *seaShip) Draft() int {
return len(ss.containers)
}
// Pirates is not defined in any interface and therefore can only be called on the concrete type
func (ss *seaShip) Pirates() string {
return "Help!"
}
// NewShip returns an implementation of the Ship interface
func NewShip() Ship {
return &seaShip{}
}
func main() {
ship := NewShip()
ship.Load([]string{"Beer", "Wine", "Peanuts"})
fmt.Println(ship.Condition())
// Won't compile, method is not part of interface!
// fmt.Println(ship.Draft())
// Assert to make Draft() available
sea := ship.(Sea)
fmt.Println(sea.Draft())
// Won't compile, methods are not part of interface!
// fmt.Println(sea.Condition())
// fmt.Println(sea.Pirates())
// Assert to the concrete type makes all methods available
ss := sea.(*seaShip)
fmt.Println(ss.Condition())
fmt.Println(ss.Pirates())
}

type INode* is pointer to interface, not interface

So trying out go for the first time today and keep running into an error to do with interfaces, I guess I don't understand them correctly. Ive tried looking around for an answer but the terminology that I'm used to is a little different from other languages so I can't piece it together. As practice I decided to implement a very simple linked list but the error I recieve is:
type INode* is pointer to interface, not interface when calling .setNext(node *Inode)
What is the reason behind this? what piece of information am I missing with interfaces?
Heres the incomplete implementation:
package main
type object interface{}
type INode interface {
GetData() object
GetNext() *INode
setNext(node *INode)
}
type ILinkedList interface {
Link(node *INode)
Unlink(node *INode)
CurrentLength() int
RemoveAt(idx int)
}
type Node struct {
data object
next *INode
}
func (n *Node) GetData() object {
return n.data
}
func (n *Node) GetNext() *INode {
return n.next
}
func (n *Node) setNext(node *INode) {
n.next = node
}
type LinkedList struct {
cur *INode
last *INode
length int
}
func (l *LinkedList) Link(node *INode) {
if l == nil {
return
}
if l.cur == nil {
l.cur = node
l.last = node
} else {
l.last.setNext(node)
l.last = node
}
l.length = l.length + 1
}
This is because in Go, an interface is just a specification of behavior. This behavior can be implemented with either a pointer receiver or a value receiver. The interface doesn't care which one is ultimately used, just as long as it fulfills the interface contract.
See this example:
https://play.golang.org/p/0AaBhB1MHBc
type I interface {
M()
}
type T struct {
S string
}
func (t T) M(){
fmt.Println("T.M fired");
}
type S struct {
S string
}
func (s *S) M(){
fmt.Println("*S.M fired");
}
func RunM(i I){
i.M()
}
func main() {
test1 := T{}
test2 := &S{}
RunM(test1)
RunM(test2)
fmt.Println("Hello, playground")
}
Both pointers to the S type and T types implement the interface I, and can be passed in to any func requiring an I. The interface doesn't care if it's a pointer or not.
You can read up about pointer receivers here: https://tour.golang.org/methods/4
I thought I would post a reference for those visiting in the future that have the same issue regarding pointers to interfaces:
When should I use a pointer to an interface?
Almost never. Pointers to interface values arise only in rare, tricky
situations involving disguising an interface value's type for delayed
evaluation.
It is however a common mistake to pass a pointer to an interface value
to a function expecting an interface. The compiler will complain about
this error but the situation can still be confusing, because sometimes
a pointer is necessary to satisfy an interface. The insight is that
although a pointer to a concrete type can satisfy an interface, with
one exception a pointer to an interface can never satisfy an
interface.
Consider the variable declaration,
var w io.Writer The printing function fmt.Fprintf takes as its first
argument a value that satisfies io.Writer—something that implements
the canonical Write method. Thus we can write
fmt.Fprintf(w, "hello, world\n") If however we pass the address of w,
the program will not compile.
fmt.Fprintf(&w, "hello, world\n") // Compile-time error. The one
exception is that any value, even a pointer to an interface, can be
assigned to a variable of empty interface type (interface{}). Even so,
it's almost certainly a mistake if the value is a pointer to an
interface; the result can be confusing.

Struct with dynamic type

I am learning Go at the moment and I write a small project with some probes which report to a internal Log. I have a basic probe and I want create new probes extending the basic probe.
I want save the objects in an array/slice LoadedProbes.
type LoadableProbe struct {
Name string
Probe Probe
Active bool
}
var LoadableProbes []LoadableProbe
The basic probe struct is:
type ProbeModule struct {
version VersionStruct
name string
author string
log []internals.ProbeLog
lastcall time.Time
active bool
}
func (m *ProbeModule) New(name string, jconf JsonConfig) {
// read jsonConfig
}
func (m *ProbeModule) Exec() bool {
// do some stuff
return true
}
func (m *ProbeModule) String() string {
return m.name + " from " + m.author
}
func (m *ProbeModule) GetLogCount() int {
return len(m.log)
}
[...]
I am using this basic struct for other probes, for example:
type ShellProbe struct {
ProbeModule
}
func (s *ShellProbe) New(name string, jconf JsonConfig) {
s.ProbeModule.New(name, jconf)
fmt.Println("Hello from the shell")
}
func (s *ShellProbe) Exec() bool {
// do other stuff
return true
}
during Init() I call the following code:
func init() {
RegisterProbe("ShellProbe", ShellProbe{}, true)
}
func RegisterProbe(name string, probe Probe, state bool) {
LoadableProbes = append(LoadableProbes, LoadableProbe{name, probe, state})
}
The Problem is now that I can't add the type Shellprobe the the LoadableProbe struct, which expects a Probe struct.
My idea was to use interface{} instead the Probe struct in the Loadable Probe struct. But when I call the New() method of the Probe object:
for _, p := range probes.LoadableProbes {
probe.Probe.New(probe.Name, jconf)
}
But I got the error: p.Probe.New undefined (type interface {} is interface with no methods)
how can I solve this problem?
If you will have common data fields in each probe type, you might consider using Probe as a concrete base type defining your base data fields and base methods, and using a new ProbeInterface interface as an abstract base type defining common expected method signatures to allow you to pass around / collect / manage different specialized probe types.
You would embed Probe into each specialized probe type, and methods and fields would be promoted according to rules of embedding. It looks like you're familiar with embedding in general, but the details are worth reviewing in the "Embedding" section of Effective Go if you haven't looked at it recently.
You could override Probe methods in specialized probe types to execute type-specific code.
It might look something like this:
type ProbeInterface interface {
New()
Exec() bool
// whatever other methods are common to all probes
}
type Probe struct {
// whatever's in a probe
}
func (p *Probe) New() {
// init stuff
}
func (p *Probe) Exec() bool {
// exec stuff
return true
}
// Probe's methods and fields are promoted to ShellProbe according to the rules of embedding
type ShellProbe struct {
Probe
// any specialized ShellProbe fields
}
// override Probe's Exec() method to have it do something ShellProbe specific.
func (sp *ShellProbe) Exec() bool {
// do something ShellProbe-ish
return true
}
type LoadableProbe struct {
Name string
P ProbeInterface
Active bool
}
func RegisterProbe(name string, probe ProbeInterface, state bool) {
LoadableProbes = append(LoadableProbes, LoadableProbe{name, probe, state})
}
There are different approaches to your question.
The most direct answer would be: You need to convert your interface{} to a concrete type before calling any methods on it. Example:
probe.Probe.(ShellProbe).New(...)
But this is a really confusing API to use.
A better approach is probably to re-think your entire API. It's hard to do this level of design thinking with the limited information you've provided.
I don't know whether this will work for you, but a common pattern is to define an interface:
type Probe interface {
New(string, JsonConfig)
Exec() bool
// ... etc
}
Then make all of your probe types implement the interface. Then use that interface instead of interface{}, as you initially did:
type LoadableProbe struct {
Name string
Probe Probe
Active bool
}
Then your syntax should work again, because the Probe interface includes a New method.
probe.Probe.New(...)

Resources