{"title":"Constructors","description":"","content":"In the last lesson, we used `new Product()` to create objects and then assigned each field one at a time. That works, but it leaves the object in an awkward half-built state until every field has been set. A constructor fixes that by making field initialization part of the act of creating the object. This lesson covers what a constructor is, the default no-arg constructor the compiler quietly adds, parameterized constructors, and how to overload constructors so a class can be built in more than one way.\n\n---\n\n# What a Constructor Is\n\nA constructor is a special method that runs when you create an object with `new`. It sets up the object's initial state. Once the constructor finishes, the new object is ready to use.\n\nA small class with a constructor:\n\n\n```java\npublic class Product {\n String name;\n double price;\n int stock;\n\n public Product() {\n name = \"Unknown\";\n price = 0.0;\n stock = 0;\n }\n\n public static void main(String[] args) {\n Product p = new Product();\n System.out.println(\"Name: \" + p.name);\n System.out.println(\"Price: $\" + p.price);\n System.out.println(\"Stock: \" + p.stock);\n }\n}\n```\n\n\nThe line `new Product()` does two things. It allocates memory for a fresh `Product` object, and then it calls the `Product()` constructor body. By the time the assignment `Product p = new Product()` finishes, `p` points at a `Product` whose fields hold the values the constructor set.\n\nThat's the whole idea. Instead of writing `Product p = new Product(); p.name = \"Unknown\"; p.price = 0.0; p.stock = 0;` at every call site, the class itself takes care of the initial values, in one place.\n\n---\n\n# Why Constructors Exist\n\nWithout constructors, every caller has to know which fields to set and in what order. Forget one, and the object ships with a stale or invalid value. Spread that responsibility across a codebase and the bugs become hard to track down.\n\nLook at a small example without a constructor.\n\n\n```java\npublic class Customer {\n String name;\n String email;\n int loyaltyPoints;\n\n public static void main(String[] args) {\n Customer alice = new Customer();\n alice.name = \"Alice\";\n alice.email = \"alice@example.com\";\n // forgot to set loyaltyPoints\n\n System.out.println(alice.name + \" has \" + alice.loyaltyPoints + \" points\");\n }\n}\n```\n\n\nThe output happens to look okay because `int` fields default to `0`. But the program never told us whether Alice has zero loyalty points or whether we just forgot to set them. Now imagine the field were `String referralCode`. Forgetting to set it would leave it `null`, and the first piece of code that read it would crash with a `NullPointerException`.\n\nA constructor moves that responsibility from every caller into one place. The same class with a constructor:\n\n\n```java\npublic class Customer {\n String name;\n String email;\n int loyaltyPoints;\n\n public Customer(String name, String email, int loyaltyPoints) {\n this.name = name;\n this.email = email;\n this.loyaltyPoints = loyaltyPoints;\n }\n\n public static void main(String[] args) {\n Customer alice = new Customer(\"Alice\", \"alice@example.com\", 150);\n System.out.println(alice.name + \" has \" + alice.loyaltyPoints + \" points\");\n }\n}\n```\n\n\nNow there's no way to forget a field. The constructor demands all three at construction time, so an `alice` that exists at all is an `alice` whose fields are filled in. We use `this.name = name` to assign the parameter `name` to the field `name`; for now, read `this` as \"the field on this object\".\n\nThe bigger point is that constructors let you state, in one place, what it means for an object to be valid. Anything that calls `new Customer(...)` is forced to supply the data needed to satisfy that contract.\n\n---\n\n# Constructor vs Regular Method\n\nConstructors look like methods, but they follow different rules. The differences are easy to miss because the syntax overlaps. A side-by-side comparison:\n\n\n| Aspect | Constructor | Regular method |\n| --- | --- | --- |\n| Name | Must match the class name exactly | Any valid identifier |\n| Return type | None at all, not even `void` | Required: `void` or some type |\n| How it runs | Automatically when you write `new ClassName(...)` | Only when you call it by name |\n| `return` statement | Optional bare `return;`; never returns a value | Required for non-`void` methods |\n| Purpose | Initialize the new object | Anything else |\n\n\nA regular method might look like `public void reset()` and you'd call it as `product.reset()`. A constructor looks like `public Product()` and you can only invoke it through `new Product()`. The two are wired into the language differently.\n\nA class with both, to see them line up:\n\n\n```java\npublic class Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public void printSummary() {\n System.out.println(name + \" @ $\" + price);\n }\n\n public static void main(String[] args) {\n Product mouse = new Product(\"Wireless Mouse\", 29.99);\n mouse.printSummary();\n }\n}\n```\n\n\n`Product(String name, double price)` is the constructor. No return type, name matches the class. `printSummary` is a regular method. Return type `void`, name unrelated to the class. The constructor runs as part of `new Product(...)`. `printSummary` runs only because we explicitly called it.\n\nA common point of confusion: if you accidentally give a constructor a return type, Java treats it as a method that happens to share its name with the class. The compiler won't complain, but it won't run on `new` either.\n\n**What's wrong with this code?**\n\n\n```java\npublic class Cart {\n int itemCount;\n\n public void Cart(int initialCount) {\n itemCount = initialCount;\n }\n\n public static void main(String[] args) {\n Cart cart = new Cart(5);\n System.out.println(\"Items: \" + cart.itemCount);\n }\n}\n```\n\n\nThe line `public void Cart(int initialCount)` looks like a constructor, but the `void` makes it a regular method named `Cart`. There is no real constructor with that signature, so `new Cart(5)` fails to compile with `constructor Cart in class Cart cannot be applied to given types`. (And even if you wrote `new Cart()` instead, the method `Cart(int)` would never run.)\n\n**Fix:**\n\n\n```java\npublic class Cart {\n int itemCount;\n\n public Cart(int initialCount) {\n itemCount = initialCount;\n }\n\n public static void main(String[] args) {\n Cart cart = new Cart(5);\n System.out.println(\"Items: \" + cart.itemCount);\n }\n}\n```\n\n\nDrop the `void` and the constructor works.\n\n---\n\n# The Default No-Arg Constructor\n\nYou can write a class without declaring any constructor at all. When the compiler sees a class with no constructors, it generates a hidden one for you: a public, no-argument constructor with an empty body. This is the **default constructor**.\n\n\n```java\npublic class Address {\n String street;\n String city;\n String zipCode;\n}\n```\n\n\nEven though you never wrote a constructor, you can still write `new Address()` and the compiler-generated one runs. After construction, every field holds its default value: `null` for references, `0` for numeric primitives, `false` for `boolean`.\n\n\n```java\npublic class AddressDemo {\n public static void main(String[] args) {\n Address a = new Address();\n System.out.println(\"Street: \" + a.street);\n System.out.println(\"City: \" + a.city);\n System.out.println(\"Zip: \" + a.zipCode);\n }\n}\n```\n\n\nThe default constructor is convenient when a class is simple enough that any field defaults are fine. But the moment you declare even one constructor of your own, the compiler stops generating the default. From that point on, only the constructors you wrote exist.\n\nThis is the source of one of the most common new-Java errors. Look at this code.\n\n\n```java\npublic class Order {\n int orderId;\n double total;\n\n public Order(int orderId, double total) {\n this.orderId = orderId;\n this.total = total;\n }\n}\n\npublic class OrderDemo {\n public static void main(String[] args) {\n Order blank = new Order();\n System.out.println(blank.orderId);\n }\n}\n```\n\n\nThe line `new Order()` looks innocent. But `Order` declares a parameterized constructor, which suppresses the default. The compiler reports:\n\n\n```shell\nerror: constructor Order in class Order cannot be applied to given types;\n Order blank = new Order();\n ^\n required: int,double\n found: no arguments\n```\n\n\nThe fix is one of two things. If you want a no-arg version, add it explicitly. If you don't, supply the arguments the existing constructor requires.\n\n**Fix (option 1, add a no-arg constructor):**\n\n\n```java\npublic class Order {\n int orderId;\n double total;\n\n public Order() {\n this.orderId = 0;\n this.total = 0.0;\n }\n\n public Order(int orderId, double total) {\n this.orderId = orderId;\n this.total = total;\n }\n}\n```\n\n\n**Fix (option 2, pass arguments at the call site):**\n\n\n```java\nOrder blank = new Order(0, 0.0);\n```\n\n\nBoth compile. Which one you pick depends on whether a \"blank\" `Order` is a meaningful concept in your code.\n\n---\n\n# Parameterized Constructors\n\nA parameterized constructor takes arguments and uses them to initialize fields. This is the form you'll write most often. The pattern is straightforward: declare the parameters in the constructor's parameter list, then assign each one to the matching field.\n\n\n```java\npublic class Product {\n String name;\n double price;\n int stock;\n\n public Product(String name, double price, int stock) {\n this.name = name;\n this.price = price;\n this.stock = stock;\n }\n\n public static void main(String[] args) {\n Product mouse = new Product(\"Wireless Mouse\", 29.99, 50);\n Product cable = new Product(\"USB Cable\", 9.99, 200);\n\n System.out.println(mouse.name + \": $\" + mouse.price + \", stock \" + mouse.stock);\n System.out.println(cable.name + \": $\" + cable.price + \", stock \" + cable.stock);\n }\n}\n```\n\n\nBoth objects are fully populated by the time `new` returns. We never write `mouse.name = ...` from `main`, because the constructor already handled it.\n\nA constructor can do real work inside its body, not just assignment. It's still a method, so any normal code is allowed. A common case is deriving one field from the inputs:\n\n\n```java\npublic class Order {\n int orderId;\n double subtotal;\n double tax;\n double total;\n\n public Order(int orderId, double subtotal, double taxRate) {\n this.orderId = orderId;\n this.subtotal = subtotal;\n this.tax = subtotal * taxRate;\n this.total = subtotal + tax;\n }\n\n public static void main(String[] args) {\n Order order = new Order(1042, 100.0, 0.08);\n System.out.println(\"Order \" + order.orderId + \": subtotal=$\" + order.subtotal\n + \", tax=$\" + order.tax + \", total=$\" + order.total);\n }\n}\n```\n\n\nThe caller supplies `subtotal` and `taxRate`. The constructor figures out `tax` and `total` from them. After `new Order(...)`, the order is a fully consistent object: the total matches the subtotal plus tax, by construction. There's no way for a caller to forget to compute `tax` or to set `total` to a value that doesn't match. That guarantee is one of the main reasons constructors exist.\n\nConstructor parameters live for as long as the constructor is running, the same as any other method's local variables. Once construction finishes, they're gone. Only the fields persist.\n\n---\n\n# Object Construction Step by Step\n\nWhen you write `new Product(\"Mouse\", 29.99, 50)`, Java goes through a small fixed sequence. Knowing it helps explain a few behaviors that otherwise look mysterious.\n\n\n```mermaid\nflowchart LR\n A[new Product...]:::cyan --> B[Allocate memory
for the object]:::orange\n B --> C[Fields set to
default values
0, false, null]:::teal\n C --> D[Run constructor body
assignments and logic]:::green\n D --> E[Return reference
to the new object]:::cyan\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\nStep by step:\n\n1. **Allocate memory.** The JVM reserves enough heap space to hold every field of the class. The reference variable you assign to (like `mouse`) doesn't yet point at anything.\n2. **Default values.** Before your constructor runs at all, every field is set to its default: `0` for numeric primitives, `false` for `boolean`, `null` for references. This is why fields you forget to assign aren't garbage. They're zeros.\n3. **Constructor body.** Your code runs. Every `this.field = value` overwrites the default with the value you actually want.\n4. **Return the reference.** Once the body finishes, `new` evaluates to a reference pointing at the new object. The assignment `Product mouse = new Product(...)` stores that reference in `mouse`.\n\nOne consequence: if your constructor body never assigns to a field, that field keeps its default. Java doesn't warn you. The object is built; the field just happens to be `0` or `null`.\n\n\n```java\npublic class Cart {\n String customerName;\n int itemCount;\n double total;\n\n public Cart(String customerName) {\n this.customerName = customerName;\n // itemCount and total never assigned\n }\n\n public static void main(String[] args) {\n Cart cart = new Cart(\"Alice\");\n System.out.println(\"Customer: \" + cart.customerName);\n System.out.println(\"Items: \" + cart.itemCount);\n System.out.println(\"Total: $\" + cart.total);\n }\n}\n```\n\n\n`itemCount` and `total` keep their primitive defaults. No error, no warning. If `0` items and `$0.0` are sensible starting values for a new cart, this is fine. If they aren't, the bug is silent.\n\n---\n\n# Constructor Overloading\n\nA class can declare more than one constructor, as long as each one has a different parameter list. This is exactly the same rule that applies to method overloading. The compiler picks which constructor to run based on the arguments you pass to `new`.\n\nThe reason this matters: real classes often have several reasonable ways to be created. A `Review` might be built from a rating alone, a rating and a text comment, or a full set of fields including the reviewer's name. Forcing every caller into one rigid signature is awkward.\n\n\n```java\npublic class Review {\n int rating;\n String comment;\n String reviewerName;\n\n public Review(int rating) {\n this.rating = rating;\n this.comment = \"\";\n this.reviewerName = \"Anonymous\";\n }\n\n public Review(int rating, String comment) {\n this.rating = rating;\n this.comment = comment;\n this.reviewerName = \"Anonymous\";\n }\n\n public Review(int rating, String comment, String reviewerName) {\n this.rating = rating;\n this.comment = comment;\n this.reviewerName = reviewerName;\n }\n\n public static void main(String[] args) {\n Review r1 = new Review(5);\n Review r2 = new Review(4, \"Good product\");\n Review r3 = new Review(3, \"Average\", \"Alice\");\n\n System.out.println(r1.reviewerName + \": \" + r1.rating + \" stars, '\" + r1.comment + \"'\");\n System.out.println(r2.reviewerName + \": \" + r2.rating + \" stars, '\" + r2.comment + \"'\");\n System.out.println(r3.reviewerName + \": \" + r3.rating + \" stars, '\" + r3.comment + \"'\");\n }\n}\n```\n\n\nThree constructors, three call shapes. Each call site uses whichever one matches the data it actually has. The compiler resolves `new Review(5)` to the one-argument constructor, `new Review(4, \"Good product\")` to the two-argument one, and so on. The rules are the same three-phase resolution (exact match, widening, boxing, varargs) we saw with method overloading.\n\nYou can also overload constructors purely by parameter type, not just count.\n\n\n```java\npublic class Order {\n int orderId;\n double total;\n\n public Order(int orderId, double total) {\n this.orderId = orderId;\n this.total = total;\n }\n\n public Order(String orderIdAsText, double total) {\n this.orderId = Integer.parseInt(orderIdAsText);\n this.total = total;\n }\n\n public static void main(String[] args) {\n Order fromNumber = new Order(1042, 89.99);\n Order fromText = new Order(\"1042\", 89.99);\n System.out.println(\"From number: \" + fromNumber.orderId);\n System.out.println(\"From text: \" + fromText.orderId);\n }\n}\n```\n\n\nBoth constructors set the same fields, but they accept the order ID in different forms. The caller picks whichever one matches what they have on hand.\n\nOne thing to notice about the three-constructor `Review` example: the assignments are duplicated. Every constructor assigns the same field names. If you add a new field, you have to remember to update all three. There's a much cleaner way to handle this where the shorter constructors call the longer one through `this(...)` instead of repeating the assignments.\n\n---\n\n# What Counts as a Different Constructor\n\nThe signature of a constructor, just like a method, is the constructor name (which equals the class name) plus the ordered list of parameter types. Two constructors are valid overloads only if their signatures differ.\n\n\n| Are these valid overloads? | Why |\n| --- | --- |\n| `Product(String, double)` and `Product(String, double, int)` | Yes, different number of parameters |\n| `Product(String, double)` and `Product(double, String)` | Yes, same types in different order |\n| `Product(String, double)` and `Product(String, int)` | Yes, different parameter types |\n| `Product(String name)` and `Product(String productName)` | No, parameter names are not part of the signature |\n| `Product(String)` returning the implicit `this` and a hypothetical `Product(String)` \"returning\" something else | Not applicable: constructors have no return type at all |\n\n\nIf two constructors have the same signature, the compiler rejects the second one with `constructor Product is already defined`.\n\n\n```java\npublic class Product {\n String name;\n double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n // This would NOT compile if uncommented:\n // public Product(String productName, double productPrice) {\n // this.name = productName;\n // this.price = productPrice;\n // }\n\n public static void main(String[] args) {\n Product p = new Product(\"Wireless Mouse\", 29.99);\n System.out.println(p.name + \" @ $\" + p.price);\n }\n}\n```\n\n\nThe commented-out constructor has the same parameter types in the same order. The compiler treats it as a duplicate even though the parameter names are different.\n\n---\n\n# Common Mistakes\n\nA few errors come up often when writing constructors. Knowing the shape of the error message makes them easy to fix.\n\n### Mistake 1: Declaring a Return Type\n\nA constructor must not have a return type, not even `void`. If you add one, you've actually declared a regular method that happens to share its name with the class. The compiler accepts it but won't call it on `new`.\n\n**What's wrong with this code?**\n\n\n```java\npublic class Coupon {\n String code;\n double percentOff;\n\n public void Coupon(String code, double percentOff) {\n this.code = code;\n this.percentOff = percentOff;\n }\n}\n```\n\n\n`public void Coupon(...)` is a method called `Coupon`, not a constructor. Because no actual constructor matches the parameter list, `new Coupon(\"WELCOME10\", 10.0)` won't compile. And because the class declared no other constructors, the compiler did add a default no-arg one, so `new Coupon()` still works, just without setting any fields.\n\n**Fix:**\n\n\n```java\npublic class Coupon {\n String code;\n double percentOff;\n\n public Coupon(String code, double percentOff) {\n this.code = code;\n this.percentOff = percentOff;\n }\n}\n```\n\n\nRemove the `void`. Now it's a real constructor and `new Coupon(\"WELCOME10\", 10.0)` works.\n\n### Mistake 2: Calling `new ClassName()` After Adding a Parameterized Constructor\n\nWe covered this earlier, but the error message can be confusing. The moment a class declares any constructor, the implicit no-arg one disappears.\n\n**What's wrong with this code?**\n\n\n```java\npublic class Address {\n String street;\n String city;\n\n public Address(String street, String city) {\n this.street = street;\n this.city = city;\n }\n\n public static void main(String[] args) {\n Address a = new Address();\n System.out.println(a.city);\n }\n}\n```\n\n\nThe compiler error is:\n\n\n```shell\nerror: constructor Address in class Address cannot be applied to given types;\n Address a = new Address();\n ^\n required: String,String\n found: no arguments\n```\n\n\nThe class no longer has a no-arg constructor because the parameterized one took its place.\n\n**Fix (option 1, add a no-arg constructor explicitly):**\n\n\n```java\npublic class Address {\n String street;\n String city;\n\n public Address() {\n this.street = \"\";\n this.city = \"\";\n }\n\n public Address(String street, String city) {\n this.street = street;\n this.city = city;\n }\n\n public static void main(String[] args) {\n Address a = new Address();\n System.out.println(\"'\" + a.city + \"'\");\n }\n}\n```\n\n\n**Fix (option 2, pass the arguments the existing constructor needs):**\n\n\n```java\nAddress a = new Address(\"123 Main St\", \"Springfield\");\n```\n\n\nPick whichever fits the situation. If a \"blank\" `Address` makes sense in your code, add the no-arg version. If every `Address` should require both fields, drop the call to `new Address()` and pass real values.\n\n### Mistake 3: Confusing Field Names With Parameter Names\n\nIf a constructor parameter has the same name as a field, the parameter \"shadows\" the field inside the constructor body. An unqualified assignment writes to the parameter, not the field, which is almost certainly not what you wanted.\n\n**What's wrong with this code?**\n\n\n```java\npublic class Customer {\n String name;\n String email;\n\n public Customer(String name, String email) {\n name = name;\n email = email;\n }\n\n public static void main(String[] args) {\n Customer c = new Customer(\"Alice\", \"alice@example.com\");\n System.out.println(\"Name: \" + c.name);\n System.out.println(\"Email: \" + c.email);\n }\n}\n```\n\n\nBoth fields stay `null`. The lines `name = name;` and `email = email;` assign the parameter to itself, because inside the constructor, the unqualified name `name` refers to the parameter (the closer-scoped one), not the field. The field is never touched.\n\n**Fix:**\n\n\n```java\npublic class Customer {\n String name;\n String email;\n\n public Customer(String name, String email) {\n this.name = name;\n this.email = email;\n }\n\n public static void main(String[] args) {\n Customer c = new Customer(\"Alice\", \"alice@example.com\");\n System.out.println(\"Name: \" + c.name);\n System.out.println(\"Email: \" + c.email);\n }\n}\n```\n\n\n`this.name = name` says \"assign the parameter `name` to the field named `name` on the object being constructed\". When a field and a local variable share a name, prefix the field with `this.` to make clear which one you mean.\n\n---\n\n# A Worked Example: Order With Validation\n\nConstructors are a natural place to enforce rules about what makes an object valid. Putting validation in the constructor means a caller can't end up with a half-broken object that fails later in confusing ways.\n\n\n```java\npublic class Order {\n int orderId;\n String customerName;\n double total;\n\n public Order(int orderId, String customerName, double total) {\n if (orderId <= 0) {\n System.out.println(\"Warning: orderId should be positive, got \" + orderId);\n }\n if (customerName == null || customerName.isEmpty()) {\n System.out.println(\"Warning: customerName is missing\");\n }\n if (total < 0) {\n System.out.println(\"Warning: total cannot be negative, got \" + total);\n }\n\n this.orderId = orderId;\n this.customerName = customerName;\n this.total = total;\n }\n\n public void printSummary() {\n System.out.println(\"Order #\" + orderId + \" for \" + customerName + \": $\" + total);\n }\n\n public static void main(String[] args) {\n Order good = new Order(1042, \"Alice\", 89.99);\n good.printSummary();\n\n Order bad = new Order(-1, \"\", -5.0);\n bad.printSummary();\n }\n}\n```\n\n\nThe first `Order` passes its checks and prints normally. The second one trips every check, but the constructor still assigns the (invalid) values and the object is built. The warnings go to standard output. In real code, you'd typically throw an exception to refuse construction entirely. For now, printing a warning shows the idea. The constructor is where invariants get checked because it runs before any other code can use the object.\n\nThis example also keeps to one constructor for clarity. In real classes, you'd often pair this with overloads that fill in defaults so that simple cases don't require every argument.","pageType":"java"}

Constructors

Get Premium