{"title":"Inheritance Basics","description":"","content":"Earlier lessons built individual classes from scratch: `Product`, `Customer`, `Order`, `Review`. Each one stood on its own, with its own fields and methods. Real catalogs don't work that way. A book, a laptop, and a t-shirt are all products that share a name, a price, and a stock count, but a book also has an author, a laptop has a warranty, and a t-shirt has a size. Inheritance is Java's mechanism for saying \"this thing is a specialized kind of that thing,\" so the shared parts live in one place and the specialized parts live where they belong. This lesson covers what inheritance is, when it fits, and when something else fits better.\n\n---\n\n# Why Inheritance Exists\n\nConsider what happens without inheritance. Suppose the store sells two product types, books and electronics. They share the basic product fields, but each has extra information.\n\n\n```java\npublic class Book {\n public String name;\n public double price;\n public int stockCount;\n public String author;\n public int pages;\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price + \" (\" + stockCount + \" in stock)\");\n }\n}\n```\n\n\n\n```java\npublic class Electronics {\n public String name;\n public double price;\n public int stockCount;\n public int warrantyMonths;\n public String brand;\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price + \" (\" + stockCount + \" in stock)\");\n }\n}\n```\n\n\nThe two classes side by side show three fields and one method are copy-pasted. Adding `category` to every product later would require changes in two places. A bug fix in `printSummary` would need to happen twice. Add a third type (clothing, kitchen, toys) and the duplication grows linearly. The two classes also have no shared type, so a method that accepts \"any product\" can't be written cleanly.\n\nThe duplication is the symptom. The real problem is that the type system hasn't been told what is true: a book and an electronics item are both products. The specialized things are described without naming the general thing they have in common.\n\nThe same model with a shared `Product` class on top:\n\n\n```java\npublic class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price + \" (\" + stockCount + \" in stock)\");\n }\n}\n```\n\n\n\n```java\npublic class Book extends Product {\n public String author;\n public int pages;\n}\n```\n\n\n\n```java\npublic class Electronics extends Product {\n public int warrantyMonths;\n public String brand;\n}\n```\n\n\nThe shared three fields and the shared method now live on `Product`. `Book` and `Electronics` declare only what's different about them. The `extends` keyword tells Java that a `Book` is a specialized kind of `Product` and an `Electronics` item is too. Both classes pick up `name`, `price`, `stockCount`, and `printSummary` automatically.\n\nA small driver:\n\n\n```java\npublic class CatalogDemo {\n public static void main(String[] args) {\n Book novel = new Book();\n novel.name = \"Effective Java\";\n novel.price = 45.99;\n novel.stockCount = 7;\n novel.author = \"Joshua Bloch\";\n novel.pages = 416;\n\n Electronics laptop = new Electronics();\n laptop.name = \"Aluminum Laptop\";\n laptop.price = 1299.00;\n laptop.stockCount = 3;\n laptop.brand = \"Acme\";\n laptop.warrantyMonths = 24;\n\n novel.printSummary();\n laptop.printSummary();\n }\n}\n```\n\n\nNeither `Book` nor `Electronics` declares `printSummary`, and neither declares `name`, `price`, or `stockCount`. They inherit all of it from `Product`. The shape: shared parts in one class, specialized parts in another.\n\nInheritance provides two things at once. First, **code reuse**: write the common behavior once, use it everywhere. Second, **a shared type**: a `Book` and an `Electronics` are now both also `Product`s in the eyes of the type system, which allows methods that work on any product without caring what specific kind it is.\n\n---\n\n# The IS-A Relationship\n\nInheritance models a single, specific idea: an **IS-A** relationship. A `Book` is a `Product`. An `Electronics` item is a `Product`. The child is a more specific version of the parent, with everything the parent has plus possibly more.\n\nIf \"a Book is a Product\" sounds true when said aloud, inheritance is at least a candidate. If the sentence sounds wrong, inheritance isn't appropriate, no matter how convenient the code reuse looks.\n\nThe IS-A test is strict on purpose. It's not \"a Book and a Product have some fields in common.\" It's \"a Book is, in every meaningful sense, a kind of Product.\" Anywhere code expects a `Product`, a `Book` should work and the program should still make sense.\n\nConcretely: a method like\n\n\n```java\npublic static double restockCost(Product p, int unitsToBuy) {\n return p.price * unitsToBuy;\n}\n```\n\n\nworks on a `Book` because a `Book` is a `Product` and has a `price`. It works on an `Electronics` for the same reason. Passing in something that wasn't really a kind of `Product` would either fail to compile or misbehave at runtime.\n\nThe claim here is not \"a Book is composed of a Product\" or \"a Book uses a Product internally.\" It is stronger: at the type level, a Book really is a Product. That's what gives the parent's methods meaning when called on a child.\n\nThe terms for the two sides of this relationship show up in every Java textbook and interview, so it's worth pinning them down once.\n\n\n| Term used for parent | Term used for child | Notes |\n| --- | --- | --- |\n| Superclass | Subclass | Most common in Java docs and books |\n| Parent class | Child class | Common in tutorials and casual conversation |\n| Base class | Derived class | Common in C++ background; used less in Java |\n\n\nThis lesson uses **superclass** and **subclass** because that's what the Java Language Specification uses and what appears in compiler messages and the official documentation. The other terms mean the same thing.\n\nIn the running example, `Product` is the superclass and `Book` is a subclass of `Product`. `Book extends Product` reads as \"Book is a subclass of Product\" or \"Book extends from Product.\"\n\n\n```mermaid\nflowchart TD\n Product[\"Product (superclass)
name, price, stockCount
printSummary()\"]:::cyan\n Book[\"Book (subclass)
author, pages\"]:::orange\n Electronics[\"Electronics (subclass)
brand, warrantyMonths\"]:::orange\n\n Book --> Product\n Electronics --> Product\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe arrows point from subclass to superclass, which is the standard direction in UML class diagrams. The reason for that convention is that the child knows about the parent (it has to, in order to extend it), but the parent doesn't know about its children. `Product` was a complete class long before we wrote `Book`, and it would still compile if `Book` disappeared.\n\n---\n\n# Inheritance vs Composition (HAS-A)\n\nThere's a different way two classes can relate that beginners often confuse with inheritance. It's called **composition**, and it expresses a **HAS-A** relationship instead of an IS-A relationship.\n\nComposition means one class holds another class as a field. The container \"has\" the contained thing as a part. It doesn't claim to be a specialized version of it.\n\nThe clearest e-commerce example is a shopping cart and the items in it. A `Cart` is not a kind of `CartItem`. A cart is a thing that holds cart items. So:\n\n\n```java\npublic class CartItem {\n public String productName;\n public double pricePerUnit;\n public int quantity;\n}\n```\n\n\n\n```java\npublic class Cart {\n public String customerName;\n public CartItem[] items;\n public int itemCount;\n\n public double total() {\n double sum = 0;\n for (int i = 0; i < itemCount; i++) {\n sum = sum + items[i].pricePerUnit * items[i].quantity;\n }\n return sum;\n }\n}\n```\n\n\nThe `Cart` *has* items. It doesn't extend `CartItem`. The relationship is \"cart has cart items,\" and the field `items` makes that real.\n\nCompare that with the earlier `Book extends Product`. A book *is* a product. The relationship is identity-based, not container-based. There's no \"the book holds a product inside it.\" A book just is a product, with a few extra fields tacked on.\n\nA side-by-side comparison:\n\n\n```java\n// IS-A: inheritance. A Book is a Product.\npublic class Book extends Product {\n public String author;\n public int pages;\n}\n```\n\n\n\n```java\n// HAS-A: composition. An Order has a Customer and a list of items.\npublic class Order {\n public int orderId;\n public Customer customer;\n public CartItem[] items;\n public int itemCount;\n public boolean isPaid;\n}\n```\n\n\n`Order` doesn't extend `Customer`, because an order isn't a kind of customer. An order has a customer attached to it. Likewise, an order has line items, but it isn't a kind of item.\n\nA runnable example of the order/customer relationship:\n\n\n```java\npublic class Customer {\n public String name;\n public String email;\n}\n\npublic class Order {\n public int orderId;\n public Customer customer;\n public double total;\n\n public void printReceipt() {\n System.out.println(\"Order #\" + orderId);\n System.out.println(\"For: \" + customer.name + \" <\" + customer.email + \">\");\n System.out.println(\"Total: $\" + total);\n }\n}\n\npublic class OrderDemo {\n public static void main(String[] args) {\n Customer alice = new Customer();\n alice.name = \"Alice\";\n alice.email = \"alice@example.com\";\n\n Order order = new Order();\n order.orderId = 1042;\n order.customer = alice;\n order.total = 89.99;\n\n order.printReceipt();\n }\n}\n```\n\n\nThe `Order` reaches into its `customer` field with the dot operator to get the name and email. It doesn't inherit a name or an email, because an order isn't a kind of customer. It just keeps a reference to one.\n\nThe two relationships look superficially similar in code: in both cases, one class mentions another class. The difference is in how it mentions it.\n\n\n| Feature | Inheritance (IS-A) | Composition (HAS-A) |\n| --- | --- | --- |\n| Syntax | `class Sub extends Super` | `class Outer { Inner field; }` |\n| Reads as | \"Sub is a Super\" | \"Outer has an Inner\" |\n| Inherits members? | Yes, automatically | No, you access via the field |\n| Type compatibility? | A `Sub` is also a `Super` | An `Outer` is not an `Inner` |\n| Lifetime tied? | Yes, members come with the object | The inner can exist independently |\n\n\nOne mistake to avoid: choosing inheritance because it looks like less typing. If `Order extends Customer` happens to compile and provides a `name` field automatically, that's not a reason to do it. An order is not a kind of customer. Misrepresenting the relationship will hurt later, especially once polymorphism starts treating every `Order` as if it could stand in for a `Customer`.\n\n---\n\n# Java's Single Inheritance Rule\n\nJava has a strict rule about how many superclasses a class can have: **one, and only one**. A class can extend exactly one other class. Writing `class Book extends Product, Reviewable` is a compile error.\n\n\n```java\npublic class Reviewable {\n public int averageRating;\n public int reviewCount;\n}\n\n// This does NOT compile.\npublic class Book extends Product, Reviewable {\n public String author;\n}\n```\n\n\nThe compiler rejects the comma. Java was designed this way on purpose, and the design choice has a name: **single inheritance of implementation**.\n\nWhy the restriction? When a class inherits from multiple parents and those parents disagree, things get ugly fast. If both `Product` and `Reviewable` defined a method called `printSummary` with different bodies, which one does `Book` use? If both defined a field called `tag`, which copy lives on a `Book` instance? The classic name for this mess is the **diamond problem**: when two parents share a common grandparent, and a child inherits from both, the layout of the shared grandparent's state gets ambiguous. Languages that allow multiple inheritance of state (C++ is the famous example) have to add rules and keywords to disambiguate, and those rules are easy to get wrong.\n\nJava sidesteps the whole problem by forbidding multiple inheritance of classes. The compiler doesn't have to choose between `Product.printSummary` and `Reviewable.printSummary`, because no class can have both as parents.\n\nThat doesn't mean a class is stuck with exactly one set of behaviors. Java has a separate mechanism, **interfaces**, that allows a class to promise to support multiple sets of methods without inheriting their implementations. A class implements as many interfaces as needed:\n\n\n```java\npublic interface Reviewable {\n int averageRating();\n}\n\npublic interface Discountable {\n double discountedPrice();\n}\n\npublic class Book extends Product implements Reviewable, Discountable {\n // one superclass: Product\n // multiple interfaces: Reviewable, Discountable\n}\n```\n\n\nThe rule for this lesson: **a class extends at most one superclass**, no exceptions. When two parents seem needed, interfaces are usually the way out, or composition.\n\nThe single-inheritance limit applies only to classes. The picture below shows what's allowed and what isn't:\n\n\n```mermaid\nflowchart TD\n A[\"Book\"]:::cyan\n B[\"Product\"]:::green\n C[\"Reviewable\"]:::red\n D[\"Discountable\"]:::red\n\n A -->|extends OK| B\n A -.->|extends NOT OK| C\n A -.->|extends NOT OK| D\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nOne solid arrow up to one superclass. Multiple `extends` on a single class is forbidden. (The dotted lines show what's not allowed; they're not real Java syntax.)\n\nOne bit of vocabulary worth noting. Even though a class has only one *direct* superclass, it can have multiple *indirect* superclasses through a chain. The rule is about direct parents, not ancestors.\n\n---\n\n# Types of Inheritance\n\nEven with the one-superclass rule, inheritance can build interesting shapes. There are three patterns worth naming.\n\n### Single Inheritance\n\nThe simplest case. One subclass, one superclass, one arrow.\n\n\n```mermaid\nflowchart TD\n A[\"Book\"]:::orange\n B[\"Product\"]:::cyan\n\n A --> B\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nIn code:\n\n\n```java\npublic class Product {\n public String name;\n public double price;\n public int stockCount;\n}\n\npublic class Book extends Product {\n public String author;\n public int pages;\n}\n```\n\n\nThis is what the running example uses. `Book` extends `Product` and that's the whole hierarchy. Most useful inheritance trees are single inheritance trees with one or two levels.\n\n### Multilevel Inheritance\n\nA subclass becomes a superclass for a further subclass. The result is a chain: A extends B, B extends C.\n\n\n```mermaid\nflowchart TD\n A[\"Hardcover
(jacketColor)\"]:::green\n B[\"Book
(author, pages)\"]:::orange\n C[\"Product
(name, price, stockCount)\"]:::cyan\n\n A --> B\n B --> C\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```\n\n\nIn code:\n\n\n```java\npublic class Product {\n public String name;\n public double price;\n public int stockCount;\n}\n\npublic class Book extends Product {\n public String author;\n public int pages;\n}\n\npublic class Hardcover extends Book {\n public String jacketColor;\n}\n```\n\n\nA `Hardcover` is a `Book`, and through `Book` it's also a `Product`. So a `Hardcover` instance has `jacketColor`, `author`, `pages`, `name`, `price`, and `stockCount`, five inherited through the chain plus its own one.\n\nThe single-superclass rule is still honored. `Hardcover` extends exactly one class: `Book`. `Book` extends exactly one class: `Product`. No class has two direct parents. The chain is just a series of single-step relationships stacked together.\n\nA runnable example follows:\n\n\n```java\npublic class HardcoverDemo {\n public static void main(String[] args) {\n Hardcover atlas = new Hardcover();\n atlas.name = \"World Atlas\"; // from Product\n atlas.price = 79.99; // from Product\n atlas.stockCount = 4; // from Product\n atlas.author = \"National Geographic\"; // from Book\n atlas.pages = 320; // from Book\n atlas.jacketColor = \"navy\"; // from Hardcover\n\n System.out.println(atlas.name + \" by \" + atlas.author);\n System.out.println(\"Pages: \" + atlas.pages + \", Jacket: \" + atlas.jacketColor);\n System.out.println(\"Price: $\" + atlas.price);\n }\n}\n```\n\n\nA `Hardcover` object has six fields visible on it, picked up from three different classes in the chain. None of them are redeclared in `Hardcover`.\n\nMultilevel inheritance is legal, but use it sparingly. The deeper the chain, the harder it gets to figure out where a given field or method actually comes from when reading the code. Two levels (`Book extends Product`) is common and fine. Five levels deep is usually a sign that something has gone wrong with the design.\n\nEach level in a multilevel chain adds reading overhead. A reader of `Hardcover.printSummary()` has to walk up to `Book`, then up to `Product`, to find which implementation runs. Two levels is manageable. Beyond three, prefer composition or a flatter design.\n\n### Hierarchical Inheritance\n\nMultiple subclasses share one superclass. One parent, many children, each branching off independently.\n\n\n```mermaid\nflowchart TD\n P[\"Product
(name, price, stockCount)\"]:::cyan\n B[\"Book
(author, pages)\"]:::orange\n E[\"Electronics
(brand, warrantyMonths)\"]:::orange\n C[\"Clothing
(size, color)\"]:::orange\n\n B --> P\n E --> P\n C --> P\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nIn code:\n\n\n```java\npublic class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price + \" (\" + stockCount + \" in stock)\");\n }\n}\n\npublic class Book extends Product {\n public String author;\n public int pages;\n}\n\npublic class Electronics extends Product {\n public int warrantyMonths;\n public String brand;\n}\n\npublic class Clothing extends Product {\n public String size;\n public String color;\n}\n```\n\n\nThis is the shape that most product catalogs end up with. One `Product` superclass with the shared fields and methods, and a sibling class for each major category. The siblings don't know about each other; they just share a parent.\n\n\n```java\npublic class CatalogTour {\n public static void main(String[] args) {\n Book novel = new Book();\n novel.name = \"Effective Java\";\n novel.price = 45.99;\n novel.stockCount = 7;\n\n Electronics laptop = new Electronics();\n laptop.name = \"Aluminum Laptop\";\n laptop.price = 1299.00;\n laptop.stockCount = 3;\n\n Clothing tshirt = new Clothing();\n tshirt.name = \"Cotton T-Shirt\";\n tshirt.price = 19.99;\n tshirt.stockCount = 40;\n\n novel.printSummary();\n laptop.printSummary();\n tshirt.printSummary();\n }\n}\n```\n\n\nThree subclasses, one `printSummary` method, written once on `Product`. Each subclass adds its own fields without redoing the shared part.\n\nTwo other shapes sometimes appear in Java textbooks. **Multiple inheritance** (a class with two or more direct superclasses) and **hybrid inheritance** (a mix involving multiple inheritance). Java doesn't support either for classes, so this lesson does not cover them in depth. Interfaces fill the gap when a class needs to play more than one role.\n\nThe three shapes covered, summarized:\n\n\n| Type | Shape | Java supports it? | Example |\n| --- | --- | --- | --- |\n| Single | A → B | Yes | `Book extends Product` |\n| Multilevel | A → B → C | Yes | `Hardcover extends Book extends Product` |\n| Hierarchical | A → B, A → C, A → D | Yes | `Book`, `Electronics`, `Clothing` all extend `Product` |\n| Multiple | A and B → C | No (for classes) | Use interfaces instead |\n| Hybrid | Mix of multiple and other | No (for classes) | Use interfaces instead |\n\n\n---\n\n# When to Choose Inheritance\n\nInheritance is powerful, and it's used too often. A piece of advice has stood the test of time in the Java community, popularized by Joshua Bloch in *Effective Java*: **favor composition over inheritance**. Understanding the reasoning helps when deciding which tool to use.\n\nThe core problem with inheritance is that it's a strong commitment. When `Book extends Product`, `Book` is locked into whatever `Product` does, including changes that happen later. Add a method to `Product`, and every subclass picks it up automatically, whether or not the addition makes sense for that subclass. Change the behavior of a `Product` method, and every subclass behaves differently overnight. This is sometimes called the **fragile base class problem**.\n\nComposition doesn't have that problem. A class that holds another class as a field can choose exactly which methods to expose. If the inner class changes, only the outer class's wiring breaks, not the contract it exposes to its callers.\n\nA practical rule of thumb:\n\n\n| Question | If yes... | If no... |\n| --- | --- | --- |\n| Does `Sub` pass the IS-A test for `Super`? | Inheritance is a candidate | Use composition |\n| Could `Sub` swap in anywhere `Super` is used and still make sense? | Inheritance is a candidate | Use composition |\n| Should all changes to `Super` ripple into `Sub` automatically? | Inheritance is a candidate | Use composition |\n| Are `Super` and `Sub` under the same control (vs. third-party)? | Inheritance is safer | Inheritance is riskier |\n\n\nInheritance is appropriate when:\n\n- The IS-A relationship is real, not just a coincidence of shared fields. `Book` is a `Product` is real. `Order` is a `Customer` is not.\n- A shared type benefits generic code that operates on the supertype. A method that prices any product benefits from the shared `Product` type.\n- The superclass is stable and unlikely to change in ways that hurt the subclasses. Well-designed classes under the same ownership are usually fine. Random library classes are riskier.\n- Behavior in the superclass should be picked up by all subclasses without each one re-implementing it.\n\nComposition is appropriate when:\n\n- The relationship is \"has-a\" or \"uses-a\", not \"is-a\". A `Cart` has items. An `Order` has a `Customer`. A `Customer` has an `Address`.\n- Only a small slice of another class's behavior is needed. If `Book` would inherit fifteen methods from `Library` but only needs two, prefer composition.\n- The inner type may switch later. A field of type `PaymentMethod` can be reassigned to a different payment method. A superclass is fixed at compile time.\n- The classes belong to different conceptual layers. A persistence helper has no business being a parent of a domain object.\n\nA side-by-side comparison in code. Both versions give an `Order` access to a `Customer`'s data. One is wrong, one is right.\n\n\n```java\n// WRONG: Order is not a kind of Customer.\npublic class Order extends Customer {\n public int orderId;\n public double total;\n}\n```\n\n\n\n```java\n// RIGHT: Order has a Customer.\npublic class Order {\n public int orderId;\n public double total;\n public Customer customer;\n}\n```\n\n\nThe wrong version compiles. It even gives `Order` a working `name` and `email` automatically. That's the trap. The IS-A test fails (an order is not a kind of customer), and treating an `Order` as a `Customer` anywhere else in the program will lead to nonsense. The right version expresses the actual relationship: an order has a customer associated with it.\n\nA second example from the same domain. Consider modeling product reviews.\n\n\n```java\n// WRONG: A Review is not a kind of Product.\npublic class Review extends Product {\n public int rating;\n public String comment;\n}\n```\n\n\n\n```java\n// RIGHT: A Review is about a Product.\npublic class Review {\n public Product product;\n public int rating;\n public String comment;\n}\n```\n\n\nA review is a separate thing from the product it's about. The wrong version gives reviews a `price` and `stockCount`, neither of which makes sense on a review. The right version stores a reference to the product being reviewed.\n\nThe shorthand: **if the IS-A sentence requires squinting to sound right, use composition**. Inheritance fits when the relationship is so clear that no other phrasing works.\n\n\n```mermaid\nflowchart TD\n Q[\"Need to relate
two classes\"]:::cyan\n Test{\"Is the relationship
truly IS-A?\"}:::orange\n Yes[\"Use inheritance
class Sub extends Super\"]:::green\n No[\"Use composition
class Outer { Inner field; }\"]:::teal\n\n Q --> Test\n Test -->|Yes| Yes\n Test -->|No| No\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\nA decision in two questions. A \"no\" answer to the IS-A test routes to composition.\n\n---\n\n# Putting It Together\n\nThe three concepts (the IS-A relationship, the single-inheritance rule, and the composition alternative) fit together in one picture.\n\n\n```mermaid\nflowchart TD\n Product[\"Product
(superclass)\"]:::cyan\n\n Book[\"Book
extends Product\"]:::orange\n Electronics[\"Electronics
extends Product\"]:::orange\n Clothing[\"Clothing
extends Product\"]:::orange\n\n Hardcover[\"Hardcover
extends Book\"]:::green\n\n Customer[\"Customer\"]:::teal\n Cart[\"Cart
has CartItem[]\"]:::teal\n Order[\"Order
has Customer
has CartItem[]\"]:::teal\n Review[\"Review
has Product\"]:::teal\n\n Book --> Product\n Electronics --> Product\n Clothing --> Product\n Hardcover --> Book\n\n Order -.has.-> Customer\n Cart -.has.-> Product\n Review -.has.-> Product\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\nSolid arrows are `extends`, the inheritance arrows. They model IS-A: a `Book` is a `Product`, a `Hardcover` is a `Book`. Dotted arrows are HAS-A, the composition relationships: an `Order` has a `Customer`, a `Cart` has products, a `Review` is about a product. The two kinds of edges represent two different kinds of relationship and they aren't interchangeable.\n\n`Product` here sits at the top of a small hierarchical inheritance tree, and `Hardcover extends Book extends Product` adds a multilevel branch on one side. None of the children have more than one direct parent, which is exactly what Java's single-inheritance rule requires. The HAS-A relationships off to the side don't show up in the class hierarchy at all; they're stored as fields, not encoded in the type system.\n\nThe pattern: inheritance is for *what something is*, composition is for *what something has*. They are not in competition. A real codebase uses both, often inside the same class.","pageType":"java"}

Inheritance Basics

Get Premium