#Help understanding implicit interface satisfaction in Go REST server

9 messages · Page 1 of 1 (latest)

slate badger
#

Hey, I’m currently learning Go and building a REST API, but I’m getting confused about implicit interface satisfaction. I kind of understand the basic idea, that a type implements an interface just by having the required methods, but when I see it used in different places in a real project, I get lost.

I’m following a tutorial to learn what to use, when, and how. But the instructor sometimes manipulates the request and response variables by wrapping them in custom structs and things like that. For example, creating a custom responseWriter struct that embeds http.ResponseWriter and overrides WriteHeader to capture the status code.

Not limited to this, but I am looking for a general understanding of this topic, as I believe this is the topic that is holding me from getting a better knowledge of go.

I don’t fully understand when and why this pattern is used, and how to recognize it quickly when reading a codebase. It makes it hard for me to follow what’s going on.

I attached a small example below. Can someone explain in simple terms what’s happening here, why it’s done this way, and how I should think about implicit interfaces when building REST APIs in Go?

I am open to reading article/ referring a book/ watching a tutorial, any which gives me an in-depth understanding of what to use when and how in Implicit Interface Satisfaction.

visual arrow
# slate badger Hey, I’m currently learning Go and building a REST API, but I’m getting confused...

when you embed the interface into your struct, when you initialize it, you provide another struct that implements that interface. now your struct has another struct inside of it that implements the interface. so you don't need to worry about defining ALL the necessary methods. you can now create a method with the same name to override the embedded implementation. so u only have to rewrite the methods u want to not be the same as the embedded implementation

slate badger
visual arrow
# slate badger There’s also this `io.Reader’ and ‘io.Writer`, and they use different data struc...

so there are different ways / reasons you would want to write or read data. but it's useful to have an overall interface so that you can have different implementations that can be used by the same function, and all u gotta do is change how ur initializing the structs that implement the reader. honestly i also sometimes get confused by how those work. luckily, unless ur making something really complex, you can just use the default implementations that the stdlib provides, like bufio.reader/writer and http.responsewriter

#

unsure how much that helps but hopefully someone smarter will see this and help

slate badger
slate badger
visual arrow
#

but generally the idea is that if i have a struct that implements io.reader, i can use that in my implementation for when i'm embedding, and now, if everybody agrees to make writers implement that interface, i can kinda mix and match between the implementations and everything still will work out.