{"title":"Abstract Methods","description":"","content":"The previous lesson introduced abstract classes as containers that can't be instantiated. The interesting half of that story is what they hold. An abstract class becomes useful by declaring methods that have no body, just a signature and a semicolon, and forcing every concrete subclass to fill those in. Those declarations are abstract methods, and the rules around them shape how Java models contracts in a class hierarchy. This lesson covers the `abstract` keyword on methods, the modifiers it refuses to combine with, who has to implement what, and the compile errors that appear when any of these rules is broken.\n\n---\n\n# What an Abstract Method Is\n\nAn abstract method is a method declaration without an implementation. You write the signature, you mark it `abstract`, and you end it with a semicolon instead of a body.\n\n\n```java\npublic abstract class PaymentProcessor {\n public abstract void process(double amount);\n}\n```\n\n\nThat single line tells anyone reading `PaymentProcessor` two things. First, every concrete subclass must define a `process` method that takes a `double` and returns nothing. Second, the parent class itself refuses to commit to one way of doing it, because \"process a payment\" means different things for credit cards, gift cards, store credit, and bank transfers. The abstract method is a contract, not an implementation.\n\nHere's the same idea inside a tiny e-commerce flow that actually runs.\n\n\n```java\npublic class PaymentDemo {\n public static void main(String[] args) {\n PaymentProcessor card = new CreditCardProcessor();\n PaymentProcessor giftCard = new GiftCardProcessor();\n\n card.process(49.99);\n giftCard.process(15.00);\n }\n}\n\nabstract class PaymentProcessor {\n public abstract void process(double amount);\n}\n\nclass CreditCardProcessor extends PaymentProcessor {\n @Override\n public void process(double amount) {\n System.out.println(\"Charging $\" + amount + \" to credit card\");\n }\n}\n\nclass GiftCardProcessor extends PaymentProcessor {\n @Override\n public void process(double amount) {\n System.out.println(\"Deducting $\" + amount + \" from gift card balance\");\n }\n}\n```\n\n\nTwo details. The parent has no body for `process`, just a signature and a semicolon. Both children supply a real method body with the same signature, marked `@Override` because they're overriding the parent's declaration. The method overriding rules (same name, same parameter list, compatible return type, no narrower access, no broader checked exceptions) all apply here unchanged. An abstract method is still a method to override; the only twist is that the parent never had a body to begin with.\n\n\n```mermaid\nflowchart TD\n PP[PaymentProcessor
abstract
process amount;]:::cyan --> CC[CreditCardProcessor
process amount runs]:::green\n PP --> GC[GiftCardProcessor
process amount runs]:::green\n PP --> BT[BankTransferProcessor
process amount runs]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe parent declares one method that has no body. Three concrete children each supply their own version. The parent has no opinion about how the work happens; the children carry that knowledge.\n\n---\n\n# Why Abstract Methods Exist\n\nAbstract methods are the reason most abstract classes are abstract in the first place. They solve a specific design problem: how do you say \"every kind of X must support operation Y, but I refuse to pick the one true way to do Y\"?\n\nWithout abstract methods, you have two unsatisfying choices. You can give the parent a placeholder implementation that throws an exception or does nothing, and hope every subclass remembers to override it. Or you can leave the method off the parent entirely and rely on documentation to tell subclass authors what they need to write. Both approaches push enforcement out of the type system and into \"I hope the next developer reads the docs.\"\n\nAbstract methods move that enforcement into the compiler. Consider the placeholder approach first.\n\n\n```java\nclass NaivePaymentProcessor {\n public void process(double amount) {\n throw new UnsupportedOperationException(\"Subclasses must implement process\");\n }\n}\n\nclass ForgetfulProcessor extends NaivePaymentProcessor {\n // Author forgot to override process.\n // Code compiles. Bug shows up at runtime, in production.\n}\n```\n\n\n`ForgetfulProcessor` compiles cleanly. The bug appears only when someone calls `process` on a `ForgetfulProcessor` instance and the program crashes. Whoever wrote the subclass thought they were done. Their tests for unrelated methods passed. The failure happens far from the cause.\n\nCompare the same idea with an abstract method.\n\n\n```java\nabstract class PaymentProcessor {\n public abstract void process(double amount);\n}\n\nclass ForgetfulProcessor extends PaymentProcessor {\n // No process method.\n}\n```\n\n\nThis time the compiler stops the build:\n\n\n```shell\nerror: ForgetfulProcessor is not abstract and does not override abstract method process(double) in PaymentProcessor\n```\n\n\nThe error names the exact missing method. The fix is mechanical: either implement `process`, or mark `ForgetfulProcessor` abstract too and let one of its subclasses handle it. Either way, the unfinished class can never reach production by accident.\n\nThe same argument applies in reverse. When reading code and seeing an abstract method, two things are immediately clear: the parent doesn't have a working implementation, and every concrete subclass is forced to provide one. That's information the type system carries automatically.\n\n---\n\n# Where Abstract Methods Can Live\n\nAn abstract method can only live inside an abstract class or an interface. The reason is simple: if the class is concrete, callers can instantiate it, and they expect every method on that instance to actually do something. A concrete class with an abstract method would be a contradiction.\n\nThe compiler enforces this directly. The moment you write `abstract` in front of a method, the containing class must also be `abstract`.\n\n\n```java\nclass OrderHandler { // not abstract\n public abstract void handle(); // compile error\n}\n```\n\n\nThe compiler responds with:\n\n\n```shell\nerror: OrderHandler is not abstract and does not override abstract method handle() in OrderHandler\nerror: abstract methods cannot have a body\n```\n\n\n(The second error appears because the compiler tries to parse what comes after the signature; the first one is the meaningful one.)\n\nThe fix is to mark the class abstract:\n\n\n```java\nabstract class OrderHandler {\n public abstract void handle();\n}\n```\n\n\nThe rule cuts both ways. An abstract class is allowed to contain zero abstract methods if it wants, but a class containing even one abstract method must be declared abstract. Said the other way around: putting one abstract method in a class infects the whole class with abstractness.\n\n\n```mermaid\nflowchart LR\n Q{Does the class
contain any
abstract method?}:::orange -->|Yes| Must[Class must be
declared abstract]:::red\n Q -->|No| Choice[Class may be abstract
or concrete]:::green\n\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nAn abstract class isn't required to have abstract methods, but having one forces the class to be abstract.\n\n---\n\n# Modifiers That Don't Combine With `abstract`\n\nThe keyword `abstract` declares an intent: \"I'm a method that subclasses must implement.\" Several other modifiers contradict that intent so directly that combining them with `abstract` is a compile error. Six of them fail for different conceptual reasons.\n\n\n| Modifier | Combined with `abstract`? | Why not |\n| --- | --- | --- |\n| `private` | Compile error | `private` methods aren't inherited, so subclasses can never implement them. |\n| `final` | Compile error | `final` says \"this can't be overridden.\" `abstract` says \"this must be.\" Direct contradiction. |\n| `static` | Compile error | `static` methods belong to the class, not instances, and aren't dispatched dynamically. |\n| `synchronized` | Compile error | `synchronized` locks the method body, but there's no body to lock. |\n| `native` | Compile error | `native` says \"the body lives in C/C++ code.\" Abstract says \"there is no body.\" |\n| `strictfp` | Compile error | `strictfp` controls floating-point evaluation inside a body. No body, nothing to control. (Largely irrelevant since Java 17 made strict floating-point the default, but the rule still applies.) |\n\n\nThe rest of this section walks through each combination, the rationale, and the exact compiler error.\n\n### `abstract` + `private`\n\nA `private` method isn't inherited. Subclasses can't see it, can't override it, and can't supply an implementation. An abstract method whose whole purpose is to force subclasses to implement it can't also be hidden from those subclasses.\n\n\n```java\nabstract class PaymentProcessor {\n private abstract void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and private\n```\n\n\nIf you really need a helper that the abstract class controls and subclasses can't see, write it as a regular `private` method with a body. Abstract is for the contract, `private` is for hidden internals; they describe different things.\n\n### `abstract` + `final`\n\n`final` on a method says \"no subclass may override this.\" `abstract` on a method says \"every concrete subclass must override this.\" These are direct opposites.\n\n\n```java\nabstract class PaymentProcessor {\n public abstract final void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and final\n```\n\n\nThis is the cleanest illegal combination in the list. There is no version of \"must be overridden, cannot be overridden\" that makes sense.\n\n### `abstract` + `static`\n\n`static` methods belong to the class, not an instance. They aren't dispatched based on the actual object's type, which is the whole mechanism that makes overriding work. Without dynamic dispatch, there's no way for a subclass implementation to be picked over the parent's, so making a `static` method abstract leaves the runtime no way to resolve calls.\n\n\n```java\nabstract class PaymentProcessor {\n public static abstract void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and static\n```\n\n\nIf you want a class-level utility that varies by subtype, you've picked the wrong tool. Instance methods with overriding handle that. `static` methods are for class-bound utilities where the variable's declared type, not the actual object, is what selects the implementation.\n\n### `abstract` + `synchronized`\n\n`synchronized` on a method tells the JVM to acquire the object's monitor lock before running the method body, and to release it on exit. An abstract method has no body, so there's nothing to wrap in a lock.\n\n\n```java\nabstract class PaymentProcessor {\n public abstract synchronized void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and synchronized\n```\n\n\nIf a subclass implementation needs to be synchronized, the subclass can mark its override `synchronized`. The `synchronized` modifier isn't inherited from a parent declaration, so this is the only sensible place to put it.\n\n### `abstract` + `native`\n\n`native` means \"the implementation is written in another language (typically C or C++) and linked in at runtime.\" `abstract` means \"there is no implementation here, every subclass must supply one.\" Both describe what the method body is, and they describe opposite things.\n\n\n```java\nabstract class PaymentProcessor {\n public abstract native void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and native\n```\n\n\n`native` rarely appears in normal application code. It shows up in the JDK itself (think `System.currentTimeMillis()` or `Object.hashCode()`), but the rule still applies.\n\n### `abstract` + `strictfp`\n\n`strictfp` forces floating-point operations inside a method body to follow strict IEEE 754 rules across all JVMs. Without a body, there's nothing to constrain. (As of Java 17, all floating-point is strict by default, so `strictfp` is effectively a no-op modifier, but the combination rule remains in the language.)\n\n\n```java\nabstract class PaymentProcessor {\n public abstract strictfp void process(double amount); // compile error\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: illegal combination of modifiers: abstract and strictfp\n```\n\n\nThe pattern across all six is the same: abstract describes \"no implementation here,\" and every banned modifier describes some property of an implementation. You can't have a property of a thing that doesn't exist.\n\n---\n\n# Access Modifiers on Abstract Methods\n\nAbstract methods can use any access level except `private`. `public`, `protected`, and package-private (no keyword) all work. The choice changes who in the world is required to be able to implement the method, but the implementation rule itself is identical in every case.\n\n\n```java\nabstract class PaymentProcessor {\n public abstract void process(double amount);\n protected abstract void logAttempt(String detail);\n abstract boolean validate(double amount); // package-private\n}\n```\n\n\nA concrete subclass must supply all three. The access modifier on the subclass implementation must be the same or wider (the standard overriding rule). So a `protected` abstract method can be implemented as `protected` or `public` in the subclass, but never narrowed to package-private or `private`.\n\n\n```java\nclass CreditCardProcessor extends PaymentProcessor {\n @Override\n public void process(double amount) { /* ... */ }\n\n @Override\n public void logAttempt(String detail) { /* widening from protected is fine */ }\n\n @Override\n boolean validate(double amount) { return amount > 0; }\n}\n```\n\n\nWidening is allowed because callers who could reach the parent's declaration must still be able to reach the override; widening preserves that. Narrowing is forbidden for the same reason it's forbidden in normal overriding: it would silently break callers holding a parent-typed reference.\n\nThe package-private case has a wrinkle. A package-private abstract method can only be overridden by subclasses in the same package, because subclasses in other packages can't see the method at all. If you want a method that every subclass anywhere must implement, use `protected` or `public`. Package-private abstract methods are useful when you're keeping the entire hierarchy inside one package and want to limit the API surface; they're rare in practice.\n\n---\n\n# Abstract Methods With `throws` Clauses\n\nAn abstract method declaration can specify checked exceptions in a `throws` clause, just like any other method. The clause tells subclass implementations: \"callers of this method will be required to handle these checked exceptions, so you may throw them.\"\n\n\n```java\nimport java.io.IOException;\n\nabstract class OrderExporter {\n public abstract void export(String orderId) throws IOException;\n}\n\nclass FileOrderExporter extends OrderExporter {\n @Override\n public void export(String orderId) throws IOException {\n // write to a file, may throw IOException\n }\n}\n\nclass InMemoryOrderExporter extends OrderExporter {\n @Override\n public void export(String orderId) {\n // throws nothing, allowed\n }\n}\n```\n\n\nBoth subclass declarations are valid. `FileOrderExporter` throws exactly what the parent declared. `InMemoryOrderExporter` throws nothing at all, which is fine because the standard overriding rule lets a subclass throw fewer checked exceptions than the parent (same, narrower subtype, or none). What it can't do is broaden the throws clause.\n\n\n```java\nclass BadExporter extends OrderExporter {\n @Override\n public void export(String orderId) throws Exception { // compile error\n }\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: export(String) in BadExporter cannot override export(String) in OrderExporter\n overridden method does not throw java.lang.Exception\n```\n\n\n`Exception` is broader than `IOException`. Callers of `OrderExporter.export(...)` only know they need to catch `IOException`. If a subclass slipped a broader `Exception` in, those callers would suddenly have unhandled checked exceptions in code the compiler had previously approved. The rule keeps the parent's contract honest.\n\nUnchecked exceptions (`RuntimeException` and its subclasses) bypass this rule entirely. A subclass can throw `IllegalArgumentException` from an override without the parent declaring anything, just like with any normal override.\n\n---\n\n# Forcing Implementation in the First Concrete Subclass\n\nThe rule that defines abstract methods at the hierarchy level is short: the first concrete subclass in the chain must implement every abstract method it has inherited. Otherwise, it must itself be abstract.\n\nThe word \"first\" matters. Abstract methods can pass through intermediate abstract classes without being implemented. The compiler only insists when it reaches a class that's not abstract.\n\n\n```java\npublic class PaymentChainDemo {\n public static void main(String[] args) {\n PaymentProcessor visa = new VisaCardProcessor();\n PaymentProcessor amex = new AmexCardProcessor();\n\n visa.process(100.00);\n amex.process(250.00);\n }\n}\n\nabstract class PaymentProcessor {\n public abstract void process(double amount);\n public abstract void refund(double amount);\n}\n\nabstract class CreditCardProcessor extends PaymentProcessor {\n // Implements refund for all credit cards.\n // Leaves process abstract so each card brand fills it in.\n @Override\n public void refund(double amount) {\n System.out.println(\"Refunding $\" + amount + \" to credit card\");\n }\n}\n\nclass VisaCardProcessor extends CreditCardProcessor {\n @Override\n public void process(double amount) {\n System.out.println(\"Visa charge: $\" + amount);\n }\n}\n\nclass AmexCardProcessor extends CreditCardProcessor {\n @Override\n public void process(double amount) {\n System.out.println(\"Amex charge: $\" + amount);\n }\n}\n```\n\n\n`PaymentProcessor` declares two abstract methods. `CreditCardProcessor` implements one (`refund`) and leaves the other (`process`) abstract. That's legal because `CreditCardProcessor` is itself abstract. The compiler only starts enforcing at the first concrete class. `VisaCardProcessor` and `AmexCardProcessor` are both concrete, so each must supply a `process` implementation. They inherit `refund` from `CreditCardProcessor` and don't need to redeclare it.\n\n\n```mermaid\nflowchart TD\n P[PaymentProcessor
abstract
process and refund]:::cyan --> CC[CreditCardProcessor
abstract
refund implemented
process still abstract]:::orange\n CC --> Visa[VisaCardProcessor
concrete
process implemented]:::green\n CC --> Amex[AmexCardProcessor
concrete
process implemented]:::green\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\nThe pattern (an abstract class partway down the chain that implements some methods and leaves others abstract) is common when a group of subclasses shares behavior for some operations but disagrees on others. The compiler is fine with multi-step chains as long as the last step that isn't abstract has everything covered.\n\nThe forgetting case looks like this:\n\n\n```java\nabstract class PaymentProcessor {\n public abstract void process(double amount);\n}\n\nclass IncompleteProcessor extends PaymentProcessor {\n // No process implementation, and not declared abstract.\n}\n```\n\n\nThe error:\n\n\n```shell\nerror: IncompleteProcessor is not abstract and does not override abstract method process(double) in PaymentProcessor\n```\n\n\nThe compiler names the missing method. Two fixes work: implement it, or change `class IncompleteProcessor` to `abstract class IncompleteProcessor` and push the obligation down to whoever extends it next.\n\n---\n\n# Calling Abstract Methods From Concrete Ones\n\nAn abstract class is allowed to mix abstract methods with concrete ones, and the concrete methods can call the abstract ones. The parent code calls the contract; at runtime, the subclass's implementation fills in the blank.\n\n\n```java\npublic class CheckoutFlow {\n public static void main(String[] args) {\n PaymentProcessor visa = new VisaCardProcessor();\n PaymentProcessor giftCard = new GiftCardProcessor();\n\n visa.checkout(120.00);\n System.out.println();\n giftCard.checkout(35.00);\n }\n}\n\nabstract class PaymentProcessor {\n public abstract boolean authorize(double amount);\n public abstract void charge(double amount);\n\n // Concrete method that depends on the abstract ones.\n public void checkout(double amount) {\n System.out.println(\"Starting checkout for $\" + amount);\n if (authorize(amount)) {\n charge(amount);\n System.out.println(\"Checkout complete\");\n } else {\n System.out.println(\"Authorization failed\");\n }\n }\n}\n\nclass VisaCardProcessor extends PaymentProcessor {\n @Override\n public boolean authorize(double amount) {\n System.out.println(\"Visa authorization for $\" + amount);\n return true;\n }\n\n @Override\n public void charge(double amount) {\n System.out.println(\"Visa charging $\" + amount);\n }\n}\n\nclass GiftCardProcessor extends PaymentProcessor {\n @Override\n public boolean authorize(double amount) {\n System.out.println(\"Gift card balance check for $\" + amount);\n return amount <= 50.00;\n }\n\n @Override\n public void charge(double amount) {\n System.out.println(\"Gift card deducting $\" + amount);\n }\n}\n```\n\n\n`checkout` is a concrete method on the abstract parent. It owns the high-level flow (announce, authorize, charge or fail). The `authorize` and `charge` steps are abstract because each payment type does them differently. When `checkout` calls `authorize(amount)` and `charge(amount)`, the runtime looks at the actual object (a `VisaCardProcessor` or a `GiftCardProcessor`) and dispatches to that class's implementation.\n\nThis pattern (a concrete parent method orchestrating abstract steps that subclasses fill in) is the Template Method design pattern. The _Design Patterns_ section covers it in detail. For this lesson the takeaway is that abstract methods can be called from inside the same class, and the call uses normal runtime dispatch.\n\nCalls to abstract methods use the same virtual method table dispatch as any other instance method override. Expect one extra pointer hop versus a direct static call. The JIT compiler often inlines these calls when it can prove the actual object type, so in hot paths the cost frequently disappears at runtime.\n\nOne point: the abstract class can't construct itself and call its own concrete method directly, because abstract classes can't be instantiated. The pattern works because callers instantiate a concrete subclass, then call the concrete method on that instance. The parent method's code runs in the subclass's object, so when it calls the abstract method, the dispatch lands on the subclass's implementation.\n\n---\n\n# Real Compiler Errors\n\nMost of this lesson's rules show up as compile errors. Here are the exact messages javac produces for each of the most common mistakes.\n\n**Missing implementation in a concrete subclass:**\n\n\n```shell\nerror: ConcreteClass is not abstract and does not override abstract method methodName() in ParentClass\n```\n\n\n**Abstract method in a non-abstract class:**\n\n\n```shell\nerror: ClassName is not abstract and does not override abstract method methodName() in ClassName\nerror: abstract methods cannot have a body\n```\n\n\n**Abstract method with a body:**\n\n\n```shell\nerror: abstract methods cannot have a body\n```\n\n\n(This happens if you write `abstract void foo() { }` instead of `abstract void foo();`.)\n\n**Illegal modifier combinations:**\n\n\n```shell\nerror: illegal combination of modifiers: abstract and private\nerror: illegal combination of modifiers: abstract and final\nerror: illegal combination of modifiers: abstract and static\nerror: illegal combination of modifiers: abstract and synchronized\nerror: illegal combination of modifiers: abstract and native\nerror: illegal combination of modifiers: abstract and strictfp\n```\n\n\n**Reducing access in an override:**\n\n\n```shell\nerror: methodName(...) in SubClass cannot override methodName(...) in ParentClass\n attempting to assign weaker access privileges; was public\n```\n\n\n**Broadening a `throws` clause:**\n\n\n```shell\nerror: methodName(...) in SubClass cannot override methodName(...) in ParentClass\n overridden method does not throw java.lang.Exception\n```\n\n\nWhen a build fails with one of these, the message itself almost always tells you which rule fired. The fix is usually mechanical: add `abstract` to a class, remove a conflicting modifier, supply the missing implementation, or widen access. The compiler is doing its job; the type system is keeping the contract honest.\n\n---\n\n# Putting It Together: A Small Hierarchy\n\nA worked example pulls every rule above into one program. The setup is the e-commerce payment hierarchy from the start of the lesson, expanded so that all the rules come into play in one place.\n\n\n```java\nimport java.io.IOException;\n\npublic class PaymentHierarchy {\n public static void main(String[] args) throws IOException {\n PaymentProcessor[] processors = {\n new VisaCardProcessor(),\n new AmexCardProcessor(),\n new GiftCardProcessor()\n };\n\n for (PaymentProcessor p : processors) {\n p.checkout(89.99);\n System.out.println();\n }\n }\n}\n\nabstract class PaymentProcessor {\n // Abstract: every concrete subclass must implement.\n public abstract boolean authorize(double amount) throws IOException;\n public abstract void charge(double amount);\n\n // Protected abstract: visible to subclasses, must still be implemented.\n protected abstract String displayName();\n\n // Concrete: orchestrates the abstract steps.\n public void checkout(double amount) throws IOException {\n System.out.println(\"[\" + displayName() + \"] Checkout for $\" + amount);\n if (authorize(amount)) {\n charge(amount);\n System.out.println(\"[\" + displayName() + \"] Done\");\n } else {\n System.out.println(\"[\" + displayName() + \"] Authorization failed\");\n }\n }\n}\n\nabstract class CreditCardProcessor extends PaymentProcessor {\n // Implements one inherited abstract method.\n @Override\n public boolean authorize(double amount) {\n return amount > 0 && amount <= 1000.00;\n }\n\n // Leaves charge and displayName abstract for the brand-specific subclass.\n}\n\nclass VisaCardProcessor extends CreditCardProcessor {\n @Override\n public void charge(double amount) {\n System.out.println(\"Visa charging $\" + amount);\n }\n\n @Override\n protected String displayName() {\n return \"Visa\";\n }\n}\n\nclass AmexCardProcessor extends CreditCardProcessor {\n @Override\n public void charge(double amount) {\n System.out.println(\"Amex charging $\" + amount);\n }\n\n @Override\n protected String displayName() {\n return \"Amex\";\n }\n}\n\nclass GiftCardProcessor extends PaymentProcessor {\n @Override\n public boolean authorize(double amount) {\n return amount <= 50.00;\n }\n\n @Override\n public void charge(double amount) {\n System.out.println(\"Gift card deducting $\" + amount);\n }\n\n @Override\n protected String displayName() {\n return \"Gift Card\";\n }\n}\n```\n\n\nSeveral rules from this lesson are visible in that code. `PaymentProcessor` is abstract and holds three abstract methods. `authorize` declares `throws IOException`, and concrete subclasses narrow it to throwing nothing. `displayName` is `protected abstract`, and every subclass implements it as `protected` (matching the parent's access). `CreditCardProcessor` is itself abstract, supplies `authorize` for all credit cards, and passes `charge` and `displayName` down to brand-specific subclasses. The `checkout` method on the parent calls the abstract methods; runtime dispatch picks the right implementation for each object.\n\nThe output confirms the dispatch: `Visa` and `Amex` go through the credit-card `authorize` (which approves up to $1000), while `Gift Card` uses its own stricter `authorize` (which caps at $50 and rejects the $89.99 charge). One concrete `checkout` method, three different runs, three different behaviors, all driven by which abstract method implementations get plugged in at runtime.","pageType":"java"}

Abstract Methods

Get Premium