{"title":"Access Modifiers","description":"","content":"A class usually has parts you want other code to use and parts you'd rather keep to yourself. The price of a `Product` should be safe from random callers overwriting it, but other code still needs to read it through some controlled path. Access modifiers are the keywords Java gives you to draw that line. This lesson covers the four access levels (`public`, `protected`, package-private, `private`), the rules each one enforces, and how to pick the right one for fields, methods, and nested types.\n\n---\n\n# The Four Access Levels\n\nJava has four levels of member access, ordered from most open to most closed:\n\n\n| Modifier | Keyword | Idea |\n| ---------------- | ------------- | ------------------------------------------------ |\n| Public | `public` | Anyone, anywhere |\n| Protected | `protected` | Same package, plus subclasses in other packages |\n| Package-private | (no keyword) | Same package only |\n| Private | `private` | Same class only |\n\n\nThe level applies to whatever it sits in front of: a field, a method, a constructor, or a nested type. Three of them are spelled out as keywords. The fourth, package-private, is the absence of any modifier. Leaving the keyword off doesn't mean \"default to public\", it means \"package-private\".\n\nHere's the same class with one field at each access level so you can see the syntax side by side.\n\n\n```java\npublic class Product {\n public String name; // anyone can read or write\n protected double price; // same package or subclass elsewhere\n int stockCount; // package-private (no keyword)\n private String internalId; // only this class\n\n public static void main(String[] args) {\n Product item = new Product();\n item.name = \"Wireless Mouse\";\n item.price = 29.99;\n item.stockCount = 50;\n item.internalId = \"SKU-9012\";\n System.out.println(item.name + \" has \" + item.stockCount + \" in stock.\");\n }\n}\n```\n\n\nInside the same class, all four fields are reachable, so the program runs as expected. The differences only show up when code outside the class tries to touch these fields.\n\n---\n\n# The Visibility Matrix\n\nThe whole story can be captured in one table. Read it as: \"If the member is declared with modifier X, can code in location Y access it?\"\n\n\n| Modifier | Same class | Same package | Subclass (different package) | Anywhere |\n| --------------- | :--------: | :----------: | :--------------------------: | :------: |\n| `public` | yes | yes | yes | yes |\n| `protected` | yes | yes | yes | no |\n| (no modifier) | yes | yes | no | no |\n| `private` | yes | no | no | no |\n\n\nOne way to picture this is as four nested rings of trust. Code inside the innermost ring can see everything; each ring outward loses one more level.\n\n\n```mermaid\nflowchart LR\n A[private
same class only]:::cyan --> B[package-private
same package]:::orange\n B --> C[protected
package + subclass elsewhere]:::teal\n C --> D[public
anywhere]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nEach level is a superset of the one to its left. Whatever `private` allows, package-private also allows. Whatever package-private allows, `protected` also allows. And `public` allows everything the others allow plus the outside world.\n\n---\n\n# `public`: Open to Everyone\n\nA `public` member can be accessed from any code in any package. No restrictions, no inheritance checks, no questions asked.\n\n\n```java\n// in package shop.catalog\npublic class Product {\n public String name;\n\n public Product(String name) {\n this.name = name;\n }\n\n public String describe() {\n return \"Product: \" + name;\n }\n}\n```\n\n\n\n```java\n// in package shop.cart\nimport shop.catalog.Product;\n\npublic class CartDemo {\n public static void main(String[] args) {\n Product item = new Product(\"USB Cable\");\n System.out.println(item.name); // works: name is public\n System.out.println(item.describe()); // works: describe is public\n }\n}\n```\n\n\nUse `public` for things that form your class's contract with the outside world: factory methods, the methods callers are meant to use, constants other code is supposed to read. The cost of `public` is that you're committing to that contract. Once outside code is calling `item.name` directly, you can't rename the field or change its type without breaking every caller.\n\nThis is why Java code uses `public` sparingly on fields. Methods, yes, often. Fields, almost never. Methods give you a chance to change the implementation behind them. Fields don't.\n\n---\n\n# `protected`: Package Plus Subclasses\n\n`protected` widens visibility past the package boundary but only for subclasses. Code in the same package can use a `protected` member directly. Code in a different package can use it only if it's inside a class that inherits from the declaring class.\n\n\n```java\n// in package shop.catalog\npublic class Product {\n protected double price;\n\n public Product(double price) {\n this.price = price;\n }\n}\n```\n\n\n\n```java\n// in package shop.cart\nimport shop.catalog.Product;\n\npublic class DiscountedProduct extends Product {\n public DiscountedProduct(double price) {\n super(price);\n }\n\n public double halfPrice() {\n return price / 2; // works: subclass can see protected price\n }\n}\n\npublic class CartOutside {\n public static void main(String[] args) {\n Product item = new Product(29.99);\n // System.out.println(item.price); // compile error: not a subclass\n }\n}\n```\n\n\nThe subclass `DiscountedProduct` reaches `price` because it inherits from `Product`. `CartOutside`, which is in the same package as `DiscountedProduct` but doesn't extend `Product`, cannot.\n\nUse `protected` when you're designing for inheritance and want to expose some internal state to subclasses without making it public. It's narrower than it sounds, though.\n\n\n> **INFO**\n>\n> **Common confusion:** `protected` does not mean \"only subclasses\". It means \"same package plus subclasses elsewhere\". A class in the same package can access a `protected` member even without inheriting.\n\n\n---\n\n# Package-Private: The Default\n\nIf you leave the modifier off, the member is **package-private**. Only code in the same package can use it. Subclasses in a different package cannot, even if everything else about them looks similar.\n\n\n```java\n// in package shop.catalog\nclass Inventory {\n int stockCount; // package-private field\n String warehouseCode; // package-private field\n\n int totalUnits() { // package-private method\n return stockCount;\n }\n}\n\npublic class CatalogService {\n public static void main(String[] args) {\n Inventory inv = new Inventory();\n inv.stockCount = 100; // works: same package\n inv.warehouseCode = \"WH-EAST\"; // works: same package\n System.out.println(inv.totalUnits());\n }\n}\n```\n\n\nTry the same field access from a different package and you get a compile error:\n\n\n```java\n// in package shop.cart\nimport shop.catalog.Inventory; // also fails: Inventory itself isn't public\n\npublic class StockReader {\n public static void main(String[] args) {\n Inventory inv = new Inventory();\n // inv.stockCount = 100; // compile error: stockCount is not visible\n }\n}\n```\n\n\nPackage-private is the natural fit for classes and members that are implementation details shared across a few files in the same package but not meant for outside callers. A common pattern: one or two `public` classes per package form the entry point, and several package-private helper classes back them up.\n\nPackage-private is sometimes called \"default access\" in older books. Java's official terminology is \"package-private\".\n\n---\n\n# `private`: Same Class Only\n\n`private` is the strictest level. A `private` member is visible only inside the class that declares it. Not to subclasses, not to other classes in the same package, not to anyone else.\n\n\n```java\npublic class Customer {\n private String email;\n private int loyaltyPoints;\n\n public Customer(String email, int loyaltyPoints) {\n this.email = email;\n this.loyaltyPoints = loyaltyPoints;\n }\n\n public String describe() {\n return \"Customer with \" + loyaltyPoints + \" points\";\n }\n\n public static void main(String[] args) {\n Customer c = new Customer(\"alice@example.com\", 250);\n System.out.println(c.describe());\n System.out.println(c.email); // works: same class\n }\n}\n```\n\n\nInside `Customer`, the `main` method can touch both fields freely because it's part of the same class. The moment another class tries the same thing, the compiler stops it.\n\n**What's wrong with this code?**\n\n\n```java\npublic class CustomerReport {\n public static void main(String[] args) {\n Customer c = new Customer(\"alice@example.com\", 250);\n System.out.println(c.email); // error\n }\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: email has private access in Customer\n System.out.println(c.email);\n ^\n```\n\n\n**Fix:** Add a public method on `Customer` that exposes the email, or use the existing `describe` method.\n\n\n```java\npublic class Customer {\n private String email;\n\n public Customer(String email) {\n this.email = email;\n }\n\n public String getEmail() {\n return email;\n }\n}\n\npublic class CustomerReport {\n public static void main(String[] args) {\n Customer c = new Customer(\"alice@example.com\");\n System.out.println(c.getEmail()); // works through the public method\n }\n}\n```\n\n\nThe field stays `private`, but a controlled door to it now exists. Callers go through `getEmail` instead of touching the field directly. If you later change the field's name, format, or type, you only update `getEmail`. Every caller stays the same.\n\n\n> **INFO**\n>\n> **Why default to `private`?** When a field is `private`, you can change its name, change its type, replace it with a computed value, or split it across two fields, without breaking a single line of code outside the class. When a field is public, every one of those changes is a public API break. The smaller you keep the surface area, the cheaper your future changes get.\n\n\n---\n\n# Access Modifiers on Top-Level Classes\n\nThe four access modifiers don't all apply to top-level classes (classes declared directly in a file, not nested inside another class). Only two are allowed there:\n\n- `public` means the class is visible from any package.\n- No modifier means the class is package-private: visible only inside its own package.\n\n`private` and `protected` are **not** valid on top-level classes. If you write them, the compiler rejects the file.\n\n**What's wrong with this code?**\n\n\n```java\nprivate class HiddenProduct { // not allowed\n String name;\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: modifier private not allowed here\nprivate class HiddenProduct {\n ^\n```\n\n\n**Fix:** Drop the `private` keyword (making the class package-private) or change it to `public` if outside code needs to see it.\n\n\n```java\nclass HiddenProduct { // package-private, OK\n String name;\n}\n\npublic class CatalogEntry { // public, OK\n String name;\n}\n```\n\n\nThe reasoning is straightforward: `private` on a top-level class would mean \"visible only inside its own class\", which doesn't make sense because the class is the unit of visibility. `protected` on a top-level class would mean \"visible to subclasses in other packages\", but there's no enclosing class to define what counts as a subclass. Both keywords only have meaning on members and on nested types, which we'll touch on in a moment.\n\nA single Java file can hold one `public` top-level class, plus any number of package-private top-level classes. The `public` class, if there is one, has to match the file name. Most files declare exactly one class, and that's `public`.\n\n\n```java\n// File: Product.java in package shop.catalog\npublic class Product {\n String name;\n}\n\nclass InventoryAudit { // package-private helper, fine in the same file\n int auditCount;\n}\n```\n\n\n`Product` is the public face of the file. `InventoryAudit` is a helper that only code in `shop.catalog` can reach.\n\n---\n\n# Access Modifiers on Methods\n\nMethods follow the same four-level rule as fields, and the choice for each method is a design decision. A useful starting position:\n\n- Methods that form the operations callers are supposed to use: `public`.\n- Methods that only other classes in the same package should use: package-private.\n- Methods that subclasses (possibly in other packages) need to override or call: `protected`.\n- Helper methods that nobody outside the class should ever call: `private`.\n\nHere's a class that uses three of the four on its methods.\n\n\n```java\npublic class OrderService {\n public void placeOrder(String productName, int quantity) {\n if (!isInStock(productName, quantity)) {\n System.out.println(\"Out of stock\");\n return;\n }\n recordOrder(productName, quantity);\n notifyWarehouse(productName, quantity);\n }\n\n private boolean isInStock(String productName, int quantity) {\n // pretend we checked a real store\n return quantity <= 10;\n }\n\n void recordOrder(String productName, int quantity) {\n // package-private: visible to other classes in the same package\n System.out.println(\"Recorded order: \" + quantity + \" x \" + productName);\n }\n\n protected void notifyWarehouse(String productName, int quantity) {\n // protected: subclasses can override or call this\n System.out.println(\"Notify warehouse: \" + quantity + \" x \" + productName);\n }\n\n public static void main(String[] args) {\n OrderService svc = new OrderService();\n svc.placeOrder(\"Wireless Mouse\", 3);\n }\n}\n```\n\n\n`placeOrder` is the public entry point. Callers use it. They don't need to know `isInStock` exists, and they have no business calling it directly, so it's `private`. `recordOrder` is the kind of helper that another class in the same package might want to call for testing or reporting, so it's package-private. `notifyWarehouse` is an extension point: a subclass might override it to send a real message instead of printing, so it's `protected`.\n\nThis is the everyday shape of access in a Java class. Start with everything as restrictive as possible. Open it up only when you have an actual caller who needs it.\n\n---\n\n# Access Modifiers on Nested Types\n\nNested types (classes, interfaces, enums declared inside another class) can use all four modifiers, because unlike top-level types, they sit inside a class that defines what each level means. Here's a quick taste:\n\n\n```java\npublic class Order {\n public enum Status { // public nested enum\n PLACED, SHIPPED, DELIVERED, CANCELLED\n }\n\n private static class LineItem { // private nested class\n String productName;\n int quantity;\n }\n\n public Status status;\n private LineItem firstItem;\n}\n```\n\n\n`Status` is `public` because callers outside `Order` need to refer to `Order.Status.PLACED`. `LineItem` is `private` because it's an internal helper that callers should never touch directly. They access whatever needs accessing through methods on `Order`.\n\nThe point for now: don't be surprised when you see `private class` inside another class, even though `private class HiddenProduct` at the top level was an error. The rules change for nested types because they have an enclosing class.\n\n---\n\n# Why Restrict Access at All?\n\nThe four levels aren't there to make life harder. They exist so the class can change without dragging every caller along with it.\n\nThink about a `Product` with a `public double price` field. As long as `price` is public, every place in the codebase can write `item.price = 49.99` or read `item.price` directly. The day you decide prices should be stored in cents instead of dollars (to avoid floating-point rounding errors), or that prices should be currency-aware, every one of those reads and writes breaks. You're rewriting parts of the codebase you didn't know existed.\n\nNow suppose `price` had been `private double priceInCents` from the start, with a `public double getPriceInDollars()` method. Callers use the method. The internal storage is yours. You can switch from a `double` to a `BigDecimal`, you can add currency conversion, you can fetch the price from a database, all without touching a single caller. The method's signature is the contract; the field is none of their business.\n\n\n```mermaid\nflowchart LR\n Caller[Caller code]:::cyan --> API[public method:
getPriceInDollars]:::green\n API --> Field[private field:
priceInCents]:::orange\n Caller -.->|blocked| Field\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe flow on the solid arrows is what's allowed. The dotted arrow is what `private` blocks. Callers can only get to the field through the public method, which is the only path you have to maintain.\n\nThere's also a correctness angle. If a `Product`'s `price` must never be negative, a `public` field gives any caller the power to write `item.price = -10` and silently break invariants the class was supposed to guarantee. A `private` field with a setter that checks the value keeps the rule in one place.\n\nThe principle has a name, encapsulation, and it shows up across virtually every Java codebase you'll work in. For now, the practical rule is enough: **default to `private` for fields**, and expose behavior through methods.\n\n---\n\n# A Realistic Example\n\nTo pull the pieces together, here's a `ShoppingCart` class that uses three of the four access levels deliberately.\n\n\n```java\npublic class ShoppingCart {\n private double subtotal; // internal state, hidden\n private int itemCount; // internal state, hidden\n protected String currencyCode; // subclasses may want to read this\n\n public ShoppingCart(String currencyCode) {\n this.currencyCode = currencyCode;\n this.subtotal = 0.0;\n this.itemCount = 0;\n }\n\n public void addItem(double price, int quantity) {\n if (price < 0 || quantity < 1) {\n return; // ignore invalid input\n }\n subtotal += price * quantity;\n itemCount += quantity;\n }\n\n public double getSubtotal() {\n return subtotal;\n }\n\n public int getItemCount() {\n return itemCount;\n }\n\n void debugDump() {\n // package-private: useful for testing, not for outside callers\n System.out.println(\"DEBUG: subtotal=\" + subtotal + \", items=\" + itemCount);\n }\n\n private double computeTaxRate() {\n // helper used only by other methods in this class\n return 0.08;\n }\n\n public double getTotalWithTax() {\n return subtotal + subtotal * computeTaxRate();\n }\n\n public static void main(String[] args) {\n ShoppingCart cart = new ShoppingCart(\"USD\");\n cart.addItem(29.99, 2);\n cart.addItem(9.99, 1);\n System.out.println(\"Items: \" + cart.getItemCount());\n System.out.println(\"Subtotal: $\" + cart.getSubtotal());\n System.out.println(\"Total with tax: $\" + cart.getTotalWithTax());\n }\n}\n```\n\n\nA few things about the choices:\n\n- `subtotal` and `itemCount` are `private`. Callers should never reach in and overwrite them. The class is responsible for keeping them in sync, and it does that through `addItem`.\n- `currencyCode` is `protected`. If a future `InternationalCart` subclass needs to vary tax behavior by currency, it can read the field directly. If `currencyCode` had been `private`, the subclass would need to call a method instead.\n- `addItem`, `getSubtotal`, `getItemCount`, and `getTotalWithTax` are `public`. They're the contract.\n- `debugDump` is package-private. A test class in the same package can call it; callers from outside cannot.\n- `computeTaxRate` is `private`. It's an implementation detail that has no business existing in the public API. If we replaced it tomorrow with a database lookup, the public methods would look exactly the same to callers.\n\nThe class makes a deliberate statement about what it owns and what it lets outside code see. That's what access modifiers are for.\n\n---\n\n# Practical Guidance\n\nA few rules of thumb that hold up in almost every Java codebase:\n\n- **Default to `private` for fields.** Open them up only when you need to. Even within the same class, prefer accessing your own fields by name rather than building habits that depend on access being looser than it has to be.\n- **Default to `private` for helper methods too.** A method that only one other method in the class calls has no business being `public`. The smaller your public surface, the easier the class is to refactor.\n- **Default to `public` for the methods that represent your class's contract.** Constructors that callers are supposed to use, the operations you want to advertise, the constants that other code reads.\n- **Use package-private when a small group of cooperating classes share something the rest of the world shouldn't see.** This is common for test helpers, internal utility classes, and the implementation details of a feature.\n- **Use `protected` only when designing for inheritance.** It says \"subclasses may need this\", which is a stronger promise than `public` because changing a `protected` member can break subclasses you don't even know exist.\n\nThe smallest access level that lets your code work is almost always the right one. If a question comes up later about whether to open something up, you can always loosen it then. Tightening access on a member with hundreds of callers is much harder than starting tight and loosening as needed.\n\n\n```mermaid\nflowchart LR\n Start[New member]:::cyan --> Q1{Caller exists
outside class?}:::orange\n Q1 -->|No| Priv[private]:::green\n Q1 -->|Yes| Q2{Caller in
same package?}:::orange\n Q2 -->|Yes, only| PP[package-private]:::teal\n Q2 -->|No| Q3{Caller is a
subclass elsewhere?}:::orange\n Q3 -->|Yes| Prot[protected]:::teal\n Q3 -->|Anyone| Pub[public]:::green\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 teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nWalking the flow from `New member` outward, you pick the most restrictive level that still covers your callers. Most fields end at `private`. Most helper methods end at `private` or package-private. Most contract methods end at `public`. `protected` is rarer and usually a deliberate choice.\n\n---\n\n# Quiz","pageType":"java"}

Access Modifiers

Get Premium