Header Interface vs Role Interface
Header vs role interfaces explained — Interface Segregation Principle, narrow consumer-specific contracts, and a Java example.
Expected Interview Answer
A header interface exposes every public method of a single concrete class as one large interface mirroring that class, while a role interface is a small, client-specific interface that groups only the methods a particular caller actually needs.
Header interfaces are extracted mechanically, usually one per class, and grow with the class, so callers still depend on operations they never call, which keeps coupling high even though an interface exists. Role interfaces are designed from the consumer’s point of view: each interface represents one narrow role or capability, such as Readable or Closeable, and a single class can implement many small role interfaces simultaneously. This maps directly onto the Interface Segregation Principle — clients should not be forced to depend on methods they do not use. Martin Fowler popularized the header versus role interface distinction, and modern languages favor role interfaces because they minimize the surface area exposed to each consumer and make mocking or substituting behavior in tests far simpler.
- Minimizes the API surface exposed to each caller
- Reduces unnecessary coupling and easier fake/mocking in tests
- Lets one class satisfy many independent roles
- Aligns naturally with the Interface Segregation Principle
AI Mentor Explanation
A header interface is like handing every teammate the entire captain’s rulebook covering batting orders, bowling changes, and fielding placements, even though a fielder only ever needs to know their catching signals. A role interface instead gives the fielder just a small card listing their specific position duties, the bowler a separate card for over limits, and the wicketkeeper another for stumping signals. One all-rounder player can hold several of these small role cards at once without ever needing the full rulebook. That is the difference: one bloated interface mirroring the whole captain versus many narrow, purpose-built ones per role.
Step-by-Step Explanation
Step 1
Identify each consumer
List the distinct callers of a class and what subset of behavior each one actually needs.
Step 2
Define one interface per role
Create a small interface per capability (e.g. Readable, Closeable) instead of one giant interface.
Step 3
Implement multiple role interfaces
Have the concrete class implement all the narrow role interfaces it supports.
Step 4
Depend on the narrow role, not the class
Consumers reference the small role interface type, not the concrete class or a header interface.
What Interviewer Expects
- Correct definition distinguishing header (class-mirroring) from role (consumer-specific) interfaces
- A link to the Interface Segregation Principle
- Awareness that one class can implement several role interfaces
- A concrete example (e.g. Readable/Writable/Closeable) rather than an abstract description only
Common Mistakes
- Treating “interface” and “role interface” as synonyms
- Extracting one interface per class instead of per capability
- Not recognizing ISP as the guiding principle behind role interfaces
- Assuming role interfaces require multiple inheritance of implementation, not just of type
Best Answer (HR Friendly)
“A header interface just mirrors everything a class can do in one big interface, so anyone using it depends on far more than they actually need. A role interface instead is a small interface built around one specific job a caller needs done, and a single class can implement several of these small role interfaces at once. I prefer role interfaces because they keep dependencies minimal and make testing much easier since you only mock the tiny slice of behavior you actually use.”
Code Example
// Header interface: mirrors the whole class
interface FileHandlerHeader {
void read();
void write(String data);
void close();
void compress();
void encrypt();
}
// Role interfaces: one narrow contract per consumer need
interface Readable { void read(); }
interface Writable { void write(String data); }
interface Closeable { void close(); }
class LocalFile implements Readable, Writable, Closeable {
public void read() { System.out.println("reading"); }
public void write(String data) { System.out.println("writing " + data); }
public void close() { System.out.println("closed"); }
}
// A logger only needs to know how to write, nothing else
void logMessage(Writable target, String msg) {
target.write(msg);
}Follow-up Questions
- How does the header vs role interface distinction relate to the Interface Segregation Principle?
- Can a class implement more than one role interface at once? Give an example.
- Why do role interfaces make unit testing easier?
- What is the downside of extracting a header interface per class?
MCQ Practice
1. A role interface is best described as?
Role interfaces are narrow and designed from the consumer perspective, unlike header interfaces that mirror the whole class.
2. Which design principle is most directly expressed by role interfaces?
ISP states clients should not depend on methods they do not use, which role interfaces directly implement.
3. A header interface typically has a cardinality of?
Header interfaces are usually extracted mechanically, one per class, exposing the class's full public surface.
Flash Cards
Header interface in one line? — An interface mirroring every public method of a single class.
Role interface in one line? — A small, consumer-specific interface grouping only the methods one caller needs.
Which principle do role interfaces express? — The Interface Segregation Principle.
Can one class implement multiple role interfaces? — Yes — that is the whole point; each role is independent.