Struct composition with Go

Struct composition with Go(dave.cheney.net)

108 points by jcxplorer 11 years ago | 16 comments

zenocon 11 years ago |

This is cool, but I find this snippet a tad bizarre:

  client, server := net.Pipe()
        var buf bytes.Buffer
        client = &recordingConn {
                Conn: client,
                Writer: io.MultiWriter(client, &buf),
        }

While it seemingly works, it seems confusing to assign client to an internal field of a new struct, and then overwriting that same client variable with the newly created struct...not to mention passing it into MultiWriter.

Anyway, I like those short posts like this. I've done similar things with embedding and struct "reconstruction" in order to elicit more testable code. It's powerful and useful, indeed.

gohrt 11 years ago | |

What is the benefit of re-using the 'client' identifier? There's no closure capturing the identifier.

Compare:

        client, server := net.Pipe()
        var buf bytes.Buffer
        client = &recordingConn {
                Conn: client,
                Writer: io.MultiWriter(client, &buf),
        }

        tempClient, server := net.Pipe()
        var buf bytes.Buffer
        client = &recordingConn {
                Conn: tempClient,
                Writer: io.MultiWriter(tempClient, &buf),
        }

The latter is less confusing to me.

aleksi 11 years ago |

In the end there is no need to embed (exported) io.Writed, it should be replaced with non-exported non-anonymous field.

shoo 11 years ago |

Since the purpose of this is apparently to provide a fake structure to test against - would another viable approach have been to implement a trivial `Close` function that doesn't do anything?

(context: i am no gopher)

(edit/tangent: i wonder how method calls from inside method calls are resolved when the names are ambiguous?)

Sphax 11 years ago | |

You need quite a few more method to be a net.Conn actually: http://golang.org/pkg/net/#Conn. Easier to just overwrite the Write() method like this in that case.

TheDong 11 years ago | |

I suspect your tangent is because you don't fully understand how composition works. Basically, it's weaker than you think I believe.

I tried to write an example that demonstrates why I don't think the ambiguity you're referring to is possible.

https://play.golang.org/p/TyMJbOjDdZ

Matt3o12_ 11 years ago | |

If you just need a close that does not do anything, go has a pretty cool wrapper: `ioutil.NoopCloser`. It takes a reader and returns a reader that can be closed `io.ReadCloser`. Very useful for testing/mocking

justinsb 11 years ago |

Is it reasonable to think of this as multiple inheritance?

davecheney 11 years ago | |

Nope, this is composition, not inheritance.

justinsb 11 years ago | | |

It looks more like inheritance: the methods on net.Conn & io.Writer are automatically exposed. Are you saying that it is composition because you are "inheriting" from interfaces, which isn't traditional inheritance? Or if not, can you explain why you think of this as composition and not inheritance?

Edit: On further thought, this looks to me like composition with automatic delegation (a huge productivity benefit of inheritance). It is unusual because the combined class also implements the interfaces because of Go's interface rules, but I think that the late-binding to implementations is more similar to composition.

Rexxar 11 years ago | | |

I would say that it's inheritance without polymorphisms or a sort of mixin.

tempClient, server := net.Pipe() var buf bytes.Buffer client = &recordingConn { Conn: tempClient, Writer: io.MultiWriter(tempClient, &buf), }