Interfaces Are Implicit

1 · Three languages, three mental models

You know two of these already. The third is the one to internalize.

# no declaration at all.
# works if .read() exists
# — discovered when called
def load(src):
    return src.read()

class File
  implements Reader {
  // MUST name Reader
  public String read(){...}
}

type File struct{}
// no "implements".
func (f *File) Read() string {...}
// satisfies Reader automatically

Go takes the safety of Java (checked at compile time — a type that's missing a method won't build) and the decoupling of Python (the concrete type never mentions the interface). The result:

2 · The consequence reviewers must know: interfaces live with the consumer

Because the implementer doesn't name the interface, the interface can be defined wherever it's used, not where the type is built. Go's strong convention — and a live review rule — is exactly that:

This is the opposite of the Java instinct (interface ships with, or above, the implementation). In Go the consumer says "I need something that can do X" and declares a tiny interface for X; any type with that method drops in.

3 · This exact pattern, in your repo

The dapp service consumes; the dapp_storage client implements. They never reference each other's interface name.

package dapp

// the service declares ONLY what
// it needs — one method.
type Client interface {
    ListDApps(ctx context.Context,
        limit, offset int64,
    ) ([]*dapp_storage.DApp, error)
}

package dapp_storage

type Client struct{ ... }

// has 5 methods, incl. this one.
// never mentions dapp.Client.
func (c *Client) ListDApps(
  ctx context.Context, limit, offset int64,
) ([]*dapp_storage.DApp, error) { ... }
// GetDAppByID, GetDAppByProtocol,
// CreateDAppByProtocol, ...

Read it like a reviewer:

• The concrete *dapp_storage.Client exposes five methods. The dapp service asks for one. The fat type satisfies the thin interface — the interface is sized to the caller's appetite, not the provider's menu.
• The compiler verifies the fit when NewService(...) is called with a *dapp_storage.Client. If ListDApps were missing or had the wrong signature, it would not compile — caught before review even runs.
• Want to test the service? Pass any struct with a ListDApps method. No mock framework, no implements. That's why the interface lives in the consumer.

4 · The two reviewer reflexes

Reflex A — "where's the real type?"

When a PR uses s.client.Foo() and client is an interface, the concrete type is wherever NewService / the DI wiring was called. Trace the constructor's argument, not the interface. The interface only tells you the contract; the wiring tells you the behavior.

Reflex B — "is this interface the right size?"

Small interfaces are idiomatic; a single-method interface named with an -er suffix (Reader, Writer, Closer) is the Go ideal. [Effective Go] A PR that introduces a 12-method interface, or defines an interface in the implementer's package "for mocking", is worth a comment.

5 · Drill — read the contract

Instant feedback. For the reps, not a grade.

Terms introduced

Added to your GLOSSARY.md:

• Interface (Go) — a named set of method signatures; a type satisfies it implicitly by having those methods.
• Implicit satisfaction — no implements; the compiler checks the method set at use time.
• Consumer-defined interface — the convention that an interface lives in the package that uses it, not the one that implements it.
• Compile-time interface assertion — var _ I = (*T)(nil), a documented, free check that *T satisfies I.