Under the Interface Segregation Principle, who should define an interface — the component that implements it or the component that calls it? Explain the difference between a role interface and a header interface.

## The question behind the question ISP tells you interfaces should be narrow. But *narrow according to whom?* The answer is what makes ISP operational rather than aspirational: **narrow according to the client's requirement**. That immediately implies the client's needs should drive the interface's shape — and often its physical location and ownership too. ## Two shapes, named (Martin Fowler's distinction) ### Header interface An interface that restates the entire public surface of one concrete class, usually 1:1, usually named `IThing` or `ThingInterface` for class `Thing`. ``` class UserService { register(); login(); resetPassword(); exportCsv(); deactivate(); } interface IUserService { register(); login(); resetPassword(); exportCsv(); deactivate(); } ``` What it achieves: a seam for mocking, and a name to inject in a DI container. What it does **not** achieve: any reduction in what clients depend on. Every caller still sees five methods; every change to `UserService`'s surface still changes the interface; every mock still fakes five members. The term "header interface" comes from C/C++ header files, which likewise mirror an implementation's declarations. It is not always wrong — it can be a deliberate compatibility or plugin boundary — but it is not ISP, and shipping one per class as a policy is a well-known anti-pattern ("interface for every class"). ### Role interface An interface named for a **capability a caller needs**, containing only the members that capability requires. ``` interface PasswordHasher { hash(pw); verify(pw, digest); } interface Clock { now(); } interface OrderReader { findById(id); } ``` One concrete class may satisfy several roles. A role interface is stable because it changes only when the *requirement* changes, not when the implementation grows a new feature. ### Naming tell Header interfaces are named after the implementation (`IUserRepository`, `UserServiceInterface`). Role interfaces are named after the need, often with an `-er`/capability noun (`Hasher`, `Notifier`, `Printer`, `Sink`, `Source`, `AuditReader`). If deleting the concrete class would make the interface's name meaningless, it is probably a header interface. ## Ownership: where the interface *lives* Beyond shape, there is the question of which module the interface source file belongs to. - **Implementer-owned** (the traditional layout): the `persistence` module declares `OrderRepository` and `JdbcOrderRepository`; the `orders` domain depends on the persistence module to get the type. The high-level policy now has a compile dependency on the low-level module. - **Consumer-owned** (Dependency Inversion applied): the `orders` domain declares the `OrderRepository` port it needs; the persistence module depends on the domain and implements it. Dependencies now point inward, toward policy. This is the **Ports and Adapters / hexagonal / clean architecture** arrangement, and the "port" is exactly an ISP-shaped role interface. Consumer ownership makes ISP self-enforcing: you literally cannot put a method in the port that the consumer does not call, because the consumer wrote it. ### Language support - **Go**: interfaces are satisfied *structurally*; the convention is to declare them in the consuming package. `io.Reader` is one method. An implementer need not import the consumer at all. Go's proverb — "the bigger the interface, the weaker the abstraction" — is ISP as folklore. - **TypeScript**: structural typing lets a function parameter declare an inline shape (`{ read(k: string): Blob }`) covering exactly what it uses; no nominal declaration or implementer cooperation required. - **Java/C#/Kotlin**: nominal typing means the implementer must explicitly declare the interface, so consumer-owned ports require the implementing module to depend on the consumer's module. That is the intended direction under DIP; module systems (Java modules, Spring Modulith, .NET assemblies) can enforce it. - **Rust traits / Swift protocols**: traits can be implemented for foreign types (with orphan-rule constraints), and protocol extensions let you retrofit conformance — both make consumer-defined roles practical. ## Trade-offs and honest limits 1. **More types.** Several small ports instead of one interface. Mitigate by naming them well and colocating them with the consumer, not in a global `interfaces/` dumping ground. 2. **Duplicate-looking ports.** Two consumers may each define a nearly identical one-method port over the same implementation. This is usually *correct* — they can evolve independently — but it looks like duplication in review; be ready to defend it. 3. **Discovery.** With Go-style structural interfaces, finding all implementers is harder; with nominal languages, `implements` gives you the list. 4. **Public API/plugin boundaries** genuinely may need a broad, implementer-owned contract that third parties code against; there, stability and documentation beat minimality, and default methods exist for evolution. 5. **Don't add an interface at all** if there is exactly one implementation, no test seam need (because you can construct the real thing cheaply), and no policy/detail boundary to invert. "Interface per class" is the failure mode this whole discussion exists to avoid. ## Practical checklist - Name it after the requirement, not the implementation. - Include only members the requirement invokes. - Put it next to the consumer when it is a policy/detail boundary. - Let one class implement several ports; do not create a class per port. - Delete it if it exists only because "everything should have an interface".