On Tuesday, August 9, 2022 at 3:52:13 PM UTC-4 t...@timpeoples.com wrote: > I've come to learn that my new shop is ... utilizing ... a complete > dependency injection framework and rather strict adherence to *Clean > Architecture*™ > <https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html> > > -- (likely from the scripts in this repo > <https://github.com/thnkrn/go-gin-clean-arch>) which goes a long way > towards explaining why so much of the code looks like Java written in Go > syntax. > Sounds like your new shop is programming in GWAIJ[1].
Yeah, I have run into that in my current shop, too. On Tuesday, August 9, 2022 at 3:35:48 PM UTC-4 rog wrote: > One significant argument against preemptive interfaces is that you can't add a method to an interface type without breaking compatibility. Exactly. Which is why single method (or at least only a few method) interfaces are preferred in Go vs. large, monolithic interfaces. I do see the value in having an interface with methods used as a contract for an extension — like a database driver — but those need to be very carefully considered with all efforts made up front for them to be as complete as possible upon publishing. Otherwise when modifying those interfaces later to add requirements that were not previously understood all the client code that uses them break or you need to version your interfaces, e.g. DBDriver, DBDriver2, etc, which I have not seen done (much?) in Go. But I am sure I am preaching to the choir on this broader point. On Wednesday, August 10, 2022 at 4:17:21 AM UTC-4 Henry wrote: > Someone also mentioned that you cannot add methods to an interface without breaking compatibility. The only case that this is true is when you have no control over the implementation. If you have control over the implementation, I don't see why you can't add methods to an interface and change its implementation in the same way you would to a struct if you are to return a struct. In my experience having control over the implementation is not a black-and-white thing, unless you are the sole developer on a project. What I have found is a desire to limit changes in code reviews that could affect other parts of the code and a desire to keep commits small to make reviewing code easier. While I don't always agree with my colleagues on that rationale in all cases, these are still organizational pressures that developers can face. Changing an interface can cause large ripples in a tested and approve codebase requiring many different files to be updated, and again in my experience those are often frowned on. Which, the moral of the story is: strive not to change interfaces once published and in use when and if you can avoid it. -Mike [1] Go Written As If Java -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c632a282-21b3-4f3c-8594-0d3f8fa3a884n%40googlegroups.com.
