When should a class expose getters and setters at all, and what are the alternatives for good information hiding?

## The default-getter/setter habit and why it's wrong Many developers, and most IDE 'generate getters and setters' tools, produce a full read/write accessor pair for every field: ```java public class Order { private OrderStatus status; public OrderStatus getStatus() { return status; } public void setStatus(OrderStatus status) { this.status = status; } } ``` This *looks* like encapsulation (the field is private) but achieves almost none of its benefits. `setStatus(...)` lets any caller move the order to any status with no rules — e.g. `SHIPPED` → `DRAFT` — so the class no longer owns its own lifecycle. The representation ("an order has a settable status field") is now part of the public contract, so it can't change. This is the **anaemic / reflexive accessor** anti-pattern. ## Principle 1: expose only what's needed Information hiding is about a **minimal public surface**. Each public member is a promise you must keep forever. So: - Add a **getter only when a caller truly needs to read that value** (display, serialization, a legitimate query). - Add a **setter only when the value legitimately changes after construction and there's no better operation to model that change.** Fewer accessors = fewer dependencies on your internals = more freedom to evolve. ## Principle 2: prefer immutability over setters The cleanest way to avoid bad setters is to not have them. Build the object fully and validly in its constructor (or via a builder/factory), make fields `private final`, and provide read accessors where needed: ```java public final class Money { private final long amountCents; private final String currency; public Money(long amountCents, String currency) { if (amountCents < 0) throw new IllegalArgumentException(); this.amountCents = amountCents; this.currency = Objects.requireNonNull(currency); } public long amountCents() { return amountCents; } public Money plus(Money other) { /* returns a NEW Money */ } } ``` Immutable objects can't enter an invalid state after construction, are thread-safe, and are safe to share and cache — and there's nothing mutable to leak. **Records** make this trivial for plain data: `record Money(long amountCents, String currency) {}` with validation in a compact constructor. ## Principle 3: expose behavior, not state (Tell, Don't Ask) The strongest hiding replaces accessor pairs with **intention-revealing operations** that keep the rules inside the object. Compare: ```java // Ask: caller reaches into state and enforces the rule externally if (account.getBalance() >= amount) { account.setBalance(account.getBalance() - amount); } // Tell: the object owns the rule account.withdraw(amount); // throws if insufficient funds ``` The "Tell, Don't Ask" form means the balance rule lives in exactly one place, can never be forgotten or duplicated, and the field is never directly exposed. This is the heart of object-oriented design: objects with behavior, not data bags with external procedures. ## When getters/setters ARE appropriate - **DTOs / API boundary objects** that exist purely to carry data across a wire (JSON, forms) often legitimately need accessors so frameworks can read/write them — though even here records or constructor binding are increasingly preferred. - **Read-only queries** for display, reporting, or serialization, returning immutable values or defensive copies. - **Frameworks** (JPA entities, JavaBeans-based tools) may require the bean shape; that's a pragmatic concession, not a design ideal. Even then, a getter should expose a **stable concept**, not necessarily a raw field — e.g. `getFullName()` deriving from parts — so the internal layout can change. ## Decision checklist 1. Does any caller actually need this value? If not, no getter. 2. Can the object be fully and validly constructed up front and never change? If so, no setters — make it immutable / a record. 3. Is there a meaningful operation the caller is really trying to perform? Expose that operation (Tell, Don't Ask) instead of get-mutate-set. 4. If you must expose state, return immutable types or defensive copies, and expose concepts, not raw fields. ## Cost / nuance This is design judgment, not a hard rule. Over-modeling trivial data carriers with elaborate behavior is its own waste; some layers (DTOs, view models) really are just data. The senior skill is matching the approach to the role of the class: rich behavior + tight hiding for domain objects; plain accessors/records for boundary data.