How does information hiding relate to encapsulation, and is a class with public fields encapsulated?

## Two ideas often blurred together These terms are used loosely, but pulling them apart clarifies a lot of interview confusion. ### Encapsulation **Encapsulation** is the object-oriented principle of **bundling** an object's **state** (its data) together with the **behavior** (methods) that operates on that state, inside one unit — the class — and presenting it through a coherent interface. The emphasis is on *cohesion*: the data and the operations that belong together live together, and the class is the unit you reason about, pass around, and reuse. ### Information hiding **Information hiding** is the narrower discipline of **restricting access** to an object's internal details so the outside world can't see or depend on them. In Java this is concretely done with **access modifiers** — primarily making fields `private` and exposing only the methods callers genuinely need. The emphasis is on *concealment*: hide the representation and implementation so callers depend only on a stable contract. ### How they fit together Think of it as: encapsulation = "put the data and behavior in one box"; information hiding = "don't let people reach inside the box." The two reinforce each other and in everyday speech "encapsulation" usually implies both. But they're separable, which the next question exposes. ## The litmus test: a public-field class ```java public class Point { public int x; // public field public int y; } ``` - **Is it encapsulated (bundling sense)?** Loosely yes — `x` and `y` are bundled together, and you could add methods that use them. It's a unit. - **Does it hide information?** No. The representation (two `int`s named `x` and `y`) is fully exposed. Any caller can write `p.x = -5` with no validation, and if you ever wanted to store the point in polar coordinates instead, every caller breaks. So a public-field class has the *form* of a class but throws away the main *benefits*: it can't validate, can't enforce invariants, can't change its representation, and tightly couples callers to its internals. That's why "is it encapsulated?" is a slightly trick question — the honest answer is "it bundles but doesn't hide, so it gives up most of what encapsulation is for." ## Why the distinction matters in practice - It explains why "I made the fields private" plus a leaking getter (see the defensive-copy question) is still poor hiding even though it's nominally encapsulated. - It explains why exposing internal types or implementation classes through a public API breaks hiding even when each individual class has private fields. - It guides API design: encapsulate *behavior*, not just data — the strongest hiding exposes operations (`deposit`, `transfer`) rather than raw accessors. ## A note on records and value-like data Sometimes a pure data carrier with no invariants (like a coordinate pair) genuinely has nothing to hide. The modern idiomatic answer there is a **record**: `record Point(int x, int y) {}`. Its components are private final fields with public accessors and it's immutable — so it provides hiding *and* immutability with no boilerplate, which is strictly better than public mutable fields even for 'dumb data.'