{"title":"Interfaces","description":"","content":"The previous two lessons used `abstract class` to share partial behavior between related types. That works when the subtypes really are related (every `Subscription` is a kind of `Product`). It falls apart the moment the design needs to express \"these unrelated types all support paying\" or \"these unrelated types are all shippable.\" Java's answer is the `interface`: a pure contract that any class can sign, regardless of where it lives in the class hierarchy. This lesson covers what an interface is, how a class implements one or many of them, and why programming against an interface tends to age better than programming against a concrete class.\n\n---\n\n# What an Interface Is\n\nAn interface is a named contract. It lists method signatures that a class promises to provide, without saying how. It's like a job description: a `Payable` interface says \"anything claiming to be `Payable` must answer `pay(amount)`,\" and a class signs up by promising to deliver.\n\nThe smallest possible interface and a class that implements it:\n\n\n```java\npublic class FirstInterface {\n public static void main(String[] args) {\n Payable order = new Order(149.99);\n order.pay(149.99);\n }\n}\n\ninterface Payable {\n void pay(double amount);\n}\n\nclass Order implements Payable {\n double total;\n\n Order(double total) {\n this.total = total;\n }\n\n @Override\n public void pay(double amount) {\n System.out.println(\"Charging $\" + amount + \" for order\");\n }\n}\n```\n\n\nThree details about that snippet. The interface uses the `interface` keyword, not `class`. The method `pay` has no body, just a signature and a semicolon. The class uses `implements Payable` to declare that it provides every method the interface requires.\n\nIf `Order` had forgotten to implement `pay`, the compiler would have rejected the file. An interface is a promise the compiler enforces. Partial implementation is not allowed. Either every method has a body in the implementing class, or the class itself has to be `abstract` and pass the obligation down to its own subclasses.\n\nThe interface here is a pure contract: no fields with state, no implementation, just a name and a method signature. That's the original (pre-Java-8) idea of an interface, and it's still the simplest way to think about it. For this lesson, treat interfaces as contracts with method signatures and constants, nothing more.\n\n\n```mermaid\nflowchart LR\n Contract[Payable
contract]:::cyan --> Method[pay double amount]:::orange\n Class[Order
class]:::green -.implements.-> Contract\n Class --> Body[void pay implementation]:::teal\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\nThe diagram shows the split: the interface describes a method that must exist, the class supplies the actual body. The dashed arrow (\"implements\") is the language-level promise that the class will deliver every signature the interface lists.\n\n---\n\n# Why Interfaces Exist\n\nAbstract classes work fine when \"is-a\" makes sense (a `Book` is a `Product`, a `Subscription` is a `Product`). But software is full of \"can-do\" relationships that don't fit a single tree. A `PhysicalBook` and a `BackpackOrder` are completely unrelated as data, but both _can be shipped_. A digital `EBook`, a one-time `Order`, and a `SubscriptionRenewal` are unrelated, but all three _can be paid for_. Forcing every \"can-do\" capability into a class hierarchy creates either deep, brittle trees or duplicated code. Interfaces describe the capability separately from the data.\n\nA small version of the problem without interfaces:\n\n\n```java\npublic class WithoutInterfaces {\n public static void main(String[] args) {\n Book book = new Book(\"Effective Java\", 45.00);\n Subscription sub = new Subscription(\"AlgoMaster Pro\", 9.99);\n\n // We want to \"pay for\" each one. But there's no shared type.\n book.payForBook(book.price);\n sub.payForSub(sub.price);\n }\n}\n\nclass Book {\n String title;\n double price;\n Book(String title, double price) {\n this.title = title; this.price = price;\n }\n public void payForBook(double amount) {\n System.out.println(\"Paid $\" + amount + \" for book \" + title);\n }\n}\n\nclass Subscription {\n String plan;\n double price;\n Subscription(String plan, double price) {\n this.plan = plan; this.price = price;\n }\n public void payForSub(double amount) {\n System.out.println(\"Paid $\" + amount + \" for subscription \" + plan);\n }\n}\n```\n\n\nThe code works, but it's stuck. A `processPayment` method would have to know about every concrete type. Each new product would force every payment handler to grow a new branch. The two classes have nothing in common as data, so making them share a parent class would misrepresent the relationship.\n\nInterfaces name the capability without inventing a fake hierarchy.\n\n\n```java\npublic class WithInterfaces {\n public static void main(String[] args) {\n Payable[] charges = {\n new Book(\"Effective Java\", 45.00),\n new Subscription(\"AlgoMaster Pro\", 9.99)\n };\n\n for (Payable p : charges) {\n p.pay();\n }\n }\n}\n\ninterface Payable {\n void pay();\n}\n\nclass Book implements Payable {\n String title;\n double price;\n Book(String title, double price) {\n this.title = title; this.price = price;\n }\n @Override\n public void pay() {\n System.out.println(\"Paid $\" + price + \" for book \" + title);\n }\n}\n\nclass Subscription implements Payable {\n String plan;\n double price;\n Subscription(String plan, double price) {\n this.plan = plan; this.price = price;\n }\n @Override\n public void pay() {\n System.out.println(\"Paid $\" + price + \" for subscription \" + plan);\n }\n}\n```\n\n\n`Book` and `Subscription` still have nothing in common as data, and that's fine. They both signed the `Payable` contract, so a `Payable[]` can hold either, and the loop dispatches at runtime to each one's implementation. New product types plug in by implementing `Payable`, no existing code changes.\n\nThat benefit has three concrete names:\n\n- **Decoupling.** Callers depend on `Payable`, not on `Book` or `Subscription`. Adding a new payable type doesn't ripple through callers.\n- **Polymorphism without a class hierarchy.** Two classes with unrelated data can still be treated uniformly through a shared interface.\n- **Testability.** A test can create a small stand-in class that implements `Payable` and exposes whatever behavior the test needs. The production code can't tell the difference.\n\n---\n\n# Implementing an Interface\n\nThe mechanics are simple. A class uses `implements InterfaceName` after its `extends` clause (if any). It must provide a body for every method the interface declares, marked `public` (because interface methods are implicitly `public`, and an implementation can't reduce visibility). The `@Override` annotation is optional but strongly recommended: it makes the compiler catch typos that would otherwise quietly create a new method.\n\n\n```java\npublic class ImplementsBasics {\n public static void main(String[] args) {\n Shippable mouse = new Electronics(\"Wireless Mouse\", 0.2);\n mouse.ship(\"742 Evergreen Terrace\");\n System.out.println(\"Weight: \" + mouse.weightKg() + \" kg\");\n }\n}\n\ninterface Shippable {\n void ship(String address);\n double weightKg();\n}\n\nclass Electronics implements Shippable {\n String name;\n double weightKg;\n\n Electronics(String name, double weightKg) {\n this.name = name;\n this.weightKg = weightKg;\n }\n\n @Override\n public void ship(String address) {\n System.out.println(\"Shipping \" + name + \" to \" + address);\n }\n\n @Override\n public double weightKg() {\n return weightKg;\n }\n}\n```\n\n\nA few rules show up in that snippet. Both methods are marked `public`. Writing `void ship(String address)` without `public` would fail to compile because the interface promised the method as `public` and the class would be trying to weaken that promise. `@Override` on both methods is a habit worth keeping: a typo like `shipp` instead of `ship` would produce a compile error instead of leaving the interface unsatisfied.\n\nAn interface can also be implemented inside an `abstract` class without providing every method. The unimplemented methods become the obligation of the next concrete subclass.\n\n\n```java\npublic class AbstractMidway {\n public static void main(String[] args) {\n Shippable mouse = new Electronics(\"Wireless Mouse\", 0.2);\n mouse.ship(\"742 Evergreen Terrace\");\n }\n}\n\ninterface Shippable {\n void ship(String address);\n double weightKg();\n}\n\nabstract class PhysicalProduct implements Shippable {\n String name;\n\n PhysicalProduct(String name) {\n this.name = name;\n }\n\n @Override\n public void ship(String address) {\n System.out.println(\"Shipping \" + name + \" to \" + address);\n }\n // weightKg() is still abstract here.\n}\n\nclass Electronics extends PhysicalProduct {\n double weightKg;\n\n Electronics(String name, double weightKg) {\n super(name);\n this.weightKg = weightKg;\n }\n\n @Override\n public double weightKg() {\n return weightKg;\n }\n}\n```\n\n\n`PhysicalProduct` implements the part of `Shippable` that doesn't depend on each product's specifics, then passes the remaining `weightKg()` obligation down. This pattern is common in the JDK and shows up whenever part of an interface has a sensible default and part doesn't.\n\nA call through an interface reference compiles to `invokeinterface`, which is a vtable lookup with one extra indirection compared to `invokevirtual` (the bytecode used for class-typed calls). On hot paths the JIT usually inlines both equally once it figures out the concrete type, so the gap is mostly invisible in real workloads. The difference shows up only when measuring microbenchmarks.\n\n---\n\n# Methods Are Implicitly `public abstract`\n\nInside a pre-Java-8 interface, every method declaration is implicitly `public abstract`. Either form is legal, but they mean the same thing.\n\n\n```java\ninterface Discountable {\n // Both lines below mean exactly the same thing.\n double applyDiscount(double price);\n public abstract double applyDiscount(double price);\n}\n```\n\n\nThe second version is verbose and considered poor style because the modifiers are redundant. Most Java code uses the bare form. The longer form shows up in interview questions and old codebases, and it's not a trick: it's the literal contract the language enforces.\n\nTwo consequences fall out of the \"implicitly `public abstract`\" rule.\n\nFirst, an interface method cannot be marked `private` or `protected`. The compiler rejects both. (Java 9 added `private` interface methods, but those are a different feature with a different role, covered three chapters from now.) Second, an interface method cannot have a body unless it uses one of the special forms (`default`, `static`, `private`), all of which are siblings to this lesson.\n\nThe verbose-but-equivalent version of `Shippable` from earlier:\n\n\n```java\npublic class ExplicitModifiers {\n public static void main(String[] args) {\n Shippable mouse = new Electronics(\"Wireless Mouse\", 0.2);\n mouse.ship(\"742 Evergreen Terrace\");\n }\n}\n\ninterface Shippable {\n public abstract void ship(String address);\n public abstract double weightKg();\n}\n\nclass Electronics implements Shippable {\n String name;\n double weightKg;\n Electronics(String name, double weightKg) {\n this.name = name; this.weightKg = weightKg;\n }\n @Override public void ship(String address) {\n System.out.println(\"Shipping \" + name + \" to \" + address);\n }\n @Override public double weightKg() { return weightKg; }\n}\n```\n\n\nThe behavior is identical to the earlier version. Most teams drop the redundant modifiers. The detail that matters is that the modifiers are _there_, supplied by the compiler, even when not typed explicitly.\n\n---\n\n# Constants in Interfaces\n\nAny field declared inside an interface is implicitly `public static final`. That's all three modifiers, applied automatically, with no way to override them. This makes interfaces a natural home for shared constants.\n\n\n```java\npublic class InterfaceConstants {\n public static void main(String[] args) {\n System.out.println(\"Free shipping over $\" + ShippingPolicy.FREE_SHIPPING_THRESHOLD);\n System.out.println(\"Standard rate: $\" + ShippingPolicy.STANDARD_RATE + \" per kg\");\n }\n}\n\ninterface ShippingPolicy {\n double FREE_SHIPPING_THRESHOLD = 50.00;\n double STANDARD_RATE = 5.00;\n int MAX_WEIGHT_KG = 30;\n}\n```\n\n\nNothing in `ShippingPolicy` declared `public`, `static`, or `final`, but every one of those modifiers is in effect. The constants are reachable through the interface name (`ShippingPolicy.FREE_SHIPPING_THRESHOLD`), can't be reassigned at runtime, and don't belong to any instance. `ShippingPolicy.FREE_SHIPPING_THRESHOLD = 60.00` is illegal. The compiler treats it like assigning to `Math.PI`.\n\nBe careful with constants in interfaces, though. A common anti-pattern is to make a class implement an interface to inherit its constants. That couples the class to the interface for a reason that has nothing to do with behavior, and constants end up showing up in the class's public type. The better way to share constants is a final class with `public static final` fields, or (since Java 5) `static import`. Interfaces as constant containers work, but most modern style guides discourage it.\n\nThe technical mechanics show up on interviews and in legacy code, for the same reason the verbose `public abstract` shows up.\n\n\n| Declaration in interface | Equivalent declaration |\n| --- | --- |\n| `int MAX = 10;` | `public static final int MAX = 10;` |\n| `String NAME = \"x\";` | `public static final String NAME = \"x\";` |\n| `double rate = 0.05;` | `public static final double rate = 0.05;` (and yes, lowercase fields still become constants) |\n\n\n---\n\n# A Class Can Implement Multiple Interfaces\n\nJava doesn't allow multiple inheritance of state (a class can `extend` only one parent class), but it does allow multiple inheritance of type. A class can implement as many interfaces as it needs by listing them after `implements`, separated by commas. Each interface contributes its own contract, and the class promises to satisfy all of them.\n\nThis is where interfaces start to outpace abstract classes. A real product might be `Payable` and `Shippable` and `Discountable` at the same time, with no single parent class that captures all three.\n\n\n```java\npublic class MultipleInterfaces {\n public static void main(String[] args) {\n Book book = new Book(\"Effective Java\", 45.00, 0.6);\n\n book.pay();\n book.ship(\"742 Evergreen Terrace\");\n double discounted = book.applyDiscount(0.10);\n System.out.println(\"After 10% off: $\" + discounted);\n }\n}\n\ninterface Payable {\n void pay();\n}\n\ninterface Shippable {\n void ship(String address);\n double weightKg();\n}\n\ninterface Discountable {\n double applyDiscount(double percentOff);\n}\n\nclass Book implements Payable, Shippable, Discountable {\n String title;\n double price;\n double weightKg;\n\n Book(String title, double price, double weightKg) {\n this.title = title;\n this.price = price;\n this.weightKg = weightKg;\n }\n\n @Override\n public void pay() {\n System.out.println(\"Paid $\" + price + \" for \" + title);\n }\n\n @Override\n public void ship(String address) {\n System.out.println(\"Shipping \" + title + \" to \" + address);\n }\n\n @Override\n public double weightKg() {\n return weightKg;\n }\n\n @Override\n public double applyDiscount(double percentOff) {\n return price * (1 - percentOff);\n }\n}\n```\n\n\n`Book` wears three hats. A method that takes a `Payable` sees it as `Payable`. A method that takes a `Shippable` sees it as `Shippable`. The runtime object is the same; only the lens changes. This is the kind of layering that abstract classes can't provide because only one parent is allowed.\n\n\n```mermaid\nflowchart TD\n Book[Book class]:::cyan\n Payable[Payable
contract]:::orange\n Shippable[Shippable
contract]:::teal\n Discountable[Discountable
contract]:::green\n\n Book -.implements.-> Payable\n Book -.implements.-> Shippable\n Book -.implements.-> Discountable\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram is intentionally fan-shaped: one class, three independent contracts. Each contract can be added or removed without disturbing the others. A new `Returnable` interface plugs in the same way: add `, Returnable` to the `implements` list, implement its methods, and every existing caller (every method that takes a `Payable`, every method that takes a `Shippable`) keeps working.\n\nWhen a class implements multiple interfaces, name conflicts can happen if two interfaces declare a method with the same signature. The rule: the class supplies one body that satisfies both. The interfaces don't conflict; they're both asking for the same method, and one implementation answers both.\n\n\n```java\npublic class OverlappingMethods {\n public static void main(String[] args) {\n AuditedOrder order = new AuditedOrder();\n order.process();\n }\n}\n\ninterface Loggable {\n void process();\n}\n\ninterface Auditable {\n void process();\n}\n\nclass AuditedOrder implements Loggable, Auditable {\n @Override\n public void process() {\n System.out.println(\"Order processed and logged\");\n }\n}\n```\n\n\nOne `process` method covers both contracts. The compiler doesn't complain about the overlap because the signatures match exactly.\n\n---\n\n# Interface Types as Variable Types\n\nOnce a class implements an interface, the interface name becomes a legal type for variables, method parameters, return values, and array element types. This is \"programming to an interface,\" and it's the practical payoff of the lesson.\n\nThe rule of thumb: declare the variable using the most general type that still provides the methods needed. Almost always, that's the interface, not the concrete class.\n\n\n```java\npublic class ProgrammingToAnInterface {\n public static void main(String[] args) {\n Payable[] charges = {\n new Order(149.99),\n new Subscription(\"AlgoMaster Pro\", 9.99)\n };\n\n processCharges(charges);\n }\n\n static void processCharges(Payable[] charges) {\n double total = 0.0;\n for (Payable p : charges) {\n p.pay();\n total += p.amount();\n }\n System.out.println(\"Total charged: $\" + total);\n }\n}\n\ninterface Payable {\n void pay();\n double amount();\n}\n\nclass Order implements Payable {\n double total;\n Order(double total) { this.total = total; }\n @Override public void pay() { System.out.println(\"Charged order: $\" + total); }\n @Override public double amount() { return total; }\n}\n\nclass Subscription implements Payable {\n String plan;\n double price;\n Subscription(String plan, double price) { this.plan = plan; this.price = price; }\n @Override public void pay() { System.out.println(\"Charged subscription: $\" + price); }\n @Override public double amount() { return price; }\n}\n```\n\n\n`processCharges` takes a `Payable[]`. It doesn't know about `Order` or `Subscription`. The day a new product type starts implementing `Payable` is the day it slides into `processCharges` automatically. The method's source file doesn't change. The test file doesn't change. The interface stays as the only shared contract.\n\nThe same thinking applies to return types. A factory method that returns a `Payable` lets callers depend on the contract, not the concrete class.\n\n\n```java\npublic class FactoryReturnsInterface {\n public static void main(String[] args) {\n Payable today = chargeFor(\"order\", 99.99);\n today.pay();\n }\n\n static Payable chargeFor(String type, double amount) {\n if (type.equals(\"order\")) {\n return new Order(amount);\n }\n return new Subscription(\"Default Plan\", amount);\n }\n}\n\ninterface Payable {\n void pay();\n}\n\nclass Order implements Payable {\n double total;\n Order(double total) { this.total = total; }\n @Override public void pay() { System.out.println(\"Order paid: $\" + total); }\n}\n\nclass Subscription implements Payable {\n String plan;\n double price;\n Subscription(String plan, double price) { this.plan = plan; this.price = price; }\n @Override public void pay() { System.out.println(\"Sub paid: $\" + price); }\n}\n```\n\n\nCallers see `Payable`, not the concrete return type. The factory is free to return a different implementation later without breaking any caller, as long as the new implementation still honors `Payable`.\n\nA useful rule comes out of this: _accept the most general type, return the most general type that's useful_. For interfaces, this usually means accepting and returning interface types. It keeps callers from getting tangled up in concrete classes they don't need to know about.\n\n---\n\n# `instanceof` With Interfaces\n\n`instanceof` works with interface types exactly the way it works with class types. The check asks \"is this object's runtime type compatible with this interface?\" That's true if the runtime class implements the interface, directly or through inheritance.\n\n\n```java\npublic class InstanceofWithInterfaces {\n public static void main(String[] args) {\n Object[] items = {\n new Book(\"Effective Java\", 45.00, 0.6),\n new DigitalSubscription(\"AlgoMaster Pro\", 9.99)\n };\n\n for (Object item : items) {\n if (item instanceof Shippable s) {\n s.ship(\"742 Evergreen Terrace\");\n } else {\n System.out.println(item + \" does not need shipping\");\n }\n }\n }\n}\n\ninterface Shippable {\n void ship(String address);\n}\n\nclass Book implements Shippable {\n String title;\n double price;\n double weightKg;\n Book(String title, double price, double weightKg) {\n this.title = title; this.price = price; this.weightKg = weightKg;\n }\n @Override\n public void ship(String address) {\n System.out.println(\"Shipping \" + title + \" to \" + address);\n }\n}\n\nclass DigitalSubscription {\n String plan;\n double price;\n DigitalSubscription(String plan, double price) {\n this.plan = plan; this.price = price;\n }\n @Override\n public String toString() { return \"Subscription \" + plan; }\n}\n```\n\n\nTwo details. First, `instanceof Shippable` is true for `Book` because `Book implements Shippable`, even though the check is against an interface rather than a class. Java doesn't care; \"is-a\" with interfaces is the same check. Second, the `item instanceof Shippable s` form is pattern matching for `instanceof` (Java 16+). It does the type test, the cast, and the binding to `s` in one go. The traditional form still works:\n\n\n```java\nif (item instanceof Shippable) {\n Shippable s = (Shippable) item;\n s.ship(\"742 Evergreen Terrace\");\n}\n```\n\n\nUse the pattern-matching form on Java 16 and later. It avoids the manual cast and reduces the chance of mismatched type names on the right-hand side.\n\nThe shape of \"what implements what\" can get more interesting once a class implements multiple interfaces or extends a class that implements interfaces. The rule stays consistent: `obj instanceof X` is true exactly when `obj.getClass()` is `X`, extends `X`, or implements `X` (directly or transitively).\n\n\n```java\npublic class TransitiveInstanceof {\n public static void main(String[] args) {\n Object item = new HardcoverBook(\"Effective Java\");\n System.out.println(item instanceof HardcoverBook);\n System.out.println(item instanceof Book);\n System.out.println(item instanceof Shippable);\n System.out.println(item instanceof Object);\n }\n}\n\ninterface Shippable {}\nclass Book implements Shippable {\n String title;\n Book(String title) { this.title = title; }\n}\nclass HardcoverBook extends Book {\n HardcoverBook(String title) { super(title); }\n}\n```\n\n\n`HardcoverBook` inherits the `Shippable` interface implementation from `Book`. The `instanceof` check walks up the inheritance and implementation graph. The lack of an explicit `implements Shippable` on `HardcoverBook` doesn't matter: it _is_ a `Book`, and a `Book` _is_ `Shippable`, so a `HardcoverBook` _is_ `Shippable` too.\n\n---\n\n# Interfaces Can Extend Other Interfaces\n\nInterfaces have their own inheritance graph, separate from classes. An interface can `extends` another interface (or several) to build a larger contract out of smaller ones. The semantics are simple: a class implementing the child interface promises every method from the child _and_ every method inherited from the parents.\n\n\n```java\npublic class InterfaceExtendsInterface {\n public static void main(String[] args) {\n TrackedShippable book = new TrackedBook(\"Effective Java\");\n book.ship(\"742 Evergreen Terrace\");\n System.out.println(\"Tracking: \" + book.trackingNumber());\n }\n}\n\ninterface Shippable {\n void ship(String address);\n}\n\ninterface TrackedShippable extends Shippable {\n String trackingNumber();\n}\n\nclass TrackedBook implements TrackedShippable {\n String title;\n TrackedBook(String title) { this.title = title; }\n\n @Override\n public void ship(String address) {\n System.out.println(\"Shipping \" + title + \" to \" + address);\n }\n\n @Override\n public String trackingNumber() {\n return \"TRK-\" + title.hashCode();\n }\n}\n```\n\n\n`TrackedBook implements TrackedShippable` means it has to provide both `ship` (inherited from `Shippable`) and `trackingNumber` (added by `TrackedShippable`). Any code that needs only the shipping behavior can take a `Shippable`. Code that also needs tracking takes a `TrackedShippable`. The hierarchy lets clients pick the smallest contract that provides what they need.\n\nUnlike classes, an interface can extend _multiple_ interfaces. This is one of the places Java relaxes the \"single inheritance\" rule because no state is involved; only method signatures get inherited, and signatures don't conflict the way state does.\n\n\n```java\npublic class MultipleInterfaceExtends {\n public static void main(String[] args) {\n DigitalProduct ebook = new EBook(\"Effective Java\", 35.00);\n ebook.pay();\n System.out.println(\"Download URL: \" + ebook.downloadUrl());\n }\n}\n\ninterface Payable {\n void pay();\n}\n\ninterface Downloadable {\n String downloadUrl();\n}\n\ninterface DigitalProduct extends Payable, Downloadable {\n // Inherits both pay() and downloadUrl()\n}\n\nclass EBook implements DigitalProduct {\n String title;\n double price;\n EBook(String title, double price) {\n this.title = title; this.price = price;\n }\n @Override\n public void pay() { System.out.println(\"Paid $\" + price + \" for \" + title); }\n @Override\n public String downloadUrl() { return \"/downloads/\" + title.replace(' ', '-'); }\n}\n```\n\n\n`DigitalProduct` extends both `Payable` and `Downloadable`, gathering both contracts into a single named type. An `EBook` then satisfies the combined contract with one `implements` clause. This is a different kind of multiple inheritance from what classes get: interfaces inherit obligations (method signatures), not state, so there's no \"which copy of the field is in effect?\" problem.\n\n\n```mermaid\nflowchart TD\n Payable[Payable
pay]:::orange\n Downloadable[Downloadable
downloadUrl]:::teal\n DigitalProduct[DigitalProduct
extends Payable, Downloadable]:::cyan\n EBook[EBook class]:::green\n\n Payable -.->|extended by| DigitalProduct\n Downloadable -.->|extended by| DigitalProduct\n DigitalProduct -.->|implemented by| EBook\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe graph reads top-to-bottom: small contracts at the top, a combined contract in the middle, the implementing class at the bottom. Each layer adds obligations; nothing gets removed. The whole thing collapses into one set of method signatures the class must provide.\n\nThe corresponding rule for classes shows up next to this one in real code. A class can extend exactly one class but can implement many interfaces. The class-extends slot is for state inheritance (fields, partial implementation); the implements slots are for contract inheritance. Java keeps those two channels separate to avoid the diamond problem that affects C++.\n\n\n```java\nclass TrackedBook extends Book implements Payable, Shippable, Trackable {\n // one parent class, three interfaces, all fine.\n}\n```\n\n\nThat single line is the canonical shape of a Java class: one parent for shared data and partial behavior, any number of interfaces for capabilities. The rest of the abstraction section builds on this split.\n\n---\n\n# Putting It Together: A Mixed E-Commerce Catalog\n\nA payoff demo. Real catalogs hold a mix: physical books and electronics that need shipping and discounts, digital subscriptions that need neither, gift cards that need payment but no shipping. With three small interfaces (`Payable`, `Shippable`, `Discountable`), each product picks the contracts that fit, and one central piece of code processes them all.\n\n\n```java\npublic class MixedCatalog {\n public static void main(String[] args) {\n Object[] cart = {\n new Book(\"Effective Java\", 45.00, 0.6),\n new Electronics(\"Wireless Mouse\", 29.99, 0.2),\n new Subscription(\"AlgoMaster Pro\", 9.99),\n new GiftCard(50.00)\n };\n\n processCart(cart, \"742 Evergreen Terrace\", 0.10);\n }\n\n static void processCart(Object[] cart, String address, double discountRate) {\n double total = 0.0;\n\n for (Object item : cart) {\n // Apply discount if eligible.\n double price;\n if (item instanceof Discountable d) {\n price = d.applyDiscount(discountRate);\n } else if (item instanceof Payable p) {\n price = p.amount();\n } else {\n continue;\n }\n total += price;\n\n // Charge it.\n if (item instanceof Payable p) {\n p.pay();\n }\n\n // Ship if needed.\n if (item instanceof Shippable s) {\n s.ship(address);\n }\n }\n\n System.out.println(\"Cart total after discounts: $\" + total);\n }\n}\n\ninterface Payable {\n void pay();\n double amount();\n}\n\ninterface Shippable {\n void ship(String address);\n}\n\ninterface Discountable {\n double applyDiscount(double percentOff);\n}\n\nclass Book implements Payable, Shippable, Discountable {\n String title;\n double price;\n double weightKg;\n Book(String title, double price, double weightKg) {\n this.title = title; this.price = price; this.weightKg = weightKg;\n }\n @Override public void pay() { System.out.println(\"Paid for book: \" + title); }\n @Override public double amount() { return price; }\n @Override public void ship(String address) {\n System.out.println(\"Shipping book \" + title + \" to \" + address);\n }\n @Override public double applyDiscount(double percentOff) {\n return price * (1 - percentOff);\n }\n}\n\nclass Electronics implements Payable, Shippable, Discountable {\n String name;\n double price;\n double weightKg;\n Electronics(String name, double price, double weightKg) {\n this.name = name; this.price = price; this.weightKg = weightKg;\n }\n @Override public void pay() { System.out.println(\"Paid for electronics: \" + name); }\n @Override public double amount() { return price; }\n @Override public void ship(String address) {\n System.out.println(\"Shipping electronics \" + name + \" to \" + address);\n }\n @Override public double applyDiscount(double percentOff) {\n return price * (1 - percentOff);\n }\n}\n\nclass Subscription implements Payable {\n String plan;\n double price;\n Subscription(String plan, double price) {\n this.plan = plan; this.price = price;\n }\n @Override public void pay() { System.out.println(\"Paid for subscription: \" + plan); }\n @Override public double amount() { return price; }\n}\n\nclass GiftCard implements Payable {\n double value;\n GiftCard(double value) { this.value = value; }\n @Override public void pay() { System.out.println(\"Bought gift card worth $\" + value); }\n @Override public double amount() { return value; }\n}\n```\n\n\nA few details in `processCart`. The cart is typed `Object[]` because no single interface covers everything (subscriptions don't ship, gift cards don't discount). The method asks each item what capabilities it has by using `instanceof` against each interface. A `Book` answers `yes` to all three; a `GiftCard` answers `yes` only to `Payable`. The method doesn't know or care what concrete class an item is. The interfaces are the only contracts it depends on.\n\nA future `EBook` plugs in by implementing whichever interfaces fit (probably `Payable` and `Discountable`, not `Shippable`). `processCart` doesn't change. A future `PhysicalGiftCard` also plugs in (`Payable`, `Shippable`) without touching this code. That's the open/closed principle expressed in concrete classes, with interfaces playing the role of plug-in points.\n\n\n```mermaid\nflowchart LR\n Cart[processCart loop]:::cyan --> Pay[Payable check]:::orange\n Cart --> Ship[Shippable check]:::teal\n Cart --> Disc[Discountable check]:::green\n\n Pay --> B1[Book pays]:::cyan\n Pay --> E1[Electronics pays]:::cyan\n Pay --> S1[Subscription pays]:::cyan\n Pay --> G1[GiftCard pays]:::cyan\n\n Ship --> B2[Book ships]:::cyan\n Ship --> E2[Electronics ships]:::cyan\n\n Disc --> B3[Book discount]:::cyan\n Disc --> E3[Electronics discount]:::cyan\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows the matrix: three capabilities along the top, four product types along the bottom, each cell either filled in (the product implements that interface) or empty (it doesn't). The cart code walks the matrix without knowing the column names ahead of time.\n\n`instanceof` checks cost a handful of CPU cycles in the steady state because the JVM caches the answer on the object's class. They have a measurable cost in a tight inner loop, but in a cart-processing loop with a few items they're below the noise floor. Dozens of `instanceof` checks per item is a signal that the design wants a smaller, more focused interface.\n\n---\n\n# Interfaces vs Concrete Types as Parameters\n\nOnce interfaces are part of the toolkit, a small habit applies in almost every method: pick the parameter type by the contract actually used, not by the concrete class that happens to be in front of the call.\n\n\n```java\npublic class TooSpecific {\n public static void main(String[] args) {\n Book book = new Book(\"Effective Java\", 45.00);\n chargeWithBookOnly(book);\n }\n\n static void chargeWithBookOnly(Book book) {\n book.pay();\n }\n}\n\ninterface Payable { void pay(); }\nclass Book implements Payable {\n String title;\n double price;\n Book(String title, double price) { this.title = title; this.price = price; }\n @Override public void pay() { System.out.println(\"Charged $\" + price); }\n}\n```\n\n\nThe method works, but it's tied to `Book`. Adding a `Subscription` later means a new method or generics. The fix is to widen the parameter type to the interface.\n\n\n```java\npublic class JustRight {\n public static void main(String[] args) {\n Book book = new Book(\"Effective Java\", 45.00);\n Subscription sub = new Subscription(\"AlgoMaster Pro\", 9.99);\n charge(book);\n charge(sub);\n }\n\n static void charge(Payable p) {\n p.pay();\n }\n}\n\ninterface Payable { void pay(); }\nclass Book implements Payable {\n String title;\n double price;\n Book(String title, double price) { this.title = title; this.price = price; }\n @Override public void pay() { System.out.println(\"Book charged $\" + price); }\n}\nclass Subscription implements Payable {\n String plan;\n double price;\n Subscription(String plan, double price) { this.plan = plan; this.price = price; }\n @Override public void pay() { System.out.println(\"Sub charged $\" + price); }\n}\n```\n\n\n`charge` doesn't care about `Book` or `Subscription`. It cares about `Payable`. The signature reads like documentation: \"this method does something with anything that's payable.\" The fewer assumptions a method makes about its arguments, the more places it fits, and the easier it is to test in isolation.\n\nThere's a balance to strike. Widening the parameter type costs nothing if the interface is right-sized, but a method that takes `Object` and then `instanceof`-checks everything has thrown away type safety. The interface should be wide enough to cover all the legitimate callers, no wider. Start narrow and widen when a second use case shows up.","pageType":"java"}

Interfaces

Get Premium