What is Information Hiding?
Understand information hiding in OOP — Parnas's principle of concealing design decisions behind stable interfaces — with a Java example.
Expected Interview Answer
Information hiding is the software design principle of concealing a module’s internal design decisions — data structures, algorithms, and implementation choices — behind a stable interface, so those decisions can change later without affecting code that depends on the module.
The principle, formalized by David Parnas in 1972, is about decomposing a system so each module hides a specific design decision likely to change, such as which data structure backs a collection or which algorithm implements a lookup. Callers program against the stable interface and never need to know, or depend on, the hidden decision. This is broader than a single class’s private fields: it applies at the module, package, and API level too, guiding what a package exports versus keeps internal. The payoff is that a hidden implementation detail can be swapped — a HashMap replaced with a TreeMap, a linear search replaced with a binary search — without any change rippling out to consumers of the interface.
- Isolates the impact of design changes to a single module
- Reduces coupling between modules across a codebase
- Lets teams evolve internals independently of consumers
- Simplifies reasoning by exposing only what callers need to know
AI Mentor Explanation
A national cricket board publishes a fixed selection process — trials, form, fitness — but keeps its internal scouting network, statistical models, and coach deliberations completely hidden from the public. The board can swap its entire internal scouting methodology from one season to the next without changing what players or fans see: a published squad. That is information hiding: the decision-making mechanism is concealed behind a stable, unchanging public process.
Step-by-Step Explanation
Step 1
Identify a design decision likely to change
Pick something like a data structure, algorithm, or storage format that may evolve.
Step 2
Define a stable interface around it
Expose only the operations callers need, not the mechanism behind them.
Step 3
Hide the decision behind the interface
Keep the concrete implementation private to the module or class.
Step 4
Evolve the hidden part freely
Change the internal decision later without requiring changes to any caller.
What Interviewer Expects
- Correct attribution to Parnas's module decomposition principle
- Distinction that it applies at the module/package level, not just private fields
- A concrete example of an implementation detail changing without breaking callers
- Awareness of how it relates to, but differs from, encapsulation
Common Mistakes
- Treating information hiding as a synonym for “making fields private”
- Ignoring that it applies to module and package boundaries, not just classes
- Failing to give a concrete example of a swappable implementation detail
- Confusing it with abstraction (defining what to expose) rather than concealing why it might change
Best Answer (HR Friendly)
“Information hiding means designing a piece of software so that a decision likely to change later — like which data structure or algorithm you use internally — is tucked away behind a stable interface. Anyone using that interface never needs to know or depend on the hidden decision, so you’re free to change it later without breaking anyone who relies on you.”
Code Example
public interface UserDirectory {
void add(String userId, String name);
String lookup(String userId);
}
// Implementation detail #1: hidden inside this class
class HashMapUserDirectory implements UserDirectory {
private final Map<String, String> users = new HashMap<>();
public void add(String userId, String name) { users.put(userId, name); }
public String lookup(String userId) { return users.get(userId); }
}
// Later, swapped for implementation detail #2 with zero caller changes:
class SortedUserDirectory implements UserDirectory {
private final TreeMap<String, String> users = new TreeMap<>();
public void add(String userId, String name) { users.put(userId, name); }
public String lookup(String userId) { return users.get(userId); }
}
// Callers only ever depend on the UserDirectory interface
UserDirectory directory = new HashMapUserDirectory();
directory.add("u1", "Priya");Follow-up Questions
- Who introduced the concept of information hiding and in what context?
- How does information hiding apply beyond a single class, to packages and modules?
- What is the relationship between information hiding and interfaces?
- Can you give an example where poor information hiding caused a costly refactor?
MCQ Practice
1. Information hiding is best described as?
The principle is about concealing likely-to-change design decisions behind a stable interface, at any scope — not just field visibility.
2. Who is credited with formalizing the information hiding principle?
David Parnas introduced information hiding in his 1972 paper on module decomposition criteria.
3. Which scope can information hiding apply to?
Information hiding applies at multiple levels of decomposition, from a single class up to entire package/module boundaries.
Flash Cards
Information hiding in one line? — Concealing a design decision likely to change behind a stable interface.
Who formalized the concept? — David Parnas, in his 1972 paper on module decomposition.
What scope does it apply to? — Classes, modules, and package/API boundaries — not just private fields.
Key payoff? — Implementation details can change without breaking dependent code.