"makes it hard to cone up with good names" is not really a problem, if you have a `CreateRequest` method you name the interface `RequestCreator`. If you have a request CRUD interface, it's probably a `RequestRepository`.

The benefits outweigh the drawbacks 10 to one. The most rewarding thing about this pattern is how easy it is to split up large implementations, and _keep_ them small.

    // embedded S3Client not properly initialized
    mock := mockS3{}
    // somewhere inside the business logic
    s3.UploadReport(...) // surprise

Not sure how you hold those two things in your head at the same time, but they are anathema to each other. Different implementations of the same function name and type signature can have drastically different effects in go because side effects are everywhere in go, so you must read the implementation to understand what it does.

If this was Haskell and I could read the type signature and trust that I know what the system did with that (ignoring Rich Hickey’s point about the type signature not describing what “reverse” does) then fine, but in every function call there are unconstrained numbers of side effects, go functions which persist after the function goes out of scope and can modify any pointed to memory at any arbitrary time later… go is the Wild West in this regard. The interface method name + weak go type system function definition is not enough to tell a developer what the implementation of that interface actually does. Finally: Java’s “implements” plus excellent IDE support for Java DI allows a developer to jump to the implementation in one keyboard press, this does not exist in go. You’ll probably never know what method is actually called unless it’s runtime with the actual config on the server.

I’m not going to explain the whole reasoned argument about why it’s important for a programmer to understand program execution flow in their head clearly, Dijkstra did a much better job than I ever could with GOTO considered harmful, but check out a modern descendant of this article specifically talking about go functions, and try to internalize the point about being able to understand program execution flow:

https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

A few well defined interfaces have the advantage of being easy to understand and see usages around the codebase without the overhead of many different variants of an interface. This is extremely important if you are not familiar with a given codebase.

I'm not against segregated interfaces, but I feel like over abstracting can result in code that's harder to understand. There's a balance to be had and thought should go into introducing new interfaces, especially when working on a project with many other devs contributing.

I'm a Java dev, so I'm biased. I love being to easily understand and reason about the type system. I understand that an interface is about a set of behaviors, but when I've worked with Go code I've found it much more difficult to get my IDE to point out all the different ways some interface could be implemented. I see the advantages that Go style interfaces bring, but I personally find it harder to keep a mental model when working with Go.

The reality of development is we have to merge different design philosophies into one code base. Things can get messy. 100% agreed.

The approach I advocate for is more for a) organizing the code you do own, and b) designing in a way that you play nice with others who may import your code.

For a public interface, you have to track down all the clients, which may be infeasible, especially in an open ecosystem.

So much this. I think Go's interfaces are widely misunderstood. Often times when they're complained about, it boils down to "<old OO language> did interface this way. Why Go won't abide?" There's insistence in turning them into cherished pets. Vastly more treasured than they ought to be in Go, a meaningless thin paper wrapper that says "I require these behaviors".

Not a mock? But that's exactly what a mock is: An implementation that isn't authentic, but that doesn't try to deceive. In other words, something that behaves just like the "real thing" (to the extent that matters), but is not authentically the "real thing". Hence the name.

Not exactly the same thing, but you can use build tags to compile with a different implementation for a concrete type while under test.

Sounds like a serious case of overthinking it, though. The places where you will justifiably swap implementations during testing are also places where you will justifiably want to be able to swap implementations in general. That's what interfaces are there for.

If you cannot find any reason why you'd benefit from a second implementation outside of the testing scenario, you won't need it while under test either. In that case, learn how to test properly and use the single implementation you already have under all scenarios.

This uses reflect and is nominally checked at run time, but over time more and more I am distinguishing between a runtime check that runs arbitrarily often over the execution of a program, and one that runs in an init phase. I have a command-line option on the main executable that runs the initialization without actually starting any services up, so even though it's a run-time panic if a service misregisters itself, it's caught at commit time in my pre-commit hook. (I am also moving towards worrying less about what is necessarily caught at "compile time" and what is caught at commit time, which opens up some possibilities in any language.)

The central service module also defines some convenient one-method interfaces that the services can use, so one service may look like:

    type myDependencies interface {
        services.UsesDB
        services.UsesLogging
    }

    func init() {
        services.Register(func(in myDependencies) error {
             // init here
        }
    }

    type myDependencies interface {
        services.UsesLogging
        services.UsesCaching
        services.UsesWebCrawler
    }

    // func init() { etc. }

I also have some default fakes that things can use, but they're not necessary. They're just one convenient implementation for testing if you need them.

  // The HandlerFunc type is an adapter to allow the use of
  // ordinary functions as HTTP handlers. If f is a function
  // with the appropriate signature, HandlerFunc(f) is a
  // [Handler] that calls f.
  type HandlerFunc func(ResponseWriter, *Request)
  
  // ServeHTTP calls f(w, r).
  func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
      f(w, r)
  }