Abstract Class vs Interface

## Why the question exists at all "Abstract class or interface?" is a famous interview question because a specific family of languages makes it a real, irreversible decision. Those languages share three properties: **nominal typing** (a type conforms only if it says so), **single implementation inheritance** (a class may extend at most one class), and a syntactic distinction between a class that can carry state and an interface that cannot. Java, C#, Kotlin and Swift's class side all fit. In that world, choosing an abstract base spends the implementer's one inheritance slot forever, so the choice matters and has to be made up front. Remove any of the three properties and the question dissolves or turns into a different question. ## Go: the consumer declares the abstraction Go has no classes and no inheritance. A type satisfies an interface simply by having the right methods — nothing is declared on the type. The consequence is architectural: interfaces are typically declared **next to the code that consumes them**, not next to the code that implements them, and they are kept tiny (`io.Reader` has one method). Code reuse that would have lived in an abstract base lives in an **embedded struct**, which is delegation with automatic method forwarding, not subtyping. So the Go version of the question is "what is the smallest set of methods my function needs?" — a question about the call site, not about the type hierarchy. You never edit a third-party type to make it fit. ## Rust: traits with defaults, and no inheritance at all Rust has traits, which look like interfaces with default bodies, and structs, which hold data. There is no way to inherit implementation from another struct. So the abstract-base option simply does not exist; the design question becomes "what goes in the trait's default bodies, and what must each implementer supply?" Shared state is expressed by requiring accessor methods, or by having implementers hold a common struct as a field. Rust also allows something Java and C# do not: implementing your trait for a type you did not write. That freedom is bounded by the **orphan rule** — you may not implement a foreign trait for a foreign type — because trait resolution is global and two conflicting impls would be ambiguous. When the rule bites, you wrap the foreign type in a newtype. ## C++: the two are the same construct C++ has no `interface` keyword. An interface is a class whose member functions are all **pure virtual** and which declares no data members. Because C++ permits multiple inheritance of implementation, the compile-time restriction that forces the Java-style choice is absent. The decisions that remain are lower level and sharper: adding a data member to a base means that inheriting it twice produces two subobjects unless the bases are declared `virtual`, which changes construction order and member access; and if you do not need runtime substitution at all, templates or CRTP give you polymorphism with no base class and no vtable. ## Python: pick your coupling model per abstraction Python lets you have both, explicitly. `abc.ABC` gives a nominal abstract base: subclasses must be registered or must inherit, and the base may supply concrete mixin methods and even state. `typing.Protocol` (with `@runtime_checkable` if you need isinstance) gives Go-style structural conformance: the implementer neither knows nor declares anything. The same program can use an ABC where a shared skeleton exists and a Protocol where only a shape is needed. ## What actually drives the decision, once the taxonomy is gone Stripped of language ceremony, three questions remain, and they are the same everywhere: 1. **Is there shared state or a shared algorithm skeleton?** If yes, something must own it — a base class, an embedded struct, a delegated collaborator. This is a code-reuse question. 2. **Is conformance intrinsic to what the type *is*, or is it a role the type can *play*?** Intrinsic identity tolerates a base type; roles want small, separately declared contracts. 3. **Who is allowed to declare conformance, and can it be added later for a type you do not own?** This is where the languages genuinely diverge, and it is often the deciding factor in practice. ## Answering the interview version well A weak answer recites "an interface is a contract, an abstract class shares code, a class can implement many interfaces but extend one class". A strong answer notices that the last clause is a rule of *specific languages*, names Go, Rust, C++ and Python as counter-examples, and then re-derives the decision from state, identity and who may declare conformance — criteria that survive translation to any of them.