I don't necessarily consider the "multiple implementations" case as being truly preemptive -- if there really are multiple implementations (e.g. the "hash" package from the standard library).
I'm much more concerned about interfaces that are defined by an API producer -- for one and only one impl -- and then adding a bunch of extra (often autogenerated) code to deal with that. t. On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote: > On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples <t...@timpeoples.com> wrote: > >> >> For years I've read the old adage, "Accept interfaces, return structs" >> and have spent years working to instill this understanding among my >> colleagues. I gathered a great many skills while learning Go (and acquiring >> readability) back in the day -- and one of the strongest of those is the >> idea that interfaces should be defined by their consumer instead of an API >> producer -- but I've now been away from Google longer than I was there and >> I'm beginning to suspect that the general consensus among the *Go >> Literati* may have shifted around some things -- like preemptive >> interfaces. >> >> My arguments against preemptive interfaces have recently run into more >> and more pushback -- especially among the influx of developers coming from >> the Java and/or C# world who seem to continually reject any notion that Go >> should be any different from the way they've always done things. >> >> This has recently come to a head with a brand new job (I'm 3 weeks in) >> where virtually all of their services are built atop a dependency injection >> framework having a data model with dozens (if not hundreds) of preemptive >> interfaces and my initial, cursory review tells me the codebase is at least >> an order of magnitude more complex that it needs to be. (Note, I was told >> that none SWEs at this company (other than myself) knew any Go before they >> started). >> >> So, my questions to the group are thus, "Should I even care about this at >> all? Are preemptive interfaces now considered the norm with Go? Or, should >> I just shut up and crawl back into my hole? >> > > I believe both approaches have their uses. What you call preemptive > interfaces can be effectively used to hide implementation details where > multiple implementations can exist. This approach can coexist very well > with interfaces defined by the consumer. For example we have services that > are written to implement an interface, so it becomes a logical deployment > unit. Then we have consumers of that service that define parts of the > interface service implements, so the consumer is not dependent on the > complete service, and we can add any interceptors/filters. > > However, I agree with your assessment that especially newcomers tend to > choose the traditional "interface is a contract" approach. In addition to > the effect of other languages, people seem to like "clean architecture". > Nevertheless, even with people dedicated to clean architecture, the idea of > "interface parts" seems to resonate, especially when you show that you can > define an interface on the consumer side that combines parts of multiple > "contracts". > > >> >> TIA, >> Tim. >> >> -- >> 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/34469b98-c37e-4a1d-af13-729b639a71ben%40googlegroups.com.
