{"title":"Getters & Setters","description":"","content":"A class can hold data in two ways: expose it directly as public fields, or hide it behind methods that read and write the data on the caller's behalf. Java code typically picks the second approach, and the read and write methods have standard names: `getX` and `setX`. This lesson covers why hiding fields behind methods is the default, how to write getters and setters cleanly, and the cases where one or both should be left out.\n\n---\n\n# Why Methods Instead of Public Fields\n\nA `Product` with everything public looks tempting. It's the shortest code possible.\n\n\n```java\npublic class ProductPublic {\n public String name;\n public double price;\n public int stock;\n\n public static void main(String[] args) {\n ProductPublic mouse = new ProductPublic();\n mouse.name = \"Wireless Mouse\";\n mouse.price = 29.99;\n mouse.stock = 50;\n System.out.println(mouse.name + \" costs $\" + mouse.price + \", stock \" + mouse.stock);\n }\n}\n```\n\n\nThis works. It also fails the moment any of the following happens:\n\n- A bug somewhere in the codebase sets `mouse.price = -5.0`. Nothing stops it. The catalog now has a product with a negative price.\n- A rule says `stock` should never go below zero. There is no single place to enforce that, because every caller writes directly to the field.\n- A new requirement says \"price is stored in cents internally, but the public API still exposes dollars\". Every line of code that touches `price` must change.\n- A logging team wants every change to `stock` recorded for an audit. There is no hook to add the logging to.\n\nA getter and a setter sidestep all of these. The field becomes `private`, callers go through methods, and the methods can validate, transform, log, or change their underlying storage without breaking any caller. The field is an implementation detail. The methods are the contract.\n\n\n```java\npublic class ProductWithAccessors {\n private String name;\n private double price;\n private int stock;\n\n public String getName() { return name; }\n public void setName(String name) { this.name = name; }\n\n public double getPrice() { return price; }\n public void setPrice(double price) { this.price = price; }\n\n public int getStock() { return stock; }\n public void setStock(int stock) { this.stock = stock; }\n\n public static void main(String[] args) {\n ProductWithAccessors mouse = new ProductWithAccessors();\n mouse.setName(\"Wireless Mouse\");\n mouse.setPrice(29.99);\n mouse.setStock(50);\n System.out.println(mouse.getName() + \" costs $\" + mouse.getPrice() + \", stock \" + mouse.getStock());\n }\n}\n```\n\n\nSame behavior at the call site, more flexibility internally. There's no validation yet, but the door is open. The validation section is next.\n\nThree benefits this pattern provides:\n\n- **Validation.** Setters can reject bad input before it corrupts the object.\n- **Computed values.** Getters can return data that isn't directly stored, like a discounted price.\n- **A stable external API.** The class can change how it stores data internally without breaking callers. As long as `getPrice()` still returns a `double`, the caller doesn't care whether the storage is in cents or dollars.\n\nThe standard setup is `private` for fields and `public` for accessor methods.\n\n---\n\n# JavaBean Naming Conventions\n\nJava has firm conventions for accessor method names, originally formalized by the JavaBeans specification. Tools, frameworks, and IDEs all expect them.\n\n\n| Field declaration | Getter name | Setter name |\n| --- | --- | --- |\n| `private String name` | `getName()` | `setName(String name)` |\n| `private double price` | `getPrice()` | `setPrice(double price)` |\n| `private int stockCount` | `getStockCount()` | `setStockCount(int stockCount)` |\n| `private boolean available` | `isAvailable()` | `setAvailable(boolean available)` |\n\n\nThe pattern:\n\n- A getter takes no arguments and returns the field's type. Its name is `get` followed by the field name with its first letter uppercased.\n- A setter takes one argument of the field's type, returns `void`, and is named `set` followed by the same uppercased field name.\n- For a boolean field, the getter is conventionally named `is` instead of `get`. `isAvailable()` reads naturally inside an `if`: `if (product.isAvailable()) { ... }`. The setter still uses `set`.\n\nThe compiler doesn't enforce these names. `fetchName()` and `assignName(String)` would compile fine. But every reflection-based framework (Spring, Jackson, Hibernate, the older JavaBeans tools), every IDE that generates accessors, and every developer reading the code expects the standard names. Deviating from them costs compatibility for no real benefit.\n\n---\n\n# A Standard Product Class\n\nPutting the conventions together, here is the canonical shape of an e-commerce `Product`. Fields are `private`, accessors are `public`, and a small `main` method exercises them.\n\n\n```java\npublic class Product {\n private String name;\n private double price;\n private int stock;\n\n public String getName() {\n return name;\n }\n public void setName(String name) {\n this.name = name;\n }\n\n public double getPrice() {\n return price;\n }\n public void setPrice(double price) {\n this.price = price;\n }\n\n public int getStock() {\n return stock;\n }\n public void setStock(int stock) {\n this.stock = stock;\n }\n\n public static void main(String[] args) {\n Product headphones = new Product();\n headphones.setName(\"Wireless Headphones\");\n headphones.setPrice(89.99);\n headphones.setStock(25);\n\n System.out.println(headphones.getName());\n System.out.println(\"Price: $\" + headphones.getPrice());\n System.out.println(\"Stock: \" + headphones.getStock());\n }\n}\n```\n\n\nThe class has a clear external surface: six methods, three pieces of data. A caller can do exactly two things with each piece of data, read it or write it, and the class controls how both operations behave. That control is what the rest of the lesson builds on.\n\nA diagram of the same idea: the fields sit behind a wall of accessors. Callers only touch the methods, never the fields directly.\n\n\n```mermaid\nflowchart LR\n Caller[Caller code]:::cyan -->|setName| SN[setName]:::orange\n Caller -->|setPrice| SP[setPrice]:::orange\n Caller -->|setStock| SS[setStock]:::orange\n Caller -->|getName| GN[getName]:::green\n Caller -->|getPrice| GP[getPrice]:::green\n Caller -->|getStock| GS[getStock]:::green\n\n SN --> F[private fields:
name, price, stock]:::teal\n SP --> F\n SS --> F\n GN --> F\n GP --> F\n GS --> F\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\nThe fields live in the middle. Setters on the left write to them; getters on the right read from them. Callers stay on the outside. This separation is what people mean when they call this pattern encapsulation.\n\n---\n\n# Validation in Setters\n\nThe first practical benefit of using setters is that they can reject bad input. A setter is the one and only path that writes the field, so validation placed there is impossible to bypass.\n\nA negative price doesn't make sense. Neither does a negative stock count. An email address without an `@` is almost certainly a bug. All three checks belong inside the corresponding setters.\n\n\n```java\npublic class ValidatedProduct {\n private String name;\n private double price;\n private int stock;\n private String contactEmail;\n\n public String getName() { return name; }\n public void setName(String name) {\n if (name == null || name.isBlank()) {\n throw new IllegalArgumentException(\"name must not be blank\");\n }\n this.name = name;\n }\n\n public double getPrice() { return price; }\n public void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"price must not be negative, got \" + price);\n }\n this.price = price;\n }\n\n public int getStock() { return stock; }\n public void setStock(int stock) {\n if (stock < 0) {\n throw new IllegalArgumentException(\"stock must not be below zero, got \" + stock);\n }\n this.stock = stock;\n }\n\n public String getContactEmail() { return contactEmail; }\n public void setContactEmail(String contactEmail) {\n if (contactEmail == null || !contactEmail.contains(\"@\")) {\n throw new IllegalArgumentException(\"contactEmail must contain @, got \" + contactEmail);\n }\n this.contactEmail = contactEmail;\n }\n\n public static void main(String[] args) {\n ValidatedProduct mouse = new ValidatedProduct();\n mouse.setName(\"Wireless Mouse\");\n mouse.setPrice(29.99);\n mouse.setStock(50);\n mouse.setContactEmail(\"seller@store.com\");\n System.out.println(\"Created: \" + mouse.getName() + \" @ $\" + mouse.getPrice());\n\n try {\n mouse.setPrice(-1.0);\n } catch (IllegalArgumentException e) {\n System.out.println(\"Rejected: \" + e.getMessage());\n }\n }\n}\n```\n\n\nThree details:\n\n- The check happens **before** the assignment. With `this.price = price; if (price < 0) throw ...`, the bad value would already be in the field by the time the check ran.\n- The error message includes the offending value. When a setter rejects input from somewhere deep in a call stack, the value is the most useful thing to know.\n- The exception type is `IllegalArgumentException`. It's a standard unchecked exception meant for exactly this situation: \"the caller passed an argument the method refuses to accept\". The Exception Handling section covers exceptions in depth.\n\nValidation in setters runs on every single write. For hot paths that set a field millions of times per second, this might add up. For ordinary object creation and updates, the cost is negligible compared to the cost of having a corrupted object.\n\n### A Common Bad Habit: Swallowing Errors\n\nValidation is only useful if a rejected setter call is loud. A common mistake is to validate and then do nothing on bad input.\n\n**What's wrong with this code?**\n\n\n```java\npublic void setPrice(double price) {\n if (price < 0) {\n return; // ignore bad input\n }\n this.price = price;\n}\n```\n\n\nThe setter returns `void`, so the caller has no way to know whether the assignment happened. A buggy caller passes `-5.0`, the setter does nothing, the caller moves on assuming the price was set, and the rest of the program runs with a stale value. The bug shows up much later, far from its source.\n\n**Fix:**\n\n\n```java\npublic void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"price must not be negative, got \" + price);\n }\n this.price = price;\n}\n```\n\n\nThrowing is louder. The caller can't ignore it; the program either handles the exception explicitly or crashes at the exact point where the bad value showed up. That's much easier to debug than a stale field.\n\n---\n\n# Read-Only Fields: Getter Only\n\nNot every field needs a setter. Some values are set once when the object is created and should never change. A product's permanent identifier is a good example. The system assigns it, it appears on receipts and in databases, and changing it would silently break every reference to that product elsewhere.\n\nFor a read-only field, give it a getter and skip the setter. Set the value in the constructor, then leave it alone.\n\n\n```java\npublic class ProductWithId {\n private final String productId;\n private String name;\n private double price;\n\n public ProductWithId(String productId, String name, double price) {\n this.productId = productId;\n this.name = name;\n this.price = price;\n }\n\n public String getProductId() {\n return productId;\n }\n\n public String getName() { return name; }\n public void setName(String name) { this.name = name; }\n\n public double getPrice() { return price; }\n public void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"price must not be negative\");\n }\n this.price = price;\n }\n\n public static void main(String[] args) {\n ProductWithId headphones = new ProductWithId(\"P-1042\", \"Wireless Headphones\", 89.99);\n System.out.println(\"ID: \" + headphones.getProductId());\n\n headphones.setName(\"Wireless Headphones Pro\");\n headphones.setPrice(99.99);\n System.out.println(headphones.getName() + \" is now $\" + headphones.getPrice());\n }\n}\n```\n\n\nTwo things make `productId` read-only here:\n\n- There's no `setProductId` method. A caller has no way to change the value after construction.\n- The field is declared `final`. That tells the compiler the field can only be assigned once, in the constructor. Even code inside the class can't accidentally reassign it later. `final` isn't strictly required for a read-only field (the absence of a setter is enough for external callers), but it's a useful belt-and-braces signal.\n\nFor now, treat `final` as a way to say \"this value is set once and never changes\".\n\nRead-only fields are common for anything that identifies an object: order IDs, customer IDs, timestamps for when something was created. Once the system assigns them, changing them would break every reference that uses them.\n\n---\n\n# Write-Only Fields: Setter Only\n\nThe opposite case, a field with only a setter and no getter, exists but is rare. The classic example is a password reset. The class accepts a new password, but no code should be able to read the stored password back out.\n\n\n```java\npublic class CustomerCredentials {\n private String username;\n private String passwordHash;\n\n public CustomerCredentials(String username) {\n this.username = username;\n }\n\n public String getUsername() { return username; }\n\n public void setPassword(String newPassword) {\n if (newPassword == null || newPassword.length() < 8) {\n throw new IllegalArgumentException(\"password must be at least 8 characters\");\n }\n this.passwordHash = hash(newPassword);\n }\n\n // No getPassword() method. The hashed password is internal only.\n\n private String hash(String raw) {\n // Real code would use a proper hash algorithm here.\n return \"hash:\" + raw.hashCode();\n }\n\n public boolean verify(String attempt) {\n return passwordHash != null && passwordHash.equals(hash(attempt));\n }\n\n public static void main(String[] args) {\n CustomerCredentials creds = new CustomerCredentials(\"alice\");\n creds.setPassword(\"hunter2x9\");\n System.out.println(\"Login user: \" + creds.getUsername());\n System.out.println(\"Correct password? \" + creds.verify(\"hunter2x9\"));\n System.out.println(\"Wrong password? \" + creds.verify(\"wrong\"));\n }\n}\n```\n\n\nThe class accepts a password through `setPassword` but never lets a caller read it back. Anything that needs to use the password (logging in, for example) does so through other methods like `verify`, which takes a candidate password and compares it to the stored hash without revealing it.\n\nWrite-only setters are a useful sanity check for security-sensitive data: secrets, tokens, internal keys. The pattern is rare because most fields have at least one legitimate reader. Use it only when the data should never leave the object.\n\n---\n\n# Computed Getters: Returning Derived Values\n\nA getter doesn't have to return a field directly. It can compute a value on the fly from one or more fields and return that. This is the second big reason to expose state through methods rather than fields: the caller doesn't have to know whether the value is stored or calculated.\n\nA discounted price is a good example. The base price is stored. The discount percentage is stored. The discounted price is whatever those two add up to, computed when someone asks.\n\n\n```java\npublic class DiscountedProduct {\n private String name;\n private double price;\n private double discountPercent;\n\n public DiscountedProduct(String name, double price, double discountPercent) {\n this.name = name;\n this.price = price;\n this.discountPercent = discountPercent;\n }\n\n public String getName() { return name; }\n public double getPrice() { return price; }\n public double getDiscountPercent() { return discountPercent; }\n\n public double getDiscountedPrice() {\n return price * (1 - discountPercent / 100);\n }\n\n public static void main(String[] args) {\n DiscountedProduct mouse = new DiscountedProduct(\"Wireless Mouse\", 29.99, 10.0);\n System.out.println(mouse.getName());\n System.out.println(\"Base price: $\" + mouse.getPrice());\n System.out.println(\"Discount: \" + mouse.getDiscountPercent() + \"%\");\n System.out.println(\"Discounted price: $\" + mouse.getDiscountedPrice());\n }\n}\n```\n\n\n`getDiscountedPrice` isn't backed by a field. Each call recomputes the value. From outside the class, it looks identical to any other getter: take no arguments, return a `double`. The fact that it's derived is an implementation detail the caller doesn't need to know.\n\nComputed getters are useful for:\n\n- Values that can drift if stored separately, like a total that's the sum of line items.\n- Values that depend on something other than fields, like the current date.\n- Unit conversions, like a price stored in cents but exposed in dollars.\n\nA computed getter does its work on every call. If the computation is expensive (loops over a list, walks a tree) and gets called inside a tight loop, consider caching the result or computing it once and storing it. For arithmetic on a couple of doubles, the cost is invisible.\n\n---\n\n# Side Effects in Setters\n\nA setter's job is to set a field. Anything beyond that, logging, sending notifications, recalculating other fields, talking to a database, is a **side effect**. A small amount of side-effect logic is reasonable (the validation we already wrote is technically a side effect). A lot of it is a code smell.\n\nConsider this overcooked setter.\n\n\n```java\npublic class HeavySetterProduct {\n private double price;\n\n public void setPrice(double price) {\n logPriceChange(this.price, price);\n notifySubscribers(price);\n updateRecommendationEngine(price);\n rebuildSearchIndex();\n this.price = price;\n }\n\n private void logPriceChange(double oldPrice, double newPrice) {\n System.out.println(\"Price change: \" + oldPrice + \" -> \" + newPrice);\n }\n private void notifySubscribers(double newPrice) {\n System.out.println(\"Notifying 4,200 subscribers\");\n }\n private void updateRecommendationEngine(double newPrice) {\n System.out.println(\"Recomputing recommendations\");\n }\n private void rebuildSearchIndex() {\n System.out.println(\"Rebuilding search index\");\n }\n}\n```\n\n\nSetting a price now triggers four pieces of business logic. A caller writing `product.setPrice(29.99)` cannot tell from the call site that they're also triggering a search rebuild. The setter has also become impossible to use in tests or in any context where those side effects shouldn't fire.\n\nThe fix isn't to add side effects to a setter; it's to move the side effects out of it.\n\n\n```java\npublic class CleanSetterProduct {\n private double price;\n\n public double getPrice() { return price; }\n public void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"price must not be negative\");\n }\n this.price = price;\n }\n\n public void updatePriceAndNotify(double newPrice) {\n double oldPrice = this.price;\n setPrice(newPrice);\n System.out.println(\"Price change: \" + oldPrice + \" -> \" + newPrice);\n System.out.println(\"Notifying subscribers\");\n }\n}\n```\n\n\n`setPrice` is back to its small, predictable shape. The orchestration that wants logging and notifications has its own clearly-named method, `updatePriceAndNotify`, for callers that want all that to happen.\n\nThe rule of thumb: a setter should be safe to call without considering cascading effects. Light validation belongs there. Heavy work, especially anything that talks to the network, the database, or other services, does not.\n\n---\n\n# Records and Immutable Classes\n\nTwo related shapes are worth a brief mention before we wrap up.\n\n**Records** are a Java feature (introduced in Java 16) for classes that exist mainly to carry data. Fields are declared once, and the compiler generates accessors automatically. The accessor naming differs from the standard convention: a record with a field `name` exposes it as `product.name()` rather than `product.getName()`. When a class is nothing but private fields and standard accessors, a record may be the better tool.\n\n**Immutable classes** deliberately have no setters at all. Every field is `final`, set once in the constructor, and there's no way to change it afterward. A new value means a new object. This is the design behind `String`, `LocalDate`, and many other core Java types. The takeaway is that \"always provide getters and setters\" is a starting point, not a law. Sometimes the answer is no setters at all.\n\n---\n\n# Putting It All Together\n\nA more complete `Product` class uses every idea from this lesson: a read-only ID, validated setters for price and stock, a computed discounted price, and no surprise side effects.\n\n\n```java\npublic class CatalogProduct {\n private final String productId;\n private String name;\n private double price;\n private int stock;\n private double discountPercent;\n\n public CatalogProduct(String productId, String name, double price, int stock) {\n this.productId = productId;\n setName(name);\n setPrice(price);\n setStock(stock);\n this.discountPercent = 0.0;\n }\n\n public String getProductId() { return productId; }\n\n public String getName() { return name; }\n public void setName(String name) {\n if (name == null || name.isBlank()) {\n throw new IllegalArgumentException(\"name must not be blank\");\n }\n this.name = name;\n }\n\n public double getPrice() { return price; }\n public void setPrice(double price) {\n if (price < 0) {\n throw new IllegalArgumentException(\"price must not be negative\");\n }\n this.price = price;\n }\n\n public int getStock() { return stock; }\n public void setStock(int stock) {\n if (stock < 0) {\n throw new IllegalArgumentException(\"stock must not be below zero\");\n }\n this.stock = stock;\n }\n\n public double getDiscountPercent() { return discountPercent; }\n public void setDiscountPercent(double discountPercent) {\n if (discountPercent < 0 || discountPercent > 100) {\n throw new IllegalArgumentException(\"discountPercent must be between 0 and 100\");\n }\n this.discountPercent = discountPercent;\n }\n\n public double getDiscountedPrice() {\n return price * (1 - discountPercent / 100);\n }\n\n public boolean isInStock() {\n return stock > 0;\n }\n\n public static void main(String[] args) {\n CatalogProduct mouse = new CatalogProduct(\"P-1042\", \"Wireless Mouse\", 29.99, 50);\n mouse.setDiscountPercent(15.0);\n\n System.out.println(\"ID: \" + mouse.getProductId());\n System.out.println(\"Name: \" + mouse.getName());\n System.out.println(\"Price: $\" + mouse.getPrice());\n System.out.println(\"After 15%: $\" + mouse.getDiscountedPrice());\n System.out.println(\"Stock: \" + mouse.getStock());\n System.out.println(\"Available? \" + mouse.isInStock());\n }\n}\n```\n\n\nThe constructor calls the setters rather than assigning the fields directly. That way, the validation rules apply to construction too. A `CatalogProduct` can't be built with a blank name or a negative price, because the constructor would throw the same exception a later `setName(null)` would throw.\n\nThe class has five fields, but its external API is the set of public methods: six getters, four setters, and two boolean / computed helpers. That collection of methods is the contract. The fields behind them are an implementation detail.","pageType":"java"}

Getters & Setters

Get Premium