What is information hiding in Java, and how do you apply it to a class?
answer
- private fields + public methods
- controlled choke point for validation
- free to change internal representation
- expose only what's needed (not every field)
- the mechanic behind encapsulation
basics
~20 sInformation hiding means keeping a class's internal data private and letting outside code touch it only through public methods. In Java you mark fields private and add public getters/setters so the class controls how its state is read and changed.
solid answer
~40 sInformation hiding is the practice of hiding a class's internal state and implementation details behind a controlled public interface, so callers depend on what the class does, not how it stores data. In Java you implement it by declaring fields private and exposing access through public methods (getters/setters or richer behavior). This lets you validate inputs, compute derived values, change the internal representation without breaking callers, and keep invariants intact. It is the concrete mechanic behind the encapsulation pillar of OOP. A common refinement is to expose only what's needed: not every field needs a setter, and many should be read-only or fully immutable. The goal is reduced coupling and a class that's safe to evolve.
go deeper
Can state that fields should be private and accessed via public getters/setters, and write a simple class that does so.
Explains that hiding lets you validate inputs and swap internal representation without breaking callers, and that not every field needs a setter.
Frames hiding as minimizing the public surface to reduce coupling and protect invariants; argues against reflexive getter/setter pairs and prefers behavior-rich or immutable designs.
Connects information hiding to module/API boundary design (e.g. Java modules, package-private types, exposing interfaces not implementations) and to long-term evolvability across teams.
## The problem it solves A **class** in Java bundles **data** (fields, also called instance variables) with **behavior** (methods that operate on that data). If other code can read and write those fields directly, the class loses control over its own state: anyone can set an invalid value, and any change to how the data is stored would break every caller. **Information hiding** is the design discipline of preventing that by hiding the internal data and only exposing a deliberate, controlled set of operations. ## Key terms (defined from scratch) - **Field / instance variable:** a variable declared inside a class that holds part of an object's state, e.g. `private int balance;`. - **Access modifier:** a keyword that controls who can see a member. `private` = only this class; `public` = anyone; (also `protected` and package-private — the default with no keyword). - **Public interface / API:** the set of members other code is allowed to use. With information hiding this is the public methods, not the fields. - **Invariant:** a rule that must always hold for an object to be valid (e.g. "balance is never negative"). Hiding lets the class enforce invariants. - **Coupling:** how much one piece of code depends on the internals of another. Hiding reduces coupling — callers depend only on method signatures. - **Encapsulation:** the broader OOP pillar of bundling data + behavior and restricting access; information hiding is the part about restricting/hiding access. ## How you actually do it in Java 1. Declare every field `private`. 2. Provide `public` methods for the operations callers legitimately need. 3. Inside those methods, validate inputs and maintain invariants. 4. Expose only what's necessary — omit a setter if a field shouldn't change after construction. ```java public class BankAccount { private long balanceCents; // hidden state public long getBalanceCents() { // controlled read return balanceCents; } public void deposit(long cents) { // controlled write with a rule if (cents <= 0) throw new IllegalArgumentException("must be positive"); balanceCents += cents; } } ``` Because `balanceCents` is private, no caller can set it to a negative number directly. Tomorrow you could store the balance as a `BigDecimal` or in cents-as-long differently, and as long as `getBalanceCents()`/`deposit()` keep working, callers don't change. ## Why it matters - **Validation:** the setter/method is the single choke point to reject bad data. - **Freedom to change representation:** the internal field can be renamed, retyped, or computed on the fly without touching callers. - **Invariants stay true:** the object can never enter an illegal state from outside. - **Smaller surface = less to break:** fewer public things means fewer things other code can depend on. ## What it is NOT Information hiding does not mean "add a getter and setter for every field." Mechanical getter/setter pairs that just read/write the field add ceremony without hiding anything. Real hiding is choosing *which* operations to expose and keeping the rest private — sometimes that means no setter at all (read-only or immutable types).
- If every field just gets a trivial getter and setter, have you really hidden anything?Not really. Exposing a full get/set pair for each field replicates direct field access through methods. True hiding means choosing which operations to expose, validating in them, and often omitting setters — so the class controls its state and can change its representation.
saying these in an interview costs you the question
- Claiming information hiding just means 'add a getter and setter for every field' — that often hides nothing.
- Saying it is the same thing as encapsulation; hiding is the access-restriction part of the broader encapsulation pillar.
- Thinking private is about security/secrecy of values at runtime rather than compile-time access control and design coupling.