{"title":"Data Hiding","description":"","content":"As covered in *Encapsulation Basics*, the point of wrapping a class's fields behind methods is to keep callers from depending on the internal layout and to keep bad data from sneaking in. That whole story rests on one mechanism: the ability to say \"this part of the class is mine, that part is yours.\" Java spells out those rules with four access modifiers, and these choices decide what is hidden and what is exposed. This lesson covers the four modifiers in depth, the gotchas around the package-private default and `protected`, and the two patterns that finish the job: defensive copies and validating setters.\n\n---\n\n# The Four Access Modifiers\n\nJava has four access levels for fields, methods, constructors, and (for top-level types) classes. Three of them are keywords. The fourth, the most common default, has no keyword at all.\n\n\n| Modifier | Keyword | Visible to |\n| --- | --- | --- |\n| `public` | `public` | Everyone |\n| `protected` | `protected` | Same package, plus subclasses in any package |\n| package-private | _(none)_ | Same package only |\n| `private` | `private` | Same class only |\n\n\nThat single table is the whole access-control story for the language. Everything else is consequences and corner cases. Read it from top to bottom and the levels get strictly tighter: each row can see everything the row below it can see, plus a bit more.\n\nThe same idea drawn out:\n\n\n```mermaid\nflowchart LR\n Pub[\"public
any class anywhere\"]:::cyan\n Prot[\"protected
same package
+ subclasses elsewhere\"]:::orange\n Pkg[\"package-private
same package only\"]:::green\n Priv[\"private
same class only\"]:::red\n\n Pub --> Prot --> Pkg --> Priv\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe arrow direction is \"shrinks down to.\" A `public` member is the most visible. A `private` member is the least. The boundary crossed in each step is a real one: classes versus subclasses, package versus other packages, the world versus the package.\n\nThe modifier goes right after the access slot in the declaration, before any other modifier like `static` or `final`:\n\n\n```java\npublic class Product {\n public String name;\n protected double cost;\n int stockCount; // package-private (no keyword)\n private String sku;\n}\n```\n\n\nFour fields, four levels. The compiler reads each declaration and records the visibility. Anything trying to touch a field from outside the allowed zone gets a compile error.\n\nAccess control is enforced entirely at compile time for normal source. There is no runtime check and no overhead for picking a tighter modifier. Picking the right level is free.\n\nA working example that shows the rules in action, in one file. A cross-package split follows:\n\n\n```java\npublic class AccessDemo {\n public String openField = \"anyone can read this\";\n protected String subclassField = \"subclasses or same package\";\n String packageField = \"same package only\";\n private String secretField = \"only this class\";\n\n public void printAll() {\n System.out.println(openField);\n System.out.println(subclassField);\n System.out.println(packageField);\n System.out.println(secretField);\n }\n\n public static void main(String[] args) {\n AccessDemo demo = new AccessDemo();\n demo.printAll();\n }\n}\n```\n\n\nInside the class, every field is reachable. The `printAll` method touches all four without issue because it lives in `AccessDemo` itself. The interesting question is what happens when a different class tries the same reads, and that depends on where that other class lives.\n\n---\n\n# `public`: The Wide-Open Door\n\n`public` makes a member visible to every class in the program, in every package, related or not. Once a member is marked `public`, callers anywhere can read it, write it, or call it. That is the contract.\n\n\n```java\npublic class Customer {\n public String name;\n public String email;\n\n public Customer(String name, String email) {\n this.name = name;\n this.email = email;\n }\n\n public String formatLine() {\n return name + \" <\" + email + \">\";\n }\n}\n\npublic class Checkout {\n public static void main(String[] args) {\n Customer alice = new Customer(\"Alice\", \"alice@example.com\");\n System.out.println(alice.formatLine());\n\n alice.email = \"alice@new.com\";\n System.out.println(alice.formatLine());\n }\n}\n```\n\n\nReading and writing both compile from a completely unrelated class. The `email` field is `public`, so `Checkout` can reassign it without going through any method. The constructor is `public`, so `Checkout` can call `new Customer(...)`. The `formatLine` method is `public`, so `Checkout` can call it.\n\nThis is the appeal and the danger of `public`. The appeal: callers can use the class. The danger: every public member is a forever commitment. Once a field or method is part of the public API, removing it or changing its type breaks callers that the author cannot see. Public fields are worse than public methods because they advertise the internal storage layout, not just the behavior. Switching from a `String email` to two fields `String local` and `String domain` breaks every caller that wrote `alice.email = ...`.\n\nThe class itself can also be `public`. A `public` top-level class lives in a file named after the class (`Customer.java` for `public class Customer`) and is visible everywhere. A non-public top-level class is package-private and only usable within its package.\n\nA special rule about constructors. A `public` constructor lets any class call `new` on this one. If every constructor on a class is non-public, code outside that visibility scope cannot create instances at all, even though the class type might be visible. This is one of the building blocks for singleton classes and factory methods.\n\n\n```java\npublic class GiftCard {\n public double balance;\n\n public GiftCard(double balance) {\n this.balance = balance;\n }\n}\n```\n\n\n`public class` plus `public` constructor plus `public` field. Three different `public` keywords, three different scopes. The class is visible everywhere. The constructor is callable everywhere. The field is readable and writable everywhere. Each one is a separate decision.\n\n---\n\n# `private`: The Locked Room\n\n`private` is the strictest level. A `private` member is visible only inside the class that declares it. Not its subclasses. Not its package. Just the class itself.\n\n\n```java\npublic class Customer {\n private String name;\n private String email;\n\n public Customer(String name, String email) {\n this.name = name;\n this.email = email;\n }\n\n public String getName() {\n return name;\n }\n\n public String getEmail() {\n return email;\n }\n\n public void setEmail(String email) {\n this.email = email;\n }\n}\n\npublic class Checkout {\n public static void main(String[] args) {\n Customer alice = new Customer(\"Alice\", \"alice@example.com\");\n\n System.out.println(alice.getName() + \" <\" + alice.getEmail() + \">\");\n\n alice.setEmail(\"alice@new.com\");\n System.out.println(alice.getName() + \" <\" + alice.getEmail() + \">\");\n }\n}\n```\n\n\n`Checkout` cannot touch `name` or `email` directly anymore. The compiler rejects `alice.email = \"...\";` outright:\n\n\n```java\nalice.email = \"alice@new.com\"; // won't compile\n```\n\n\n\n```shell\nCheckout.java: error: email has private access in Customer\n alice.email = \"alice@new.com\";\n ^\n```\n\n\nThe fix is the setter. Callers go through `setEmail`, which lives inside `Customer` and is therefore allowed to touch `email`. That sounds like ceremony for the same outcome, but it is not. The class now controls what assignment to `email` actually does.\n\n`private` is where the **minimal API surface** rule applies. The default choice for any new field should be `private`. If no caller from outside needs to read it, nobody does. Widening from `private` to something else later is a non-breaking change: every existing call site keeps working, because everyone with access already had access. Tightening from `public` to `private` is a breaking change: every caller that touched the field stops compiling. Start tight, widen on demand.\n\nA `private` constructor is also a useful tool. It prevents code outside the class from calling `new`:\n\n\n```java\npublic class Inventory {\n public int totalItems;\n\n private Inventory(int totalItems) {\n this.totalItems = totalItems;\n }\n\n public static Inventory empty() {\n return new Inventory(0);\n }\n\n public static Inventory withStock(int initial) {\n if (initial < 0) {\n throw new IllegalArgumentException(\"Stock can't be negative: \" + initial);\n }\n return new Inventory(initial);\n }\n}\n\npublic class InventoryDemo {\n public static void main(String[] args) {\n Inventory store = Inventory.withStock(50);\n System.out.println(\"Stock: \" + store.totalItems);\n }\n}\n```\n\n\nCallers cannot write `new Inventory(50)` from outside the class. They have to go through `withStock`, which validates the argument first. The constructor is still there, doing the actual initialization, but it is gatekept behind code that runs the checks.\n\nA `private` field accessed through a getter is just as fast as a public field at runtime. The JVM inlines simple getters, so the indirection vanishes in practice. Picking `private` costs nothing.\n\n---\n\n# Package-Private: The Modifier With No Keyword\n\nJava does not give this level a keyword. A field with no access modifier is package-private:\n\n\n```java\npublic class Cart {\n int itemCount; // package-private (default)\n double total; // package-private (default)\n}\n```\n\n\n`itemCount` and `total` are visible to any class in the same package as `Cart`. They are invisible to classes in any other package. There is no `package` keyword in front of them. The absence of `public`, `protected`, or `private` is what makes them package-private.\n\n\"No modifier\" looks identical to \"I forgot to write one.\" A field written without an access level is not `public`; it is package-private, which is one of the tightest levels. Code in another package that tries to touch the field gets a compile error that looks like a \"missing import\" issue.\n\nA concrete example. Two packages, two classes:\n\n\n```java\n// File: com/example/orders/Cart.java\npackage com.example.orders;\n\npublic class Cart {\n public String customerName;\n int itemCount; // package-private\n private double total;\n}\n```\n\n\n\n```java\n// File: com/example/orders/CartPrinter.java\npackage com.example.orders;\n\npublic class CartPrinter {\n public static void print(Cart cart) {\n System.out.println(cart.customerName + \" has \" + cart.itemCount + \" items\");\n }\n}\n```\n\n\n\n```java\n// File: com/example/web/CartHandler.java\npackage com.example.web;\n\nimport com.example.orders.Cart;\n\npublic class CartHandler {\n public static void handle(Cart cart) {\n System.out.println(cart.customerName);\n System.out.println(cart.itemCount); // won't compile\n }\n}\n```\n\n\n`CartPrinter` lives in `com.example.orders`, same package as `Cart`. It can read `itemCount` without issue. `CartHandler` lives in `com.example.web`, a different package. The line that touches `itemCount` from `CartHandler` fails:\n\n\n```shell\nCartHandler.java: error: itemCount is not public in Cart; cannot be accessed from outside package\n System.out.println(cart.itemCount);\n ^\n```\n\n\nNote the error message: \"is not public in Cart\". The compiler does not say \"is package-private\" because there is no keyword to name. It just says the field is not accessible from outside the package.\n\nWhen does package-private fit? Two situations come up:\n\n- **Helper classes within a package.** A package can have several classes that cooperate. The top-level entry point is `public`. The internals are package-private, so the package can use them but outside callers cannot see them at all. This is how a lot of the standard library is organized.\n- **Test-only access.** A common practice is to put unit tests in the same package as the class under test, so the tests can read fields and call methods that are not `public`. The fields stay hidden from the rest of the application but are reachable from tests.\n\nIf neither situation applies, picking package-private over `private` is rarely worth it. Code in a single package treats `private` and package-private the same in small examples. The day code is split across packages, the difference shows up.\n\nOne related rule about classes themselves. A top-level class with no access modifier is also package-private. Only one class per file can be `public`, and that class has to match the filename. Everything else in the file is package-private by default:\n\n\n```java\n// File: Cart.java\npublic class Cart { // public, file name matches\n // ...\n}\n\nclass CartItem { // package-private\n // ...\n}\n```\n\n\n`CartItem` is reachable from code in the same package but invisible elsewhere. Putting helper classes in the same file as the main public class is one way to express \"this is an implementation detail nobody outside should use.\" The compiler enforces it.\n\n---\n\n# `protected`: Subclass Access Across Packages\n\n`protected` is the trickiest of the four because it does two things at once. A `protected` member is visible to:\n\n1. Every class in the same package (just like package-private).\n2. Subclasses of the declaring class, even if those subclasses live in a different package.\n\nThe first part is the boring half. Code that lives in one package treats `protected` and package-private the same. The interesting half is the second part:\n\n\n```java\n// File: com/example/payments/PaymentMethod.java\npackage com.example.payments;\n\npublic abstract class PaymentMethod {\n protected String holderName;\n\n public PaymentMethod(String holderName) {\n this.holderName = holderName;\n }\n}\n```\n\n\n\n```java\n// File: com/example/wallet/GiftCard.java\npackage com.example.wallet;\n\nimport com.example.payments.PaymentMethod;\n\npublic class GiftCard extends PaymentMethod {\n public double balance;\n\n public GiftCard(String holderName, double balance) {\n super(holderName);\n this.balance = balance;\n }\n\n public void printOwner() {\n System.out.println(\"Gift card held by: \" + holderName); // OK\n }\n}\n```\n\n\n`GiftCard` is in `com.example.wallet`. `PaymentMethod` is in `com.example.payments`. Different packages. `holderName` is `protected`. The line inside `printOwner` reads `holderName` directly and compiles, because `GiftCard` is a subclass of `PaymentMethod`. Protected access opened the door across the package boundary, but only for subclasses.\n\nThe same reach does not extend to unrelated classes in the wallet package:\n\n\n```java\n// File: com/example/wallet/Checker.java\npackage com.example.wallet;\n\nimport com.example.payments.PaymentMethod;\n\npublic class Checker {\n public static void main(String[] args) {\n GiftCard card = new GiftCard(\"Alice\", 50);\n System.out.println(card.holderName); // won't compile\n }\n}\n```\n\n\n\n```shell\nChecker.java: error: holderName has protected access in PaymentMethod\n System.out.println(card.holderName);\n ^\n```\n\n\n`Checker` is in the same package as `GiftCard`, but `Checker` is not a subclass of `PaymentMethod`. It cannot reach across the package boundary to a `protected` member declared in `com.example.payments`. Being a subclass is the key that unlocks `protected`, not being a neighbor in the package.\n\nOne more subtlety. A subclass can access `protected` members through its own kind of reference, but not through an arbitrary reference to the parent type:\n\n\n```java\npublic class GiftCard extends PaymentMethod {\n // ...\n\n public static void reach(PaymentMethod other, GiftCard another) {\n System.out.println(another.holderName); // OK: through GiftCard reference\n System.out.println(other.holderName); // won't compile across packages\n }\n}\n```\n\n\nFrom inside `GiftCard`, reading `holderName` through a `GiftCard` reference is allowed. Reading the same field through a `PaymentMethod` reference, when the two classes are in different packages, is not. The reasoning: `protected` is for subclasses to extend the parent's behavior, not for one subclass to access another subclass's state through the parent type.\n\n`protected` vs package-private comes up often, and the difference is exactly this cross-package subclass case:\n\n\n| Scenario | Package-private | `protected` |\n| --- | --- | --- |\n| Same package, unrelated class | Visible | Visible |\n| Same package, subclass | Visible | Visible |\n| Different package, unrelated class | Hidden | Hidden |\n| Different package, subclass | Hidden | Visible |\n\n\nThe two modifiers are identical inside a single package. They diverge the moment a package boundary is crossed with a subclass. Pick `protected` when designing a class to be extended across package boundaries (the abstract base class pattern fits here). Pick package-private when extension is meant to stay inside the package.\n\nA note on modules. Java 9 added a module system that adds another layer on top of packages, where a module decides which packages to export. Even a `public` class in an unexported package is invisible outside the module. For everything in this lesson, assume all packages are visible across module boundaries.\n\n---\n\n# Public Fields Break Encapsulation\n\nWith the four modifiers on the table, the obvious question is \"why not just make everything `public` and skip all this?\" The short answer: public fields give the class no place to put rules. The longer answer has two pieces: invariants and API evolution.\n\nStart with invariants. An invariant is something a class promises is always true about its state. A `Cart` might promise \"the total equals the sum of item prices times quantities.\" An `Order` might promise \"the status is one of `PLACED`, `SHIPPED`, `DELIVERED`, or `CANCELLED`, and it only moves forward.\" A `Product` might promise \"the price is never negative.\"\n\nIf a field is `public`, the class cannot enforce any of those rules. Callers assign to the field directly, and the class has no way to inspect what they wrote.\n\n\n```java\npublic class Order {\n public double total;\n public String status;\n}\n\npublic class BrokenOrder {\n public static void main(String[] args) {\n Order order = new Order();\n order.total = -50.00; // negative total, allowed\n order.status = \"UNICORN_DELIVERY\"; // bogus status, allowed\n System.out.println(order.status + \": $\" + order.total);\n }\n}\n```\n\n\nThe compiler does not object. The runtime does not object. The class never had a chance to say \"that is not a real status.\" The invariants exist only in the design documents.\n\nWrap the fields and the class gets a chance to enforce them:\n\n\n```java\npublic class Order {\n private double total;\n private String status;\n\n public void setTotal(double total) {\n if (total < 0) {\n throw new IllegalArgumentException(\"Total can't be negative: \" + total);\n }\n this.total = total;\n }\n\n public void setStatus(String status) {\n if (!status.equals(\"PLACED\") && !status.equals(\"SHIPPED\")\n && !status.equals(\"DELIVERED\") && !status.equals(\"CANCELLED\")) {\n throw new IllegalArgumentException(\"Unknown status: \" + status);\n }\n this.status = status;\n }\n\n public double getTotal() { return total; }\n public String getStatus() { return status; }\n}\n```\n\n\nThe same bad assignments now throw. The class catches them before the bad state ever lands in the object. The invariants stop being aspirational and start being enforced.\n\nThe second problem with public fields is API evolution. A public field commits the class to that exact storage layout for the lifetime of the API. Consider this:\n\n\n```java\npublic class Customer {\n public String fullName;\n}\n```\n\n\nCallers across the codebase write `customer.fullName = \"Alice Smith\"` and read `customer.fullName`. A later change to split the name into `firstName` and `lastName` is impossible with a public field. Every existing caller would break. With a `private` field and a getter/setter pair, there is room:\n\n\n```java\npublic class Customer {\n private String firstName;\n private String lastName;\n\n public String getFullName() {\n return firstName + \" \" + lastName;\n }\n\n public void setFullName(String fullName) {\n int space = fullName.indexOf(' ');\n this.firstName = fullName.substring(0, space);\n this.lastName = fullName.substring(space + 1);\n }\n}\n```\n\n\nThe internal storage changed. The external API did not. Existing callers keep working. New callers can use richer methods when added. This kind of refactor is invisible from the outside, which is the whole point of hiding the field.\n\nPublic fields are not always wrong. Constants (`public static final`) are routinely public, because they do not represent mutable state. Records expose their components publicly through accessor methods that happen to look like fields. But for ordinary mutable state on a class, `public` fields trade away every chance to enforce rules or evolve the implementation. The cost shows up later, in code that is hard to change.\n\n---\n\n# Validating Setters\n\nHiding a field behind a setter only matters if the setter does something useful. The \"useful\" part is almost always validation: check the new value before assigning it. If the value would violate an invariant, refuse it by throwing an exception.\n\nThe standard exception for \"you passed me a bad argument\" is `IllegalArgumentException`. It is an unchecked exception, so it does not have to be declared in the method signature.\n\n\n```java\npublic class Product {\n private String name;\n private double price;\n private int stockCount;\n\n public Product(String name, double price, int stockCount) {\n setName(name);\n setPrice(price);\n setStockCount(stockCount);\n }\n\n public void setName(String name) {\n if (name == null || name.isBlank()) {\n throw new IllegalArgumentException(\"Name can't be blank\");\n }\n this.name = name;\n }\n\n public void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"Price can't be negative: \" + price);\n }\n this.price = price;\n }\n\n public void setStockCount(int stockCount) {\n if (stockCount < 0) {\n throw new IllegalArgumentException(\"Stock can't be negative: \" + stockCount);\n }\n this.stockCount = stockCount;\n }\n\n public String getName() { return name; }\n public double getPrice() { return price; }\n public int getStockCount() { return stockCount; }\n}\n\npublic class ProductDemo {\n public static void main(String[] args) {\n Product book = new Product(\"Effective Java\", 45.99, 7);\n System.out.println(book.getName() + \": $\" + book.getPrice() + \" (\" + book.getStockCount() + \" in stock)\");\n\n try {\n book.setPrice(-10);\n } catch (IllegalArgumentException e) {\n System.out.println(\"Rejected: \" + e.getMessage());\n }\n\n System.out.println(\"Price after rejected change: $\" + book.getPrice());\n }\n}\n```\n\n\nThree details. First, the constructor delegates to the setters. That way the validation rules live in one place. Changing \"price cannot be negative\" to \"price cannot be more than $1,000,000\" means changing one method, not two. Second, when a setter throws, the field does not change. The throw happens before the assignment, so the object is left in its previous valid state. Third, the exception message includes the offending value (`-10.0`), which makes debugging easier than a generic \"bad argument.\"\n\nThe pattern shows up in constructors too, and it should. A constructor that takes parameters is the first place a new object can be corrupted, so the same checks belong there:\n\n\n```java\npublic Product(String name, double price, int stockCount) {\n setName(name);\n setPrice(price);\n setStockCount(stockCount);\n}\n```\n\n\nCalling the setters from inside the constructor guarantees that an object can never exist in an invalid state. The instant `new Product(...)` returns, every invariant holds. There is no \"uninitialized for a moment\" window where another piece of code could read a half-built object with garbage fields.\n\nCalling setters from a constructor has a caveat for inheritance. A subclass's overridden setter can run before the subclass's own fields are initialized, which leads to bugs. The standard workaround in libraries that care about this: declare the setters `final` so they cannot be overridden, or call private validation helpers from both the constructor and the setters. For introductory code, calling setters from the constructor is fine; for classes designed for inheritance, prefer private helpers.\n\nWhat kind of validation makes sense? A few patterns recur:\n\n- **Range checks** for numeric fields: prices are non-negative, quantities are non-negative, percentages are between 0 and 100.\n- **Null checks** for fields that do not allow null: names, emails, identifiers. Use `Objects.requireNonNull` from `java.util` for this:\n\n\n```java\npublic void setName(String name) {\n this.name = Objects.requireNonNull(name, \"name must not be null\");\n}\n```\n\n\n- **Format checks** for string fields with structure: emails contain `@`, postal codes match a pattern.\n- **Enum membership** for fields that take a small set of values: order status is one of a fixed list (which is also a hint that an `enum` might be a better fit than a `String`).\n\nThe rule of thumb: \"if a value would put the object into a state that no other method should have to handle, reject it now.\" Catching the bad value at the setter keeps every downstream method simpler.\n\n---\n\n# Defensive Copies for Mutable Fields\n\nValidation is half the story. The other half is what happens when a field holds a reference to a mutable object: a `Date`, an `ArrayList`, an array, anything that has state of its own that callers can change.\n\nConsider an `Order` that holds a list of items. The setter takes a `List` and stores it.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class Order {\n private List items;\n\n public Order(List items) {\n this.items = items;\n }\n\n public List getItems() {\n return items;\n }\n}\n\npublic class BrokenDemo {\n public static void main(String[] args) {\n List input = new ArrayList<>();\n input.add(\"Effective Java\");\n input.add(\"Cotton T-Shirt\");\n\n Order order = new Order(input);\n System.out.println(\"Order items: \" + order.getItems());\n\n input.add(\"MALICIOUS_ITEM\");\n System.out.println(\"Order items: \" + order.getItems());\n }\n}\n```\n\n\nThe output is:\n\n\n```shell\nOrder items: [Effective Java, Cotton T-Shirt]\nOrder items: [Effective Java, Cotton T-Shirt, MALICIOUS_ITEM]\n```\n\n\nThe `Order` \"owns\" the items list. Nothing in `Order` itself touched the list after the constructor ran. But the caller still holds a reference to the same list, and mutations through that reference are visible through `getItems()`. The encapsulation is a fiction. Marking the field `private` did not help, because the field is a reference, and the actual object lives on the heap where both `Order` and the caller can see it.\n\nThe same trap exists on the other side. `getItems()` hands back the live internal list. A caller can call `order.getItems().add(\"...\")` and mutate the order's items without ever calling a setter.\n\n\n```java\norder.getItems().add(\"YET ANOTHER ITEM\");\nSystem.out.println(order.getItems());\n```\n\n\nThe fix is a **defensive copy**: copy the list on the way in and on the way out. The order keeps its own internal copy that callers can't reach.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class Order {\n private List items;\n\n public Order(List items) {\n this.items = new ArrayList<>(items); // copy in\n }\n\n public List getItems() {\n return new ArrayList<>(items); // copy out\n }\n}\n\npublic class FixedDemo {\n public static void main(String[] args) {\n List input = new ArrayList<>();\n input.add(\"Effective Java\");\n input.add(\"Cotton T-Shirt\");\n\n Order order = new Order(input);\n System.out.println(\"Order items: \" + order.getItems());\n\n input.add(\"MALICIOUS_ITEM\");\n System.out.println(\"After caller mutation: \" + order.getItems());\n\n order.getItems().add(\"STILL_BLOCKED\");\n System.out.println(\"After getter mutation: \" + order.getItems());\n }\n}\n```\n\n\nBoth attacks bounce off. The caller can mutate the input list, because `Order` no longer points at it. The caller can mutate the result of `getItems()`, because that is a fresh list too. The actual internal list stays untouchable.\n\nArrays have the same problem and the same solution. Taking an `int[]` in a setter, storing it directly, and handing the same array back from a getter lets the caller rewrite individual cells at any time. The fix is `Arrays.copyOf` or `clone()` on the array:\n\n\n```java\nimport java.util.Arrays;\n\npublic class Cart {\n private int[] quantities;\n\n public Cart(int[] quantities) {\n this.quantities = Arrays.copyOf(quantities, quantities.length);\n }\n\n public int[] getQuantities() {\n return Arrays.copyOf(quantities, quantities.length);\n }\n}\n```\n\n\nSame pattern, different copying method. The principle is the same: never store a reference handed in by an outsider, never hand back a reference to internal state.\n\nThe classic mutable-class trap in pre-Java-8 code is `java.util.Date`. A `Date` is mutable, so storing one a caller passed in opens the same hole. The fix: copy on the way in and out, using `new Date(other.getTime())`. Modern Java code avoids `Date` in favor of the `java.time` types (`LocalDate`, `Instant`, and others), which are immutable and do not need defensive copies. A field of an immutable type is safe to hand around directly, because nobody can mutate it. Defensive copies are the workaround for mutable field types; immutable types are the deeper fix.\n\nA defensive copy of a list or array is O(n) every time the field is accepted or returned. For small collections, the cost is negligible. For large ones, repeated copies add up, which is one reason library types like `List.copyOf` (which returns a shallow unmodifiable view) and immutable classes are popular alternatives. The defensive copy approach is correct and clear; the unmodifiable view approach is correct and cheaper. Both are better than handing out the raw reference.\n\n---\n\n# Minimal API Surface: Default to Private, Widen on Demand\n\nPulling everything together, the practical rule for picking access modifiers: start as narrow as possible and widen one step at a time only when there is a real reason. The reasoning:\n\n1. Every public member is a permanent commitment. Removing or renaming it breaks every caller.\n2. Every public member is something the class can no longer change internally without affecting external behavior.\n3. It is not possible to know in advance which members future callers will misuse. The safer answer is to expose nothing they do not need.\n\nThe decision tree looks like this:\n\n\n```mermaid\nflowchart TD\n Start[\"Adding a new field
or method\"]:::cyan\n Q1{\"Does any class
outside this one
need it?\"}:::yellow\n PrivateRes[\"Use private\"]:::green\n Q2{\"Does any class
outside this package
need it?\"}:::yellow\n PkgRes[\"Use package-private\"]:::green\n Q3{\"Does any subclass
in another package
need it?\"}:::yellow\n ProtRes[\"Use protected\"]:::orange\n PubRes[\"Use public
(commit to it)\"]:::red\n\n Start --> Q1\n Q1 -->|No| PrivateRes\n Q1 -->|Yes| Q2\n Q2 -->|No| PkgRes\n Q2 -->|Yes| Q3\n Q3 -->|Yes, only subclasses| ProtRes\n Q3 -->|Yes, anyone| PubRes\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram walks the same logic in flowchart form. Each \"no\" lands at the tightest level that still works. Each \"yes\" widens by exactly one step.\n\nTwo consequences:\n\n- **Widening is non-breaking.** Going from `private` to package-private, or package-private to `public`, never breaks existing callers. Everyone with access before still has access. Picking the tightest level first costs nothing when more access is needed later.\n- **Tightening is breaking.** Going the other direction, from `public` to anything tighter, removes access from callers that may have relied on it. Picking a loose level \"to be safe\" locks the class in.\n\nThe minimal API surface rule pairs with everything else in this lesson. Validating setters work because the field is `private` and the setter is the only door in. Defensive copies work because the internal collection is `private` and the caller can never reach the real reference. Public fields would undo both. The four modifiers are not four arbitrary categories; they are a sliding scale from \"fully encapsulated\" to \"completely exposed,\" and most of the value lives near the tight end.\n\nThe same rule extends to classes themselves. A class only used inside its package can be package-private. A class only used by one other class can be a nested private class. A class only used as an implementation helper inside a method can be a local class. The design principle is the same: keep the visible surface small.\n\n---\n\n# A Larger Worked Example\n\nA `Customer` class that pulls together everything in this lesson: tight access modifiers, validation in setters and constructor, and a defensive copy for a mutable address-history field.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\nimport java.util.Objects;\n\npublic class Customer {\n private String name;\n private String email;\n private List previousAddresses;\n\n public Customer(String name, String email, List previousAddresses) {\n setName(name);\n setEmail(email);\n this.previousAddresses = new ArrayList<>(previousAddresses);\n }\n\n public String getName() { return name; }\n public String getEmail() { return email; }\n\n public List getPreviousAddresses() {\n return new ArrayList<>(previousAddresses);\n }\n\n public void setName(String name) {\n Objects.requireNonNull(name, \"name must not be null\");\n if (name.isBlank()) {\n throw new IllegalArgumentException(\"name must not be blank\");\n }\n this.name = name;\n }\n\n public void setEmail(String email) {\n Objects.requireNonNull(email, \"email must not be null\");\n if (!email.contains(\"@\")) {\n throw new IllegalArgumentException(\"email must contain '@': \" + email);\n }\n this.email = email;\n }\n\n public void addPreviousAddress(String address) {\n Objects.requireNonNull(address, \"address must not be null\");\n previousAddresses.add(address);\n }\n}\n\npublic class CustomerDemo {\n public static void main(String[] args) {\n List oldAddresses = new ArrayList<>();\n oldAddresses.add(\"123 First St\");\n\n Customer alice = new Customer(\"Alice\", \"alice@example.com\", oldAddresses);\n alice.addPreviousAddress(\"456 Second Ave\");\n\n oldAddresses.add(\"999 Hacker Ln\");\n alice.getPreviousAddresses().add(\"888 Also Hacker St\");\n\n System.out.println(\"Name: \" + alice.getName());\n System.out.println(\"Email: \" + alice.getEmail());\n System.out.println(\"Previous addresses: \" + alice.getPreviousAddresses());\n\n try {\n alice.setEmail(\"not-an-email\");\n } catch (IllegalArgumentException e) {\n System.out.println(\"Rejected bad email: \" + e.getMessage());\n }\n\n System.out.println(\"Email after rejected change: \" + alice.getEmail());\n }\n}\n```\n\n\nWalk through what the design does:\n\n1. Every field is `private`. Nothing outside `Customer` can read or write them directly. The minimal surface principle in action.\n2. The constructor calls `setName` and `setEmail` rather than assigning directly. Validation lives in one place per field. Both `name` and `email` are checked for null and for content before any field is touched. If validation fails, the constructor throws and no `Customer` object survives.\n3. `previousAddresses` is initialized with a defensive copy of the caller's list. The caller's later `oldAddresses.add(\"999 Hacker Ln\")` does not affect the customer.\n4. `getPreviousAddresses` returns a defensive copy. The caller's later `alice.getPreviousAddresses().add(\"888 Also Hacker St\")` adds to a throwaway list, not to the customer's actual addresses.\n5. `addPreviousAddress` is the only legitimate way to extend the address list. It validates and then mutates the internal list directly, which is safe because the method is part of the class.\n6. The setter for `email` rejects values that do not contain `@`. The catch in `main` shows what callers see, and the next read of `getEmail` shows that the field was not modified.\n\nEvery piece of the design exists for a reason. Stripping out any one of them re-opens a hole: drop `private` and the validation can be bypassed; drop the defensive copy and outsiders can mutate the list; drop the validation and bad data slips into a \"successfully constructed\" object.\n\n---\n\n# Common Mistakes Around Data Hiding\n\nA short list of mistakes that come up often:\n\n### Adding Getters and Setters for Every Field by Default\n\nA getter and setter pair for every private field has the same effective surface as making the field public. The encapsulation buys nothing if there is no validation in the setter and no transformation in the getter. The principle: start with no accessors and add them as callers need them, not \"expose everything through methods\" out of habit.\n\n### Skipping Validation in the Constructor\n\nIt is easy to write careful setters and then bypass them in the constructor:\n\n\n```java\npublic Product(String name, double price) {\n this.name = name; // no validation\n this.price = price; // no validation\n}\n```\n\n\nA `new Product(null, -10)` slips through and creates an object that no setter would have allowed. Have the constructor call the setters, or have both the constructor and the setters call a private `validate` method.\n\n### Shallow Defensive Copy When Items Are Mutable\n\n`new ArrayList<>(otherList)` copies the list but not the items in it. If the items themselves are mutable, the caller still holds references to the same item objects and can mutate them through those references. Strings are immutable, so `List` is safe with a shallow copy. A `List` is not. For mutable items, copy each item too, or design the items themselves to be immutable.\n\n### Using `protected` as a Loose `public`\n\n`protected` is sometimes treated as \"a bit more open than package-private, a bit less than public.\" That is not quite the right model. `protected` specifically widens the door to subclasses, which is a design commitment: every member exposed this way is part of the contract that subclasses can rely on. Tightening a `protected` member later breaks external subclasses. Use `protected` when extension is the intended use, not as a generic \"in-between\" level.\n\n### Returning the Internal Map or Set\n\nThe list example generalizes to every mutable collection. Returning the internal `Map` or `Set` directly from a getter has the same problem as returning the internal `List`. Either return a defensive copy or return an unmodifiable view (`Collections.unmodifiableMap(internalMap)` or `Map.copyOf(internalMap)`). The view does not pay the copy cost but throws if the caller tries to mutate.","pageType":"java"}

Data Hiding

Get Premium