What happens if the interface changes? How would you even know that happen until runtime? If the interface is an internal one to your application no problem, just add tests to cover that code. But if you are dealing with a thrid party library and trying to conform to an internal interface, this could become a real pain point.
I think you would catch such changes at compile time?
Also, what about dependency management? I think managing dependencies is one of the main reasons for why interfaces exist in the first place (dependency inversion principle). Without explicit declaration of interfaces, how do you know upon which modules or libraries you depend? Do you have an easy way of figuring out on which interface(s) you depend, when you look at one struct/class/whatever-it-is in Go?
Interfaces should not be used to handle dependencies in Go. Go has features specifically for managing dependencies in the CLI with go get and such. Go is built around open source, so it's able to use things like git to manage dependencies (import paths for third party libraries are actually the URL to get to their library from). There are also third party managers for people who don't like the way that go get works, by putting dependencies in a vendor folder.
There is a bit of responsibility on the library maker and user though. A library maker shouldn't change an interface without documenting it, just as the user shouldn't update a dependency without reading the changes. A change in an interface will still most likely result in compile-time errors, as Go does use a strong typing system.
If the interface changes, you no longer implement the interface if your struct does not have the matching methods. This will most likely cause issues at compile-time, so you are able to catch it very early.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What happens if the interface changes? How would you even know that happen until runtime? If the interface is an internal one to your application no problem, just add tests to cover that code. But if you are dealing with a thrid party library and trying to conform to an internal interface, this could become a real pain point.
I think you would catch such changes at compile time?
Also, what about dependency management? I think managing dependencies is one of the main reasons for why interfaces exist in the first place (dependency inversion principle). Without explicit declaration of interfaces, how do you know upon which modules or libraries you depend? Do you have an easy way of figuring out on which interface(s) you depend, when you look at one struct/class/whatever-it-is in Go?
Interfaces should not be used to handle dependencies in Go. Go has features specifically for managing dependencies in the CLI with
go getand such. Go is built around open source, so it's able to use things like git to manage dependencies (import paths for third party libraries are actually the URL to get to their library from). There are also third party managers for people who don't like the way thatgo getworks, by putting dependencies in avendorfolder.There is a bit of responsibility on the library maker and user though. A library maker shouldn't change an interface without documenting it, just as the user shouldn't update a dependency without reading the changes. A change in an interface will still most likely result in compile-time errors, as Go does use a strong typing system.
Good post. Thanks.
If the interface changes, you no longer implement the interface if your struct does not have the matching methods. This will most likely cause issues at compile-time, so you are able to catch it very early.