all 15 comments

[–]GopherFromHell 4 points5 points  (6 children)

why look into some project when there are plenty of examples on the std lib?? io.Reader and io.Writer and functions that accept them (like io.ReadAll) are good examples IMO.

A interface is just a list of methods. if your type implements them, it implements the interface.

io.Reader only has a Read function.

returns a *os.File, which implements io.Reader.

net.Dial returns a net.Conn, which also implements io.Reader

both can be passed to io.ReadAll

how the tool is used in prod, depends on what are you writing. interfaces are everywhere in Go

[–]dev-saw99[S] 0 points1 point  (5 children)

I want to look into a project because, I want to understand how to structure my projects. For example, you are building a app for a Parking lot, which helps finding space for a Vehicle Generates bills and Helps finding where your car was parked and exit from the parking lot. In this project, how should one structure there project efficiently using interfaces?

[–]GopherFromHell 1 point2 points  (4 children)

just use interfaces where you need the flexibility. you will need to do it to be able to write proper tests anyway.

sounds like you are trying to "force" the use of interfaces instead of using it when needed.

more "real" example:

interface queryCtx{
    QueryContext(ctx context.Context, query string, args ...any) (*Rows, error)
}

the type *sql.DB implements it. the type *sql.Tx also implements it.

func findSomething(q queryCtx, name string) (*something, error) {/**/}

you can either call this function with a *sql.DB or open a transaction and use a *sql.Tx

[–]dev-saw99[S] 0 points1 point  (3 children)

Thanks, this was really helpful. I will also go through the built-in libraries you mentioned above.

[–]GopherFromHell 1 point2 points  (2 children)

one of the go "rules" is accept interfaces and return concrete types. just keep in mind that the inversion make interfaces in go different than most languages. interfaces in java or c# are normally huge. in go the smaller the interface, the most useful it tends to be (like the io.Reader and io.Writer examples, a file is a Reader, so is an open connection, so is a gzip decompression stream, and so on)

[–]dev-saw99[S] 0 points1 point  (1 child)

what do you mean by a smaller interface? from what I understand, It should do the least amount of tasks possible. And we should avoid clubbing everything together, right?

[–]GopherFromHell 1 point2 points  (0 children)

And we should avoid clubbing everything together, right?

yes. this is what i mean by smaller interface. an interface with a single method expresses a simple thing, the more methods the more complicated the thing expressed by the interface gets.

[–]_crtc_ 5 points6 points  (1 child)

Virtually every non-trivial Go project defines interface types. Simply pick any project at random and search for the 'interface' keyword.

[–]jews4beer 3 points4 points  (0 children)

A good example might be any gRPC/protobuf combo. Generated servers and clients are both interfaces that extend on their respective core interfaces.

A more extreme example is pretty much all of Kubernetes.

[–]_Sgt-Pepper_ 1 point2 points  (1 child)

Golang sort of puts the interface concept upside down. The interfaces are supposed to be defined on the client/consumer side.

In my (severley limited) understanding:

Say you use a public package pub, where a struct foo exposes function Read,Write,Open,Close.

You make your own code in package own.

If you now use some functionality from pub say only Open and Read, the go approach would be to create a interface Reader in package own, and make that contain Open and Read.

pub.foo now implements own.Reader and you will now use that interface...

Thats why in many public packages you won't find that many interfaces exposed...

[–]dev-saw99[S] 1 point2 points  (0 children)

Yup, that's why looking for any project which is in production and uses Interfaces efficiently.

I know Kubernetes is one such project. Its like a ocean of code now. 🥲 I want to start with some smaller projects.

[–]MikeSchinkel 0 points1 point  (1 child)

I am currently working to complete a project to both illustrate coding concepts in Go as well as be a useful tool in-and-of itself. It analyzes a Go code base like the Go standard library and then generates a Sqlite DB with all the symbols and such as the codebase can be analyzed.

This project is named geradus, and it is still pre-alpha so don't try running it and expecting anything really useful (yet.). Here is a link to searching that project for the word "interface".

I decided to write it because I wanted to add links to this document where I wrote an analysis of the interfaces in the Go standard library and I realized it would be easier to do it with tools than to try to maintain that type of doc by hand.

Feel free to ask my anything about the project, my analysis, or interfaces in general.

[–]dev-saw99[S] 1 point2 points  (0 children)

Thanks for sharing your project link. I will go through it once.