What is Interface Pollution in OOP?
Interface pollution explained — how interfaces bloat over time and how to prevent it with focused, cohesive design.
Expected Interview Answer
Interface pollution is the ongoing design mistake of adding methods to an existing shared interface that are only relevant to some implementers, gradually turning a once-focused contract into a bloated, low-cohesion one over time.
Unlike a fat interface, which describes the end state, interface pollution describes the process: each individual addition often looks reasonable in isolation ("just one more method"), but the cumulative effect couples every implementer, including unrelated ones, to methods they don’t use. This typically happens under time pressure, when it feels faster to extend an existing well-known interface than to design a new one and update call sites. The consequence is the same as a fat interface: stub implementations, brittle contracts, and every change rippling across implementers that never needed the new method. Preventing it requires discipline at each addition point: asking whether a new method belongs on this interface for every implementer, or whether it should live on a new, narrower interface instead.
- Naming the process helps catch it at each incremental addition, not just after the fact
- Keeps interfaces cohesive as a codebase evolves over years
- Avoids the “just one more method” trap that leads to fat interfaces
- Encourages new-interface-by-default thinking during code review
AI Mentor Explanation
A club’s "Player" registration form starts simple, but over several seasons administrators keep tacking on fields for scoring officials, groundskeeping duties and sponsorship contacts because it’s easier than making a new form. Years later, every player must answer irrelevant groundskeeping questions just to register. That gradual, addition-by-addition creep onto one shared form, rather than a single bad decision, is interface pollution — the process that produces a fat interface over time.
Step-by-Step Explanation
Step 1
Recognize it as a process, not a state
Interface pollution is the gradual accumulation of unrelated methods onto a shared interface over time.
Step 2
Catch it at the point of addition
Ask whether every implementer of the interface genuinely needs the new method being added.
Step 3
Prefer a new narrow interface
When the new method only applies to some implementers, create a separate interface for it instead.
Step 4
Audit periodically
Review long-lived interfaces for stub/no-op implementations as a signal that pollution has already occurred.
What Interviewer Expects
- Distinguishing interface pollution (the process) from a fat interface (the resulting state)
- Understanding it typically stems from convenience/time pressure during incremental changes
- A concrete prevention strategy: asking “does every implementer need this?” before adding
- Awareness that it is caught earlier through code review discipline, not just refactoring later
Common Mistakes
- Treating interface pollution and fat interface as identical with no distinction
- Not explaining why it happens (incremental convenience, not a single bad decision)
- Offering no concrete prevention mechanism, only “split it later”
- Ignoring the code-review angle as a real prevention point
Best Answer (HR Friendly)
“Interface pollution is what happens when people keep adding methods to an existing interface over time because it feels easier than creating a new one, even though the new method only applies to some of the classes that implement it. Each addition seems harmless on its own, but eventually you end up with a bloated interface where many implementers are stuck with methods they don’t need. The best defense is asking, at the moment you add a method, whether every current implementer of that interface actually needs it.”
Code Example
// Version 1: clean, focused
interface Repository<T> {
T findById(String id);
void save(T entity);
}
// Version 2: "just one more method" added for one use case
interface Repository<T> {
T findById(String id);
void save(T entity);
void archiveOldRecords(); // only some repos support archiving
}
// Version 3: pollution continues
interface Repository<T> {
T findById(String id);
void save(T entity);
void archiveOldRecords(); // not all repos support this
void exportToCsv(); // not all repos support this either
}
// Fix: segregate the extras into their own interfaces
interface Archivable { void archiveOldRecords(); }
interface CsvExportable { void exportToCsv(); }
class UserRepository implements Repository<User> {
public User findById(String id) { return null; }
public void save(User entity) { }
// no forced stubs for archiving or CSV export
}Follow-up Questions
- How is interface pollution different from a fat interface?
- What review practice helps prevent interface pollution?
- How would you refactor an already-polluted interface safely in a large codebase?
- Does interface pollution apply to abstract classes too, or only interfaces?
MCQ Practice
1. Interface pollution best describes?
Interface pollution is a process that unfolds over time, one seemingly small addition at a time.
2. Interface pollution most commonly happens because?
Under time pressure, extending an existing interface feels more convenient than introducing and wiring up a new one.
3. The best defense against interface pollution is?
Checking relevance to all implementers at the moment of addition catches pollution before it accumulates.
Flash Cards
Interface pollution in one line? — The gradual, incremental accumulation of unrelated methods onto a shared interface.
How does it differ from a fat interface? — Pollution is the process over time; fat interface is the resulting bloated state.
Main cause? — Convenience — extending an existing interface feels faster than designing a new one.
Best prevention? — Ask at each addition whether every implementer genuinely needs the new method.