When should you choose an abstract class over an interface or a concrete class, and what are the long-term costs of exposing an abstract class in a public API?

## The three candidates When modeling shared behavior you choose among: a **concrete class** (fully implemented, instantiable), an **abstract class** (partial implementation + abstract slots, not instantiable), and an **interface** (a contract; since Java 8 it may carry `default`/`static` method bodies but no instance state). Picking well is a design decision with long-lived consequences. ## When an abstract class wins Choose an abstract class when **all** of these hold: - There is a genuine **'is-a'** relationship (a `Circle` IS-A `Shape`) — not merely 'can-do.' - Subclasses share **mutable instance state** that should be declared and initialized once. Interfaces *cannot* hold instance fields, so only an abstract class can centralize this. - You have **partial implementation** to share — concrete methods written in terms of a few abstract primitives (the **skeletal implementation** / Template Method case, e.g. `AbstractList` built on `get(int)`+`size()`). - A **single, controlled hierarchy** is acceptable, because `extends` consumes the subclass's one inheritance slot. ## When an interface wins Prefer an interface when: - You only need to **publish a contract** ('anything that can be Comparable / Closeable'), with no shared state. - Implementers may be **unrelated** types that already extend something else — interfaces give **multiple inheritance of type** (a class can implement many). - You want maximum flexibility to **retrofit** existing classes (they can implement a new interface without changing their superclass). - Default methods can supply the small bit of shared behavior you need without instance state. The canonical combo is **interface + skeletal abstract class**: publish `List` (interface), provide `AbstractList` (abstract skeleton) for implementers who want the freebies, but don't *force* the inheritance on anyone. This gets the best of both. ## When neither — use composition If there's no real variation to defer, don't introduce a hierarchy at all. A concrete class, or **composition + delegation** (hold a collaborator, forward calls) or a **strategy object** (a functional interface injected at runtime), often beats inheritance: it avoids the coupling, sidesteps the single-inheritance limit, and lets behavior change at runtime. 'Favor composition over inheritance' is the default; inheritance is the exception you justify. ## The long-term costs of a *public* abstract class Exposing an abstract class as part of an API is a heavy, near-irreversible commitment: 1. **Single-inheritance tax.** Every subclass spends its one `extends` slot on you. If a client already has a base class, they *cannot* use your abstract class by extension at all. 2. **Adding abstract methods is a breaking change.** You can append *concrete* methods in a later version, but adding an *abstract* method breaks every existing subclass (they no longer compile). Interfaces with default methods are more evolvable here. 3. **`protected` is forever.** Any protected field or method you expose for subclasses becomes part of your permanent contract; you can't tighten or remove it without breaking subclasses. Protected members leak implementation detail into the API. 4. **Fragile base class.** Changing the base's internal call sequence can silently break subclasses that overrode hooks expecting the old order. And a base constructor that calls an overridable method invokes subclass code before the subclass is initialized — a latent NPE generator. 5. **Liskov obligations.** Subclasses must honor the base's invariants; a poorly specified base makes correct subclassing impossible. ## Effective Java's rule The guidance (Bloch): **'Design and document for inheritance, or else prohibit it.'** If you ship an abstract class meant to be extended, document *exactly* which methods call which overridable methods, in what order (the self-use patterns), and provide a skeletal implementation. If you don't intend extension, make the class `final` or hide its constructor. Half-measures — an extensible-looking class with undocumented self-use — are how fragile-base-class bugs are born. ## Modern alternatives For closed type families, **sealed classes/interfaces** plus **pattern-matching switch** let you express 'these and only these subtypes' with exhaustive handling, often replacing an abstract base + visitor. For varying a single behavior, **functional interfaces + lambdas** (Strategy) beat subclassing. Reserve abstract classes for the true skeletal-implementation case where shared state and a single hierarchy genuinely pay for themselves.