{"title":"Abstract Classes","description":"","content":"In the inheritance section we built inheritance hierarchies like `Book extends Product` where every class in the tree could be created with `new`. That works when every class in the hierarchy represents a real, concrete thing. It stops working when the superclass exists only to share state and behavior, never to be instantiated on its own. An abstract class is Java's way of declaring \"this class is a building block for subclasses, not a finished thing you should ever create directly.\" This lesson covers what abstract classes are, what they can and can't do, and when to use one.\n\n---\n\n# Why Abstraction Exists\n\nLook at the hierarchy we ended the Inheritance section with: `Product` at the top, with `Book`, `Electronics`, and `Clothing` extending it. Every product in the store is one of those three specific kinds. So what should this line do?\n\n\n```java\nProduct p = new Product();\np.name = \"Mystery Item\";\np.price = 19.99;\n```\n\n\nIt compiles. It runs. But what kind of product did we just create? Not a book, not an electronics item, not a piece of clothing. Just a bare `Product`. The store's catalog has no shelf for it. The checkout flow doesn't know how to display it. It's a `Product` in the type system and nothing in the real world.\n\nThe `Product` class was meant to be a shared base. It exists so its three subclasses can pull `name`, `price`, and `stockCount` from one place. It was never meant to be a thing in its own right. Java had no way to enforce that. The class compiled, `new Product()` worked, and a careful design relied entirely on programmer discipline.\n\nThat's the gap abstraction closes. Sometimes a class exists to define a shape that subclasses fill in. The class collects the common state, provides the common behavior, and explicitly forbids anyone from creating instances of itself. The `abstract` keyword is how Java lets you say that out loud.\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n}\n```\n\n\nOne word, big consequence. `Product` still has fields. It still compiles. Subclasses can still extend it. The only thing that changes is that `new Product()` is no longer legal. Any attempt to create a bare `Product` is now caught at compile time, not left as an error-prone pitfall for the next developer.\n\nAbstraction is about modeling intent. The IS-A relationship from inheritance tells the compiler \"a `Book` is a kind of `Product`.\" Marking `Product` as abstract tells the compiler \"there's no such thing as a bare `Product`; every `Product` is some specific kind.\" Both statements together describe the catalog accurately.\n\n\n```mermaid\nflowchart TD\n Product[\"Product (abstract)
name, price, stockCount
cannot be instantiated\"]:::cyan\n Book[\"Book (concrete)
author, pages\"]:::orange\n Electronics[\"Electronics (concrete)
brand, warrantyMonths\"]:::orange\n Clothing[\"Clothing (concrete)
size, color\"]:::orange\n\n Book --> Product\n Electronics --> Product\n Clothing --> Product\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe diagram looks like the hierarchical inheritance trees from before, with one important difference: the root is marked abstract. The leaves are concrete. You can call `new` on the orange boxes. You can't call `new` on the cyan one.\n\nThere's a second motivation. Abstract classes also let you define a **contract**: a set of methods that every subclass must provide, with the actual implementation left to each subclass. For this lesson, the focus stays on the class-level decision: marking a class abstract so it can't be created on its own.\n\n---\n\n# The `abstract` Keyword on a Class\n\nThe mechanics are small. Put `abstract` between the access modifier and the `class` keyword in a class declaration:\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n}\n```\n\n\nThat's the whole syntax. `abstract` is a modifier on the class. It doesn't change the body. The fields, the constructors, the methods, all of them look exactly like they did in a regular class. The only difference is the one extra word in the header.\n\n`abstract` is a reserved keyword. You can't use it as a variable or method name. Its only job on a class declaration is to mark the class as \"not directly instantiable.\"\n\nA few rules about where `abstract` is allowed on a class:\n\n\n| Combination | Legal? | Why |\n| --- | --- | --- |\n| `public abstract class Product` | Yes | Standard form |\n| `abstract class Product` | Yes | Package-private abstract class |\n| `abstract public class Product` | Yes | Order of modifiers doesn't matter |\n| `public abstract final class Product` | No | `abstract` and `final` contradict each other |\n| `abstract static class Product` | Only as a nested class | Top-level classes can't be `static` |\n\n\nThe `final` rule deserves attention. A `final` class can't be extended. An `abstract` class must be extended (otherwise it can never be used at all). Combining them would describe a class that is impossible to use, so the compiler rejects it outright:\n\n\n```java\npublic abstract final class Product { // compile error\n public String name;\n}\n```\n\n\nThe compiler error reads `illegal combination of modifiers: abstract and final`. The fix is to drop one or the other based on what you actually want. If you want subclasses, drop `final`. If you don't want subclasses, drop `abstract` and accept that the class is concrete.\n\nBeyond classes, the `abstract` keyword also applies to methods, and that's where most of the interesting behavior lives. Methods can be marked abstract to declare that subclasses must provide an implementation.\n\n---\n\n# You Cannot Instantiate an Abstract Class\n\nThe single biggest behavioral change is that `new` doesn't work on an abstract class. The line that compiled before now fails:\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n}\n\npublic class Mistake {\n public static void main(String[] args) {\n Product p = new Product(); // compile error\n p.name = \"Mystery Item\";\n }\n}\n```\n\n\nThe compiler emits:\n\n\n```shell\nMistake.java:3: error: Product is abstract; cannot be instantiated\n Product p = new Product();\n ^\n1 error\n```\n\n\nThat's a hard stop. The error happens at compile time, not at runtime. No JVM is launched, no class is loaded, no constructor is called. The compiler sees the `abstract` modifier and refuses to translate `new Product()` into bytecode. There's no flag, no trick, no reflective workaround at the language level. If you want a `Product`, you have to create one of its concrete subclasses instead.\n\nThe fix is to instantiate a subclass:\n\n\n```java\npublic abstract 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}\n\npublic class FixDemo {\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\n System.out.println(novel.name + \" by \" + novel.author + \" - $\" + novel.price);\n }\n}\n```\n\n\n`Book` is concrete, so `new Book()` is fine. The `Book` instance inherits the `name`, `price`, and `stockCount` fields from `Product`, even though `Product` itself can never be the type passed to `new`. The abstract class still does its job as a building block; it just can't be the final product.\n\nTwo attempts and what they do:\n\n\n```java\nProduct p1 = new Product() {}; // legal, but creates an anonymous subclass\nProduct p2 = (Product) new Object(); // ClassCastException at runtime\n```\n\n\nThe first line creates an anonymous subclass of `Product` and instantiates that subclass. It compiles because `new Product() {}` is shorthand for \"define an unnamed class that extends `Product`, and create an instance of it.\" The second line is plain wrong: you can't cast an arbitrary `Object` to `Product`, and the JVM throws `ClassCastException` the moment the cast runs. Neither attempt is a real way to create a bare `Product`, because there's no such thing as a bare `Product` once the class is abstract.\n\nThe \"abstract\" check happens at compile time. There's zero runtime overhead from marking a class abstract. The JVM doesn't pay anything to enforce it.\n\n---\n\n# What an Abstract Class Can Still Have\n\nA common misconception is that an abstract class is a \"stripped-down\" class with fewer features. It isn't. Other than the rule that you can't directly instantiate one, an abstract class can have everything a regular class can have.\n\n### Fields (Instance and Static)\n\nAbstract classes can hold state. Every kind of field a regular class supports is also legal here: instance fields, static fields, final fields, fields with any access modifier.\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n private static int totalProductsCreated = 0;\n\n public static final double SHIPPING_TAX_RATE = 0.05;\n}\n```\n\n\n`name`, `price`, and `stockCount` are normal instance fields. Every subclass instance gets its own copy. `totalProductsCreated` is a static field shared across all instances and subclasses. `SHIPPING_TAX_RATE` is a `public static final` constant available through `Product.SHIPPING_TAX_RATE` without ever creating a `Product` (which is good, because you can't).\n\nThe point: storing shared state on an abstract class is a perfectly normal thing to do. It's actually one of the main reasons to use an abstract class instead of an interface (interfaces traditionally don't hold instance state).\n\n### Constructors\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public Product(String name, double price, int stockCount) {\n this.name = name;\n this.price = price;\n this.stockCount = stockCount;\n }\n}\n```\n\n\nAn abstract class can have constructors. It can have multiple constructors. It can have constructors that take arguments. None of this changes the rule that you can't write `new Product(...)`.\n\nSo what are the constructors for, if you can never call `new` on the class? They're for subclasses to call. When a subclass extends `Product`, the subclass's constructor must call one of `Product`'s constructors (either explicitly with `super(...)` or implicitly via the no-arg default). The only change from regular constructor chaining is that the parent in the chain happens to be an abstract class.\n\nA concrete subclass shows it working:\n\n\n```java\npublic class Book extends Product {\n public String author;\n\n public Book(String name, double price, int stockCount, String author) {\n super(name, price, stockCount);\n this.author = author;\n }\n}\n\npublic class ConstructorDemo {\n public static void main(String[] args) {\n Book novel = new Book(\"Effective Java\", 45.99, 7, \"Joshua Bloch\");\n System.out.println(novel.name + \" by \" + novel.author + \" - $\" + novel.price);\n }\n}\n```\n\n\nThe `Book` constructor takes four arguments. The first three are passed up to `Product`'s constructor with `super(name, price, stockCount)`. That `super` call runs the `Product` constructor, which assigns the three shared fields. Then the `Book` constructor continues and sets `this.author`. The result is a fully initialized `Book` whose `Product` part was set up by a constructor on an abstract class.\n\nIf you forget the `super(...)` call when the parent has no no-arg constructor, the compiler complains:\n\n\n```shell\nBook.java: error: constructor Product in class Product cannot be applied to given types;\n required: String,double,int\n found: no arguments\n```\n\n\nThat's the same error you'd see with any superclass; the abstractness of the parent doesn't change how constructor chaining works.\n\n### Concrete Methods (with Real Bodies)\n\nMethods on an abstract class are concrete by default. Unless you specifically mark a method abstract, it has a body just like a method on any other class.\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public Product(String name, double price, int stockCount) {\n this.name = name;\n this.price = price;\n this.stockCount = stockCount;\n }\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price + \" (\" + stockCount + \" in stock)\");\n }\n\n public boolean isInStock() {\n return stockCount > 0;\n }\n\n public double priceAfterDiscount(double percentOff) {\n return price * (1 - percentOff / 100);\n }\n}\n```\n\n\nEvery subclass inherits these methods. They run on subclass instances and use the subclass's field values. Nothing about being inside an abstract class makes them special.\n\n\n```java\npublic class Book extends Product {\n public String author;\n\n public Book(String name, double price, int stockCount, String author) {\n super(name, price, stockCount);\n this.author = author;\n }\n}\n\npublic class MethodDemo {\n public static void main(String[] args) {\n Book novel = new Book(\"Effective Java\", 45.99, 7, \"Joshua Bloch\");\n novel.printSummary();\n System.out.println(\"In stock: \" + novel.isInStock());\n System.out.println(\"After 20% off: $\" + novel.priceAfterDiscount(20));\n }\n}\n```\n\n\nThree method calls, three implementations, all of them living on the abstract `Product` class. `Book` didn't have to override any of them to use them.\n\nThis is the **template** flavor of an abstract class: shared behavior in the parent, specialized differences in the children, and the type system enforcing that nobody can pretend to have just the shared part without picking a specific kind.\n\n### Static Methods\n\nAbstract classes can have static methods, and you call them on the class name like any other static method:\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public Product(String name, double price, int stockCount) {\n this.name = name;\n this.price = price;\n this.stockCount = stockCount;\n }\n\n public static double applyShippingTax(double subtotal) {\n return subtotal * 1.05;\n }\n}\n\npublic class StaticDemo {\n public static void main(String[] args) {\n double subtotal = 100.0;\n double withTax = Product.applyShippingTax(subtotal);\n System.out.println(\"Subtotal: $\" + subtotal);\n System.out.println(\"With shipping tax: $\" + withTax);\n }\n}\n```\n\n\n`Product.applyShippingTax` doesn't need a `Product` instance. It belongs to the class, not to any object. So even though you can't write `new Product()`, you can still call `Product.applyShippingTax(...)`. Static methods on abstract classes are perfectly normal. They behave like static methods anywhere else.\n\n### Access Modifiers, `final`, and Everything Else\n\nFields and methods on an abstract class can be `public`, `protected`, package-private, or `private`. They can be `final`. They can be `static`. The abstract modifier on the class doesn't disable or change any of the other modifiers you'd use on members.\n\nA summary table of what an abstract class can hold:\n\n\n| Feature | Abstract class supports it? |\n| --- | --- |\n| Instance fields | Yes |\n| Static fields | Yes |\n| `final` fields and constants | Yes |\n| Constructors (called by subclasses via `super`) | Yes |\n| Concrete instance methods | Yes |\n| Static methods | Yes |\n| Abstract methods | Yes |\n| `private`, `protected`, `public`, package-private members | Yes |\n| Being instantiated with `new` | **No** |\n\n\nThe only \"no\" in that table is the line that gives abstract classes their identity. Everything else looks like a regular class.\n\n---\n\n# Zero Abstract Methods is Still Valid\n\nAn abstract class is not required to have any abstract methods. The class-level `abstract` modifier alone is enough to make a class abstract.\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public Product(String name, double price, int stockCount) {\n this.name = name;\n this.price = price;\n this.stockCount = stockCount;\n }\n\n public void printSummary() {\n System.out.println(name + \" - $\" + price);\n }\n}\n```\n\n\nThis `Product` has fields, a constructor, and a concrete method. It declares no abstract methods at all. It is still a perfectly valid abstract class. It still can't be instantiated with `new`. The compiler enforces that based on the `abstract` keyword in the class header, not based on what's inside.\n\nWhy would you ever do this? The case is exactly the one we opened the lesson with. `Product` is a sensible shared base for `Book`, `Electronics`, and `Clothing`, and every subclass can fully use the inherited fields and methods without overriding anything. But there's no such thing as a \"bare product.\" Marking the class abstract documents and enforces the design intent.\n\nA subclass extending this kind of abstract class needs almost nothing extra:\n\n\n```java\npublic class Clothing extends Product {\n public String size;\n public String color;\n\n public Clothing(String name, double price, int stockCount, String size, String color) {\n super(name, price, stockCount);\n this.size = size;\n this.color = color;\n }\n}\n\npublic class ClothingDemo {\n public static void main(String[] args) {\n Clothing tshirt = new Clothing(\"Cotton T-Shirt\", 19.99, 40, \"M\", \"Blue\");\n tshirt.printSummary();\n System.out.println(\"Size: \" + tshirt.size + \", Color: \" + tshirt.color);\n }\n}\n```\n\n\n`Clothing` doesn't override `printSummary`. It doesn't need to. It just adds its own two fields and a constructor that chains up. The abstract `Product` provides the rest.\n\nThe \"zero abstract methods\" case is the cleanest illustration of the difference between an abstract class and an interface. An interface traditionally couldn't have instance state and required every method to be a contract. An abstract class with zero abstract methods is essentially a regular class with one extra restriction: no direct instantiation. That's a useful tool when shared state and shared method implementations are the whole point, and there's nothing for subclasses to \"fill in.\"\n\n\n> **INFO**\n>\n> **Design note:** If your abstract class has zero abstract methods and you can't think of a reason a subclass would ever want to override a method, the abstract-ness is doing one job and one job only: preventing direct instantiation. That's a legitimate reason to use it, but it's a narrower benefit than the template-method use case.\n\n\n---\n\n# When to Use an Abstract Class\n\nThe mechanics are simple. The harder question is when to actually use one. There are three recurring situations where an abstract class fits well.\n\n### Shared State Plus Shared Behavior That No Subclass Should Skip\n\nThis is the case our running example fits. `Product` holds three shared fields and a few shared methods. Every subclass needs them. None of them want to redefine them. Putting them on a regular `Product` class and using single inheritance works, except that \"regular\" leaves the door open to `new Product()`, which the design doesn't intend.\n\nMaking `Product` abstract is the difference between \"the design hopes nobody creates a bare `Product`\" and \"the design enforces that nobody can.\" The runtime cost is zero. The compile-time enforcement is real.\n\n### A Partial Implementation You Want Subclasses to Complete\n\nAn abstract class can supply most of a workflow and leave a few specific operations for subclasses to fill in. The parent provides the structure; the children provide the parts that vary.\n\nA quick sketch shows why an abstract class fits this case rather than a regular class. If every product needs to provide a \"display label\" for the cart, but books, electronics, and clothing format their labels differently: An abstract class lets `Product` declare \"every subclass must provide a `displayLabel()`\" without committing to one implementation. A regular class would have to either supply a default (which might be wrong for everyone) or leave the method off entirely (which makes generic code awkward). Abstract methods are how you express \"must be provided\" formally.\n\n### A Class That Is a Type but Not a Concrete Thing\n\nSometimes a class exists purely to give a name to a category of things, with subclasses for each specific kind. The category itself isn't a thing anyone would point to. \"Discount\" might be that kind of category. A `PercentageDiscount` is a thing. A `FixedAmountDiscount` is a thing. A bare \"discount\" without a specific kind is a label, not an object.\n\n\n```java\npublic abstract class Discount {\n public String code;\n public String description;\n\n public Discount(String code, String description) {\n this.code = code;\n this.description = description;\n }\n}\n\npublic class PercentageDiscount extends Discount {\n public double percent;\n\n public PercentageDiscount(String code, String description, double percent) {\n super(code, description);\n this.percent = percent;\n }\n\n public double applyTo(double price) {\n return price * (1 - percent / 100);\n }\n}\n\npublic class FixedAmountDiscount extends Discount {\n public double amount;\n\n public FixedAmountDiscount(String code, String description, double amount) {\n super(code, description);\n this.amount = amount;\n }\n\n public double applyTo(double price) {\n double result = price - amount;\n return result < 0 ? 0 : result;\n }\n}\n\npublic class DiscountDemo {\n public static void main(String[] args) {\n PercentageDiscount fifteenOff = new PercentageDiscount(\"SAVE15\", \"15% off\", 15);\n FixedAmountDiscount tenOff = new FixedAmountDiscount(\"FLAT10\", \"$10 off\", 10);\n\n System.out.println(fifteenOff.code + \": $100 becomes $\" + fifteenOff.applyTo(100));\n System.out.println(tenOff.code + \": $100 becomes $\" + tenOff.applyTo(100));\n }\n}\n```\n\n\n`Discount` exists so that anywhere the catalog says \"this product has a discount,\" the variable can be typed as `Discount` without committing to which kind. The two subclasses fill in the specific behavior. A bare `new Discount(...)` would represent a \"discount of unspecified type,\" which isn't something the system has any rule for. Marking `Discount` abstract documents that fact and prevents the construction.\n\nCompared with the earlier `Product` example, the shape is the same: an abstract parent, two or three concrete children, each child supplying its own specifics. The abstract class is the shared concept, and the subclasses are the shapes that concept actually takes in the program.\n\n\n```mermaid\nflowchart TD\n Discount[\"Discount (abstract)
code, description\"]:::cyan\n Percentage[\"PercentageDiscount
percent
applyTo(price)\"]:::orange\n Fixed[\"FixedAmountDiscount
amount
applyTo(price)\"]:::orange\n\n Percentage --> Discount\n Fixed --> Discount\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe pattern repeats. Two concrete leaves under one abstract root. Shared state on the root, specialized state and behavior on the leaves. The root is a category. The leaves are the actual things.\n\n### When an Abstract Class is the Wrong Tool\n\nThe flip side matters too. Two common cases where using an abstract class is a mistake:\n\n- **The class will actually be instantiated as itself.** If a bare `Product` is a real thing the program needs (say, \"miscellaneous item, no specific category\"), don't make it abstract. The abstract modifier means the class is incomplete on its own. If it isn't incomplete, leave it concrete.\n- **The relationship is HAS-A, not IS-A.** Abstract classes are still classes; they use the same inheritance hierarchy. If you'd reject inheritance for a relationship because it isn't IS-A, abstract classes don't change that calculus. An `Order` is not a kind of `Cart`, abstract or otherwise. The IS-A test still applies.\n\n---\n\n# Reference Variables of Abstract Type\n\nThe fact that you can't create an instance of an abstract class doesn't mean you can't have a variable of that type.\n\n\n```java\npublic abstract class Product {\n public String name;\n public 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\npublic class Book extends Product {\n public String author;\n\n public Book(String name, double price, String author) {\n super(name, price);\n this.author = author;\n }\n}\n\npublic class Electronics extends Product {\n public String brand;\n\n public Electronics(String name, double price, String brand) {\n super(name, price);\n this.brand = brand;\n }\n}\n\npublic class CatalogPrinter {\n public static void main(String[] args) {\n Product p1 = new Book(\"Effective Java\", 45.99, \"Joshua Bloch\");\n Product p2 = new Electronics(\"Aluminum Laptop\", 1299.00, \"Acme\");\n\n p1.printSummary();\n p2.printSummary();\n }\n}\n```\n\n\nThe variables `p1` and `p2` are both typed as `Product`. Their values are a `Book` instance and an `Electronics` instance. The line `Product p1 = new Book(...)` is the key: the right-hand side creates a concrete object, and the left-hand side stores the reference in a variable whose declared type is the abstract parent. The compiler accepts it because `Book` is a `Product` (IS-A holds), so the assignment is widening a reference, not creating an abstract instance.\n\nWhat you cannot do is the other direction:\n\n\n```java\nProduct p = new Product(\"Mystery\", 19.99); // compile error\n```\n\n\nThe declared type of the variable is fine. The `new Product(...)` is what fails. The type doesn't make the class instantiable; the class's own modifier does.\n\nThis pattern matters because it's the entire foundation of polymorphism over an inheritance hierarchy. You can write a method that operates on any product:\n\n\n```java\npublic class PriceCalculator {\n public static double subtotal(Product[] items) {\n double sum = 0;\n for (int i = 0; i < items.length; i++) {\n sum = sum + items[i].price;\n }\n return sum;\n }\n\n public static void main(String[] args) {\n Product[] cart = new Product[2];\n cart[0] = new Book(\"Effective Java\", 45.99, \"Joshua Bloch\");\n cart[1] = new Electronics(\"Aluminum Laptop\", 1299.00, \"Acme\");\n\n double total = subtotal(cart);\n System.out.println(\"Cart subtotal: $\" + total);\n }\n}\n```\n\n\nThe array `cart` is declared as `Product[]`. The actual objects in it are a `Book` and an `Electronics`. The `subtotal` method walks the array using the abstract `Product` type. It never creates a `Product`, it just receives references to subclass instances.\n\nThe diagram below captures the situation. The variable holds a `Product` reference. The reference points at a `Book` object. The object's actual class is `Book`, but the type the variable knows about is `Product`. You can call any method declared on `Product` through the variable. The method runs on the `Book` instance.\n\n\n```mermaid\nflowchart LR\n Var[\"Product p1
(reference variable)\"]:::cyan\n Heap[\"Book object
name = 'Effective Java'
price = 45.99
author = 'Joshua Bloch'\"]:::orange\n\n Var -->|points to| Heap\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe abstract class works fine as a type. It just doesn't work as a value all by itself.\n\nOne consequence: through the `Product` reference, you can only see what `Product` declares. The `author` field, declared on `Book`, is not visible through a `Product` reference even though the underlying object has one:\n\n\n```java\nProduct p1 = new Book(\"Effective Java\", 45.99, \"Joshua Bloch\");\nSystem.out.println(p1.author); // compile error: cannot find symbol\n```\n\n\nThe compiler looks at the declared type (`Product`), not the actual object. `Product` has no `author` field, so the access fails to compile. Getting at the `Book`-specific parts requires a cast. The rule that an abstract class makes a perfectly normal reference type doesn't lift the usual rules about what's visible through a parent reference.\n\n---\n\n# Common Compile Errors Around Abstract Classes\n\nThree compiler errors come up over and over when working with abstract classes.\n\n### \"ClassName is abstract; cannot be instantiated\"\n\nThe headline error.\n\n\n```java\npublic abstract class Product {\n public String name;\n}\n\npublic class Demo {\n public static void main(String[] args) {\n Product p = new Product(); // error\n }\n}\n```\n\n\nThe compiler message:\n\n\n```shell\nDemo.java:3: error: Product is abstract; cannot be instantiated\n Product p = new Product();\n ^\n```\n\n\nThe fix is to create a concrete subclass instead, or to remove the `abstract` modifier if you actually do want bare instances.\n\n### \"Illegal combination of modifiers: abstract and final\"\n\n\n```java\npublic abstract final class Product { // error\n public String name;\n}\n```\n\n\nThe compiler message:\n\n\n```shell\nProduct.java:1: error: illegal combination of modifiers: abstract and final\npublic abstract final class Product {\n ^\n```\n\n\nThe fix is to drop one. Abstract means \"must be extended.\" Final means \"cannot be extended.\" They directly contradict each other.\n\n### Constructor Argument Mismatch When the Abstract Parent Has Only a Parameterized Constructor\n\n\n```java\npublic abstract class Product {\n public String name;\n\n public Product(String name) {\n this.name = name;\n }\n}\n\npublic class Book extends Product {\n public String author;\n\n public Book(String author) { // error: implicit super() with no args\n this.author = author;\n }\n}\n```\n\n\nThe compiler message:\n\n\n```shell\nBook.java:5: error: constructor Product in class Product cannot be applied to given types;\n required: String\n found: no arguments\n```\n\n\nWhen a subclass constructor doesn't explicitly call `super(...)`, Java inserts an implicit `super()` call. That requires the parent to have a no-arg constructor. The abstract `Product` here only defined a constructor taking a `String`, so the implicit call fails. The fix is to add an explicit `super(...)` call with the right arguments:\n\n\n```java\npublic class Book extends Product {\n public String author;\n\n public Book(String name, String author) {\n super(name);\n this.author = author;\n }\n}\n```\n\n\nThis isn't a \"because the parent is abstract\" error. It's the standard constructor-chaining rule. It just shows up often with abstract classes because abstract classes frequently define parameterized constructors to initialize shared state.\n\nNone of these errors have a runtime equivalent. They're caught entirely at compile time, before any class is loaded. That's the whole point of the `abstract` modifier: enforcement at the cheapest possible time.\n\n---\n\n# A Larger Worked Example\n\nPutting the pieces together, here's a realistic catalog using an abstract `Product` class with shared state, a shared method, a static helper, and three concrete subclasses.\n\n\n```java\npublic abstract class Product {\n public String name;\n public double price;\n public int stockCount;\n\n public Product(String name, double price, int stockCount) {\n this.name = name;\n this.price = price;\n this.stockCount = stockCount;\n }\n\n public boolean isInStock() {\n return stockCount > 0;\n }\n\n public void printSummary() {\n String stockText = isInStock() ? stockCount + \" in stock\" : \"out of stock\";\n System.out.println(name + \" - $\" + price + \" (\" + stockText + \")\");\n }\n\n public static double cartTotal(Product[] items) {\n double sum = 0;\n for (int i = 0; i < items.length; i++) {\n sum = sum + items[i].price;\n }\n return sum;\n }\n}\n\npublic class Book extends Product {\n public String author;\n public int pages;\n\n public Book(String name, double price, int stockCount, String author, int pages) {\n super(name, price, stockCount);\n this.author = author;\n this.pages = pages;\n }\n}\n\npublic class Electronics extends Product {\n public String brand;\n public int warrantyMonths;\n\n public Electronics(String name, double price, int stockCount, String brand, int warrantyMonths) {\n super(name, price, stockCount);\n this.brand = brand;\n this.warrantyMonths = warrantyMonths;\n }\n}\n\npublic class Clothing extends Product {\n public String size;\n public String color;\n\n public Clothing(String name, double price, int stockCount, String size, String color) {\n super(name, price, stockCount);\n this.size = size;\n this.color = color;\n }\n}\n\npublic class StoreDemo {\n public static void main(String[] args) {\n Book novel = new Book(\"Effective Java\", 45.99, 7, \"Joshua Bloch\", 416);\n Electronics laptop = new Electronics(\"Aluminum Laptop\", 1299.00, 0, \"Acme\", 24);\n Clothing tshirt = new Clothing(\"Cotton T-Shirt\", 19.99, 40, \"M\", \"Blue\");\n\n Product[] cart = { novel, laptop, tshirt };\n\n for (int i = 0; i < cart.length; i++) {\n cart[i].printSummary();\n }\n\n System.out.println(\"Cart total: $\" + Product.cartTotal(cart));\n }\n}\n```\n\n\nWalk through what's happening:\n\n1. `Product` is abstract. None of the three concrete types are. The compiler would reject `new Product(...)`, but it accepts all three subclass `new` calls.\n2. The shared constructor on `Product` initializes the three shared fields. Each subclass constructor calls `super(...)` to delegate that initialization.\n3. The shared methods `isInStock` and `printSummary` live on `Product`. They run on subclass instances using each instance's own field values.\n4. The array is declared as `Product[]`, so it can hold any concrete subclass instance side by side. Iterating and calling `printSummary` works through the abstract type.\n5. The static helper `Product.cartTotal` doesn't need a `Product` instance and is called through the class name, just like any other static method.\n\nNothing in this example was technically impossible without the `abstract` keyword. The abstract modifier doesn't unlock any new capability. What it does is encode the design rule \"no bare `Product` instances\" into the compiler, so the rule is enforced everywhere automatically. The cost is one word in the class header. The benefit is one less category of bug.","pageType":"java"}

Abstract Classes

Get Premium