{"title":"extends Keyword","description":"","content":"The previous lesson motivated inheritance: when two classes share a lot of state and behavior, a parent-child relationship lets the child reuse the parent's code instead of duplicating it. This lesson covers the actual syntax Java gives you to declare that relationship, the `extends` keyword, and the exact rules for what crosses the parent-child boundary. It also covers how `final` can block inheritance entirely, and walks through a complete `Product` and `Book` example so the inheritance rules show up in real code instead of in the abstract.\n\n---\n\n# The `extends` Syntax\n\nTo declare that one class inherits from another, write `extends` followed by the parent class name in the child's declaration:\n\n\n```java\nclass Book extends Product {\n // Book inherits Product's accessible members\n // Book can add its own fields and methods\n}\n```\n\n\nThe class on the right of `extends` is the **superclass** (also called the parent or base class). The class on the left is the **subclass** (also called the child or derived class). Java uses the terms \"superclass\" and \"subclass\" most consistently, so we'll stick with those.\n\nA few mechanics:\n\n- A class can extend **at most one** other class. Java does not allow multiple inheritance of classes. Without an `extends` clause, the class implicitly extends `java.lang.Object`. Multiple inheritance of behavior comes via interfaces.\n- The `extends` clause goes after the class name and before the opening brace.\n- The superclass must be visible to the subclass. If the superclass is in another package, an `import` is usually needed.\n- The superclass must not be `final`.\n\nA minimal example. `Product` is a simple superclass, and `Book` extends it without adding anything yet:\n\n\n```java\npublic class Product {\n protected String name;\n protected double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n public String describe() {\n return name + \" ($\" + price + \")\";\n }\n}\n\nclass Book extends Product {\n public Book(String name, double price) {\n super(name, price);\n }\n\n public static void main(String[] args) {\n Book javaBook = new Book(\"Effective Java\", 39.99);\n System.out.println(javaBook.describe());\n }\n}\n```\n\n\n`Book` doesn't define `describe` or hold its own `name` and `price` fields, yet `javaBook.describe()` works. This is inheritance. `Book` inherited `name`, `price`, and `describe` from `Product`. The `super(name, price)` call hands the constructor arguments off to `Product`'s constructor so those inherited fields get set. For now, treat that line as \"this is how the parent's constructor receives the arguments\".\n\nOnly the file declaring a `public` class can have `public class Foo` in it. To keep these examples runnable in a single file, the subclass is package-private (no modifier). In real projects, both classes would normally be `public` and live in their own files.\n\n---\n\n# What a Subclass Inherits\n\nWith `class Book extends Product`, every accessible field and method from `Product` becomes part of `Book`'s definition too. \"Accessible\" depends on two things: the access modifier of the member, and whether the subclass is in the same package as the superclass.\n\nThe full matrix:\n\n\n| Access modifier | Same package as superclass | Different package |\n| --- | --- | --- |\n| `public` | Inherited | Inherited |\n| `protected` | Inherited | Inherited |\n| package-private (no modifier) | Inherited | NOT inherited |\n| `private` | NOT inherited | NOT inherited |\n\n\nTwo things to take from this table:\n\n1. `public` and `protected` always cross the inheritance boundary. They reach the subclass no matter where the subclass lives.\n2. Package-private members only cross the boundary if the subclass is in the same package as the superclass. Cross a package boundary and they vanish.\n\n`private` is the strict one. A `private` field or method is never inherited, even by a subclass in the same package. That's the point of `private`: it stays inside the class that declared it.\n\nStatic members follow the same access rules, but they belong to the class, not to instances. A subclass can call an inherited `public static` method through its own name (`Book.staticMethod()`) or through the parent's name (`Product.staticMethod()`); both reach the same method.\n\nA `Product` with one member at each access level:\n\n\n```java\npublic class Product {\n public String name;\n protected double price;\n String category; // package-private\n private String secret; // not inherited\n\n public Product(String name, double price, String category, String secret) {\n this.name = name;\n this.price = price;\n this.category = category;\n this.secret = secret;\n }\n\n public String publicDescribe() {\n return name + \" ($\" + price + \")\";\n }\n\n protected String protectedTag() {\n return \"[\" + category + \"]\";\n }\n\n String packageTag() {\n return category.toUpperCase();\n }\n\n private String privateAudit() {\n return \"audit:\" + secret;\n }\n}\n```\n\n\nA `Book` in the same package gets `name`, `price`, `category`, `publicDescribe`, `protectedTag`, and `packageTag`. It does not get `secret` or `privateAudit`. The `private` members are still inside every `Book` object at runtime (`Product`'s constructor sets `secret`), but `Book`'s code can't see or touch them.\n\nIf `Book` lived in a different package, the package-private members (`category`, `packageTag`) would also disappear. Only `public` and `protected` would survive the package crossing.\n\nA quick visual of what crosses the boundary by access modifier, for a subclass in a different package:\n\n\n```mermaid\nflowchart LR\n PUB[public members]:::green\n PROT[protected members]:::green\n PKG[package-private
members]:::red\n PRIV[private members]:::red\n\n Boundary{{Inheritance
boundary}}:::orange\n\n PUB --> Boundary\n PROT --> Boundary\n PKG -. blocked .-> Boundary\n PRIV -. blocked .-> Boundary\n\n Boundary --> Sub[Subclass in
different package]:::cyan\n\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n```\n\n\nFor a subclass in the **same** package, only `private` members are blocked. The other three all cross.\n\nOne thing the term \"inherits\" doesn't quite capture: an inherited member is still defined in the superclass. The subclass doesn't get its own copy of the method's bytecode. When `javaBook.publicDescribe()` is called, Java looks up `publicDescribe` starting from `Book`, finds nothing, walks up to `Product`, finds it there, and runs the parent's version. Inheritance is about which methods are callable on the subclass, not about copying source code.\n\n---\n\n# What a Subclass Does NOT Inherit\n\nTwo categories of things never make it across the parent-child boundary, no matter what.\n\n**1. `private` members.** A `private` field or method belongs entirely to the class that declared it. Even if the subclass is in the same file or the same package, `private` stays put. The subclass doesn't inherit it, can't read it, and can't call it.\n\nIf `Product` has `private String internalSku`, then `Book` cannot write `this.internalSku` anywhere in its own methods. The compiler will report `internalSku has private access in Product`. To give a subclass access, change the modifier to `protected` (or `public` if appropriate), or add a `protected` getter on `Product`.\n\n**2. Constructors.** Constructors are not members in the inheritance sense; they describe how to build instances of the specific class they live in. A `Product(String, double)` constructor builds a `Product` object. It does not become a `Book` constructor automatically when `Book` extends `Product`. `Book` must declare its own constructors.\n\n\n```java\npublic class Product {\n protected String name;\n protected double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n}\n\nclass Book extends Product {\n // Book does NOT automatically get a Book(String, double) constructor.\n // It must declare its own:\n public Book(String name, double price) {\n super(name, price);\n }\n}\n```\n\n\nThe `super(name, price)` line is how `Book`'s constructor hands the arguments off to `Product`'s constructor so the inherited fields get initialized. A subclass writes its own constructors and uses `super(...)` to delegate to the parent.\n\n**3. Static initializers.** A class can have a `static { ... }` block that runs once when the class is loaded. These blocks are not inherited. Each class has its own static initializers, and the parent's runs when the parent is loaded, not when the subclass is loaded extra. Same logic for instance initializer blocks.\n\nA snippet showing what doesn't survive:\n\n\n```java\npublic class Product {\n private String secret = \"hidden\";\n\n public Product() {\n }\n\n private void audit() {\n System.out.println(\"auditing\");\n }\n}\n\nclass Book extends Product {\n public Book() {\n super();\n // this.secret = \"x\"; // compile error: secret has private access in Product\n // audit(); // compile error: audit() has private access in Product\n }\n}\n```\n\n\nThe two commented lines would each cause a compile error like:\n\n\n```shell\nerror: secret has private access in Product\n this.secret = \"x\";\n ^\n```\n\n\nThe fix is either to change the modifier on the parent or to expose the value through a `protected` accessor. If `Product` has a `protected String getSecret()` method, `Book` can call `getSecret()` freely.\n\n---\n\n# The `protected` Modifier and Inheritance\n\nOf the four access levels, `protected` is the one most tied to inheritance. It exists almost entirely for the parent-child case: \"I want subclasses to see this, but not arbitrary outside code.\"\n\nThe full rule for `protected` is:\n\n- A `protected` member is visible to any code in the same package as the declaring class.\n- A `protected` member is also visible to subclasses, even when those subclasses live in a different package, but only when accessed through a reference of the subclass type.\n\nThat second clause is the cross-package extension. It's the reason `protected` is different from package-private. Package-private stops at the package boundary. `protected` crosses the package boundary, but only along inheritance edges.\n\nA typical use:\n\n\n```java\npublic class Product {\n protected String name;\n protected double price;\n\n public Product(String name, double price) {\n this.name = name;\n this.price = price;\n }\n\n protected double calculateTax() {\n return price * 0.07;\n }\n}\n\nclass Book extends Product {\n private int pageCount;\n\n public Book(String name, double price, int pageCount) {\n super(name, price);\n this.pageCount = pageCount;\n }\n\n public String summary() {\n // Direct access to inherited protected fields:\n return name + \" ($\" + price + \"), \" + pageCount + \" pages, tax $\" + calculateTax();\n }\n\n public static void main(String[] args) {\n Book javaBook = new Book(\"Effective Java\", 39.99, 416);\n System.out.println(javaBook.summary());\n }\n}\n```\n\n\nInside `Book.summary`, `name`, `price`, and `calculateTax()` are reached without any prefix. The compiler resolves them by walking up from `Book` to `Product`, where they're declared. Because they're `protected`, the subclass has full access, even if `Book` were in another package.\n\nThe trade-off with `protected` is honest: anything marked `protected` becomes part of the contract offered to subclasses. A future developer extending the class may rely on those fields and methods existing with the same signature. Changing `protected double price` to `protected BigDecimal price` later breaks every subclass that touched `price` directly. Many production codebases prefer `private` fields plus `protected` accessor methods for exactly this reason: the field's representation can change without breaking subclasses, as long as the accessor's signature holds.\n\nWhen in doubt, prefer the most restrictive access level that does the job. Use `private` for state that's purely internal. Use `protected` when subclasses actually need to reach in. Use `public` only for the outward-facing API.\n\n---\n\n# Blocking Inheritance with `final`\n\nThe `final` keyword can stop inheritance in two ways: on a whole class, or on individual methods. Here we focus on what it does for `extends`.\n\n### `final` Class: Cannot Be Extended\n\nA class declared `final` cannot appear on the right of `extends`. Any attempt to subclass it fails at compile time.\n\n\n```java\npublic final class GiftCard {\n private final String code;\n private final double amount;\n\n public GiftCard(String code, double amount) {\n this.code = code;\n this.amount = amount;\n }\n\n public String getCode() {\n return code;\n }\n\n public double getAmount() {\n return amount;\n }\n\n public static void main(String[] args) {\n GiftCard card = new GiftCard(\"GC-1001\", 50.0);\n System.out.println(card.getCode() + \" worth $\" + card.getAmount());\n }\n}\n```\n\n\nTrying to extend it fails:\n\n\n```java\nclass SpecialGiftCard extends GiftCard { // compile error\n public SpecialGiftCard(String code, double amount) {\n super(code, amount);\n }\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: cannot inherit from final GiftCard\nclass SpecialGiftCard extends GiftCard {\n ^\n```\n\n\nThe fix is to drop the `final` modifier from `GiftCard`, or to model `SpecialGiftCard` differently (for example, by having it contain a `GiftCard` field instead of extending it). The technique of holding an instance of another class as a field is called **composition**.\n\n`final` on classes shows up in the standard library frequently. `String` is `final`. So are all the numeric wrapper classes (`Integer`, `Long`, `Double`, etc.), the modern date-time classes (`LocalDate`, `LocalTime`, `LocalDateTime`, `Instant`), and `UUID`. Each of these is meant to be immutable, and immutability is fragile if subclasses can override behavior. If `MyString extends String` were legal, a malicious subclass could change what `equals` returns between two calls, or have a `length()` that returns different values on different invocations. `String` being `final` removes that entire class of bugs by construction.\n\n### `final` Method: Cannot Be Overridden\n\nA method declared `final` can still be inherited. The difference is that subclasses cannot replace it with a new implementation. For this lesson:\n\n- A subclass that extends a class with a `final` method can still call that method.\n- A subclass that tries to declare a method with the same name and parameter list as a `final` parent method fails to compile.\n\n\n```java\npublic class Product {\n public final String getDescription() {\n return \"Product: standard\";\n }\n}\n\nclass Book extends Product {\n // Inheriting getDescription() is fine.\n // Trying to redeclare it would fail:\n // public String getDescription() { return \"Product: book\"; } // compile error\n}\n```\n\n\nIf the commented-out line were uncommented, the compiler would say `getDescription() in Book cannot override getDescription() in Product; overridden method is final`.\n\n`final class` blocks inheritance entirely, and `final` on a method blocks one specific kind of change (replacement) while still letting the method be inherited and called.\n\n---\n\n# A Complete Example: `Product` and `Book`\n\nA runnable file with `Product` as the superclass and `Book` as the subclass demonstrates inherited fields, inherited methods, and new members added by the subclass.\n\n\n```java\npublic class Product {\n protected String productId;\n protected String name;\n protected double price;\n protected int stock;\n\n public Product(String productId, String name, double price, int stock) {\n this.productId = productId;\n this.name = name;\n this.price = price;\n this.stock = stock;\n }\n\n public boolean isInStock() {\n return stock > 0;\n }\n\n public double calculateTotal(int quantity) {\n return price * quantity;\n }\n\n public String describe() {\n return productId + \" \" + name + \" ($\" + price + \")\";\n }\n}\n\nclass Book extends Product {\n private String author;\n private int pageCount;\n\n public Book(String productId, String name, double price, int stock,\n String author, int pageCount) {\n super(productId, name, price, stock);\n this.author = author;\n this.pageCount = pageCount;\n }\n\n public String getAuthor() {\n return author;\n }\n\n public int getPageCount() {\n return pageCount;\n }\n\n public String bookSummary() {\n return name + \" by \" + author + \", \" + pageCount + \" pages, $\" + price;\n }\n\n public static void main(String[] args) {\n Book javaBook = new Book(\n \"B-1001\",\n \"Effective Java\",\n 39.99,\n 12,\n \"Joshua Bloch\",\n 416\n );\n\n // Methods inherited from Product:\n System.out.println(javaBook.describe());\n System.out.println(\"In stock? \" + javaBook.isInStock());\n System.out.println(\"Total for 3: $\" + javaBook.calculateTotal(3));\n\n // Methods added by Book:\n System.out.println(\"Author: \" + javaBook.getAuthor());\n System.out.println(\"Pages: \" + javaBook.getPageCount());\n System.out.println(javaBook.bookSummary());\n }\n}\n```\n\n\nThree observations.\n\nFirst, `Book` defines no `productId`, `name`, `price`, or `stock` fields of its own. It inherits all four from `Product`. They're `protected`, so `Book.bookSummary()` can read `name` and `price` directly without going through accessor methods.\n\nSecond, `Book` inherits three methods: `isInStock`, `calculateTotal`, and `describe`. The `main` method calls all three on a `Book` instance, and they work exactly as if they had been declared on `Book`. They weren't, of course; the runtime walks up to `Product` and runs the methods defined there.\n\nThird, `Book` adds two private fields (`author`, `pageCount`), two new public getters, and one new method (`bookSummary`). The new members are completely additive. Nothing in `Product` had to change to support them.\n\nThe class hierarchy as a diagram:\n\n\n```mermaid\nflowchart TD\n Obj[Object
java.lang.Object]:::teal\n Prod[Product
productId, name, price, stock
isInStock, calculateTotal, describe]:::cyan\n Book[Book
author, pageCount
getAuthor, getPageCount, bookSummary]:::orange\n\n Book -->|extends| Prod\n Prod -->|extends implicitly| Obj\n\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nEvery class that doesn't write `extends` explicitly extends `Object`. So a `Book` is a `Product`, and a `Product` is an `Object`. `Object` brings methods like `equals`, `hashCode`, `toString`, and friends to every class.\n\nNote the `super(productId, name, price, stock)` inside `Book`'s constructor. This is how the four parent fields get initialized when a `Book` is built. Without that line, the compiler would either insert an implicit `super()` (which would fail because `Product` has no no-arg constructor) or report an error. When the parent has fields, the subclass's constructor needs to pass values to a parent constructor that knows how to set them.\n\n---\n\n# Adding New Fields and Methods in the Subclass\n\nA subclass starts with everything the parent makes accessible, then adds. Anything declared inside the subclass is purely the subclass's own. The parent has no idea those members exist; only the subclass and its descendants can see them.\n\nTwo more subclasses of `Product` show how the same parent supports very different children.\n\n### `Electronics`: Adding Fields and a Method\n\n\n```java\npublic class Product {\n protected String productId;\n protected String name;\n protected double price;\n\n public Product(String productId, String name, double price) {\n this.productId = productId;\n this.name = name;\n this.price = price;\n }\n\n public double calculateTotal(int quantity) {\n return price * quantity;\n }\n}\n\nclass Electronics extends Product {\n private int warrantyMonths;\n private double powerWatts;\n\n public Electronics(String productId, String name, double price,\n int warrantyMonths, double powerWatts) {\n super(productId, name, price);\n this.warrantyMonths = warrantyMonths;\n this.powerWatts = powerWatts;\n }\n\n public int getWarrantyMonths() {\n return warrantyMonths;\n }\n\n public double estimatedYearlyEnergyCost(double pricePerKwh, double hoursPerDay) {\n double dailyKwh = (powerWatts / 1000.0) * hoursPerDay;\n return dailyKwh * 365 * pricePerKwh;\n }\n\n public static void main(String[] args) {\n Electronics monitor = new Electronics(\"E-1001\", \"27-inch Monitor\", 249.99, 24, 35.0);\n\n // Inherited:\n System.out.println(\"Total for 2: $\" + monitor.calculateTotal(2));\n\n // New on Electronics:\n System.out.println(\"Warranty: \" + monitor.getWarrantyMonths() + \" months\");\n System.out.println(\"Yearly energy cost: $\" + monitor.estimatedYearlyEnergyCost(0.15, 8));\n }\n}\n```\n\n\n`Electronics` reuses everything `Product` offers and tacks on two fields, one getter, and one calculation method. The energy-cost method uses both an `Electronics`-only field (`powerWatts`) and would have access to inherited fields too if it needed them. No code change to `Product` was required.\n\n### `DigitalProduct`: Different Fields, Same Parent\n\n\n```java\nclass DigitalProduct extends Product {\n private double fileSizeMb;\n private String downloadUrl;\n\n public DigitalProduct(String productId, String name, double price,\n double fileSizeMb, String downloadUrl) {\n super(productId, name, price);\n this.fileSizeMb = fileSizeMb;\n this.downloadUrl = downloadUrl;\n }\n\n public double getFileSizeMb() {\n return fileSizeMb;\n }\n\n public String getDownloadUrl() {\n return downloadUrl;\n }\n\n public static void main(String[] args) {\n DigitalProduct ebook = new DigitalProduct(\n \"D-1001\",\n \"Java Guide eBook\",\n 14.99,\n 3.5,\n \"https://shop.example.com/downloads/java-guide.pdf\"\n );\n\n System.out.println(\"Total for 1: $\" + ebook.calculateTotal(1));\n System.out.println(\"Size: \" + ebook.getFileSizeMb() + \" MB\");\n System.out.println(\"Download: \" + ebook.getDownloadUrl());\n }\n}\n```\n\n\n`Electronics` and `DigitalProduct` share `Product` as a parent but have nothing in common with each other. Each just adds the fields and methods that make sense for what it represents. There's no requirement that subclasses look like one another. The contract is between each child and the parent, not between the children themselves.\n\nA subclass can also access the parent's `protected` and `public` members from inside its new methods. For example, `Electronics` can compute its yearly energy cost as a fraction of the product's price using `this.price`:\n\n\n```java\npublic double energyCostAsFractionOfPrice(double pricePerKwh, double hoursPerDay) {\n return estimatedYearlyEnergyCost(pricePerKwh, hoursPerDay) / price;\n}\n```\n\n\n`price` here is the `protected` field inherited from `Product`. No prefix needed; the compiler walks up the chain to find it.\n\nWhat a subclass cannot do:\n\n- Reach into the parent's `private` members.\n- Reach into another subclass's members. `Electronics` cannot see `DigitalProduct.fileSizeMb`, even though both extend `Product`. Sibling subclasses are unrelated to each other.\n- Override `final` methods.\n- Add a method with the same signature as a parent method without following the override rules. For now, give new methods different names from anything in the parent.\n\nWhen the parent's version of something the child has its own field or method for is needed, the `super` keyword is the tool. For this lesson, stay clear of name collisions between parent and child members.\n\n---\n\n# Inheritance Is Always a Promise\n\nOne last point before the wrap-up. Writing `class Book extends Product` is not just code reuse, it's a statement about what `Book` is. The promise is: every `Book` is a `Product`. Any place that accepts a `Product` should be willing to accept a `Book`. This is sometimes called the Liskov Substitution Principle. The practical version: if extending a class only grabs a couple of methods, and the child isn't really an IS-A version of the parent, composition is the better fit. Hold a reference to the parent class as a field and delegate to it.\n\nThis guidance applies even in this small example. Making `Customer extends Product` because both have a `name` field misleads the compiler and every reader. A customer isn't a product. Composition (a `Customer` has a `name`, declared on its own) is the honest design.\n\nWhen using `extends`, ask: is the child a more-specific kind of the parent?","pageType":"java"}

extends Keyword

Get Premium