TypeScript Abstract Classes vs Interfaces in 2026: Which to Reach For and When

TypeScript engineers often misuse abstract classes and interfaces due to a superficial understanding of their differences. Interfaces define pure structural contracts with zero runtime overhead, while abstract classes combine contracts with executable code for shared behavior and state. Choosing correctly between them is crucial for building flexible, maintainable systems.

This article was written with the assistance of AI, under human supervision and review. Most TypeScript engineers misuse abstract classes and interfaces because they treat them as interchangeable. The confusion stems from a superficial understanding: both appear to define contracts for objects, both enforce implementation requirements, and both support polymorphism. Teams reach for abstract classes when interfaces would suffice, or worse, they use interfaces where shared behavior demands an abstract base. The cost shows up as duplicated logic, brittle hierarchies, and runtime errors that TypeScript's type system should have prevented. The distinction matters because these tools serve fundamentally different purposes. Interfaces define pure structural contracts—shapes that objects must match without dictating implementation. Abstract classes combine contracts with executable code, providing shared behavior and state that subclasses inherit. Choosing correctly means the difference between a flexible system that adapts to requirements and a rigid codebase that fights every change. The correct approach matches the tool to the problem. When the requirement is a contract without implementation—a shape that multiple unrelated classes satisfy—interfaces deliver maximum flexibility with zero runtime overhead. When the requirement includes shared behavior or state that subclasses must inherit, abstract classes enforce the contract while eliminating duplication. Interfaces excel when the requirement is structural conformance. When multiple unrelated classes need to expose the same shape but implement behavior independently, interfaces enforce the contract without coupling implementations through inheritance. This matters for teams building plugin systems, event-driven architectures, or any codebase where flexibility trumps code reuse. The key advantage is compile-time enforcement with zero runtime cost. TypeScript erases interfaces entirely during compilation—they produce no JavaScript, consume no memory, and impose no inheritance hierarchy. A class can implement dozens of interfaces without runtime penalty, and objects can satisfy interfaces without explicitly declaring them through structural typing. Interfaces support multiple implementation—a class can implement several interfaces simultaneously, enabling composition over inheritance. This pattern appears frequently in dependency injection systems where services must satisfy multiple contracts. The TypeScript compiler verifies that every required property and method exists with correct signatures, catching contract violations before runtime. The limitation is that interfaces cannot provide default implementations. Every class implementing an interface must define every method, even when implementations are identical. When three classes need the same validation logic, interfaces force duplication. The temptation to copy-paste shared code signals that an abstract class might be the better choice. Abstract classes serve a different purpose: they combine contract enforcement with executable code that subclasses inherit. When multiple classes require both a common interface and shared implementation, abstract classes eliminate duplication while maintaining type safety. The pattern appears in framework development, plugin architectures with common utilities, and any domain where subclasses share substantial logic. The core capability is partial implementation. Abstract classes define methods with actual code that subclasses inherit and optionally override. Protected members provide encapsulated state that subclasses access but external consumers cannot. Abstract methods—declared without implementation—force subclasses to define specific behavior while inheriting the rest. The tradeoff is reduced flexibility compared to interfaces. Abstract classes enforce single inheritance—a class extends exactly one abstract base. When requirements demand multiple base implementations, the hierarchy collapses. Interfaces allow a class to implement multiple contracts simultaneously; abstract classes impose a single inheritance chain. Runtime overhead is the other consideration. Abstract classes compile to JavaScript constructors and prototype chains. Every instance carries the inheritance hierarchy in memory, and every method call traverses the prototype chain. The impact is negligible for typical applications but matters in performance-critical code processing millions of objects. Bundle size increases proportionally with the number of base methods and properties. The plugin system pattern demonstrates interfaces at scale. When a host application needs to accept third-party extensions without knowing their implementation, interfaces define the contract. Each plugin implements the required methods, but the host never depends on concrete classes—only the interface shape. interface DataTransformer { readonly name: string; readonly version: string; transform input: unknown : Promise<unknown ; validate input: unknown : boolean; } class JsonTransformer implements DataTransformer { readonly name = "json-transformer"; readonly version = "1.0.0"; async transform input: unknown : Promise<unknown { if typeof input == "string" { throw new Error "JsonTransformer requires string input" ; } return JSON.parse input ; } validate input: unknown : boolean { if typeof input == "string" return false; try { JSON.parse input ; return true; } catch { return false; } } } class XmlTransformer implements DataTransformer { readonly name = "xml-transformer"; readonly version = "1.2.0"; async transform input: unknown : Promise<unknown { // XML parsing implementation return { parsed: "xml-data" }; } validate input: unknown : boolean { return typeof input === "string" && input.startsWith "<" ; } } class TransformerRegistry { private transformers = new Map<string, DataTransformer ; register transformer: DataTransformer : void { this.transformers.set transformer.name, transformer ; } async process name: string, input: unknown : Promise<unknown { const transformer = this.transformers.get name ; if transformer { throw new Error Transformer ${name} not found ; } if transformer.validate input { throw new Error Invalid input for ${name} ; } return transformer.transform input ; } } The registry depends only on the DataTransformer interface. New transformers integrate without modifying host code. The pattern scales to hundreds of plugins because interfaces impose no inheritance coupling. Each transformer implements the contract independently, using whatever internal implementation suits its requirements. Event emitter systems follow the same principle. When multiple unrelated classes need to handle events, interfaces define the handler contract. The event system dispatches to any object matching the shape, regardless of its inheritance hierarchy. interface EventHandler<T = unknown { handle event: T : void | Promise<void ; priority?: number; } class EventBus { private handlers = new Map<string, EventHandler ; on<T eventName: string, handler: EventHandler<T : void { const existing = this.handlers.get eventName || ; this.handlers.set eventName, ...existing, handler .sort a, b = b.priority || 0 - a.priority || 0 ; } async emit<T eventName: string, event: T : Promise<void { const handlers = this.handlers.get eventName || ; for const handler of handlers { await handler.handle event ; } } } class LoggingHandler implements EventHandler<{ message: string } { priority = 100; handle event: { message: string } : void { console.log LOG ${event.message} ; } } class MetricsHandler implements EventHandler<{ message: string } { priority = 50; async handle event: { message: string } : Promise<void { // Send to metrics service await fetch "/metrics", { method: "POST", body: JSON.stringify { event: event.message } } ; } } Both handlers satisfy the EventHandler interface structurally. The event bus dispatches without caring about class hierarchies or implementation details. Adding a new handler requires no changes to existing code—just implement the interface and register. Form validation showcases abstract classes solving duplication. When multiple validators share formatting logic and error handling but differ in validation rules, abstract base classes provide the shared code. Subclasses inherit utilities and implement only the domain-specific validation. abstract class BaseValidator<T { protected errors: string = ; abstract validateRule value: T : boolean; validate value: T : { valid: boolean; errors: string } { this.errors = ; const valid = this.validateRule value ; return { valid, errors: ...this.errors }; } protected addError message: string : void { this.errors.push message ; } protected formatError field: string, constraint: string : string { return ${field} ${constraint} ; } } class EmailValidator extends BaseValidator<string { private readonly emailPattern = /^ ^\s@ +@ ^\s@ +\. ^\s@ +$/; validateRule value: string : boolean { if value { this.addError this.formatError "Email", "is required" ; return false; } if this.emailPattern.test value { this.addError this.formatError "Email", "must be valid" ; return false; } return true; } } class PasswordValidator extends BaseValidator<string { private readonly minLength = 8; validateRule value: string : boolean { let valid = true; if value { this.addError this.formatError "Password", "is required" ; return false; } if value.length < this.minLength { this.addError this.formatError "Password", must be at least ${this.minLength} characters ; valid = false; } if / A-Z /.test value { this.addError this.formatError "Password", "must contain uppercase letter" ; valid = false; } if / 0-9 /.test value { this.addError this.formatError "Password", "must contain number" ; valid = false; } return valid; } } class FormValidator { validate fields: { email: string; password: string } : { valid: boolean; errors: Record<string, string } { const emailResult = new EmailValidator .validate fields.email ; const passwordResult = new PasswordValidator .validate fields.password ; return { valid: emailResult.valid && passwordResult.valid, errors: { email: emailResult.errors, password: passwordResult.errors } }; } } Both validators inherit error collection and formatting from BaseValidator . The protected addError and formatError methods eliminate duplication while keeping implementation details encapsulated. Each validator implements only validateRule , defining domain-specific logic without reimplementing infrastructure. Repository patterns benefit similarly. When multiple repositories share connection management, transaction handling, and error logging but differ in query logic, abstract base classes provide the common infrastructure. Related content: TypeScript form validators https://jsmanifest.com/typescript-form-validators-custom explores advanced validation patterns. abstract class BaseRepository<T { protected abstract tableName: string; protected async query<R sql: string, params: unknown : Promise<R { // Shared connection pooling, error handling console.log Executing: ${sql} ; return as R ; } protected async transaction<R fn: = Promise<R : Promise<R { // Shared transaction management console.log "Starting transaction" ; try { const result = await fn ; console.log "Committing transaction" ; return result; } catch error { console.log "Rolling back transaction" ; throw error; } } async findById id: string : Promise<T | null { const results = await this.query<T SELECT FROM ${this.tableName} WHERE id = ? , id ; return results 0 || null; } } class UserRepository extends BaseRepository<{ id: string; email: string } { protected tableName = "users"; async findByEmail email: string : Promise<{ id: string; email: string } | null { const results = await this.query<{ id: string; email: string } SELECT FROM ${this.tableName} WHERE email = ? , email ; return results 0 || null; } async createUser email: string : Promise<{ id: string; email: string } { return this.transaction async = { const id = crypto.randomUUID ; await this.query INSERT INTO ${this.tableName} id, email VALUES ?, ? , id, email ; return { id, email }; } ; } } The base repository handles connection management, transactions, and common queries. Subclasses inherit the infrastructure and add domain-specific methods. The pattern eliminates hundreds of lines of duplicated database logic across repositories. The architectural differences produce measurable performance and flexibility implications. Understanding these tradeoffs informs the decision when both approaches appear viable. Runtime performance favors interfaces in object creation and memory consumption. Interfaces compile away entirely—the TypeScript compiler erases them during transpilation. An object implementing three interfaces consumes the same memory as an object implementing zero interfaces. Abstract classes generate JavaScript constructors and prototype chains that occupy memory and add indirection to method calls. The difference manifests in high-volume scenarios. Creating ten thousand objects from an abstract class hierarchy allocates memory for the entire inheritance chain. The same objects satisfying interfaces through structural typing carry no inheritance overhead. Method calls on interface-satisfying objects resolve directly; calls on abstract subclass instances traverse prototype chains. Bundle size follows the same pattern. Interfaces contribute zero bytes to the production bundle. Abstract classes compile to JavaScript constructor functions and method definitions that occupy space proportional to the base implementation. A codebase with twenty abstract base classes might carry ten kilobytes of inheritance infrastructure that interfaces would eliminate. Flexibility tilts toward interfaces. A class can implement dozens of interfaces simultaneously, composing behavior from multiple sources. Abstract classes enforce single inheritance—exactly one base class. When a class needs behavior from two abstract bases, the architecture breaks. The workaround—composition over inheritance—often signals that interfaces were the better choice initially. Code reuse is where abstract classes dominate. When five classes share identical helper methods, abstract base classes eliminate duplication with zero cost to call sites. Interfaces force each class to implement helpers independently, or push shared code to external utility modules. The choice between duplicated implementation and awkward utility imports disappears with abstract classes. Type safety is equivalent. Both approaches catch contract violations at compile time. Both support generic constraints and complex type relationships. The compiler verifies that classes satisfy their contracts whether those contracts come from interfaces or abstract base classes. The decision reduces to a flowchart that teams can apply consistently. Start with the requirement: does the contract include shared behavior or state that multiple classes need? If the answer is no—the requirement is purely structural conformance without shared implementation—reach for interfaces. The pattern appears in plugin systems, event handlers, strategy patterns, and anywhere multiple unrelated classes expose the same shape. Interfaces provide maximum flexibility with zero runtime cost. If the answer is yes—multiple classes require both a contract and shared executable code—consider whether those classes also need to implement other contracts. When a class needs behavior from a single abstract base and implements no other interfaces, abstract classes eliminate duplication without sacrificing type safety. When a class requires both shared base behavior and multiple interface contracts, hybrid patterns provide the solution. An abstract class can implement one or more interfaces while providing shared code. Subclasses inherit the implementation and satisfy all interface contracts through the base class. interface Serializable { serialize : string; deserialize data: string : void; } interface Validatable { validate : boolean; } abstract class BaseEntity implements Serializable, Validatable { abstract id: string; serialize : string { return JSON.stringify this ; } deserialize data: string : void { Object.assign this, JSON.parse data ; } validate : boolean { return Boolean this.id ; } } class User extends BaseEntity { id: string; email: string; constructor id: string, email: string { super ; this.id = id; this.email = email; } validate : boolean { return super.validate && Boolean this.email ; } } The hybrid pattern combines interface flexibility with abstract class code reuse. BaseEntity satisfies both Serializable and Validatable interfaces while providing shared serialization logic. Subclasses inherit the implementation and extend validation as needed. External code can depend on either interface without knowing about the abstract base. Performance-critical paths warrant special consideration. When code processes millions of objects per second, interface-based structural typing outperforms abstract class hierarchies. The memory overhead of prototype chains becomes measurable at scale. Profile before optimizing, but when profiling shows inheritance as a bottleneck, interfaces eliminate the cost. Legacy codebases with deep inheritance hierarchies often benefit from incremental migration toward interfaces. Extract shared behavior into utility functions or composition patterns, define interfaces for existing contracts, and gradually replace abstract bases with interface implementations. The refactoring reduces coupling and improves testability without requiring a complete rewrite. Related content: TypeScript utility types https://jsmanifest.com/10-typescript-utility-types-bulletproof-code covers type-level composition patterns. Production systems rarely fit clean either-or patterns. Complex domains require both contract enforcement and shared behavior across partially overlapping class hierarchies. Hybrid patterns—abstract classes implementing interfaces, with composition for cross-cutting concerns—provide architectural flexibility without sacrificing type safety or code reuse. The key insight is that interfaces and abstract classes address orthogonal concerns. Interfaces define what objects can do—the contracts they satisfy. Abstract classes define how related objects implement shared behavior—the inheritance hierarchy. Combining both means separating contract definition from implementation strategy. interface Repository<T { findById id: string : Promise<T | null ; save entity: T : Promise<void ; delete id: string : Promise<void ; } interface Cacheable { getCacheKey id: string : string; invalidateCache id: string : void; } abstract class CachedRepository<T implements Repository<T , Cacheable { protected abstract tableName: string; private cache = new Map<string, T ; getCacheKey id: string : string { return ${this.tableName}:${id} ; } invalidateCache id: string : void { this.cache.delete this.getCacheKey id ; } async findById id: string : Promise<T | null { const cacheKey = this.getCacheKey id ; if this.cache.has cacheKey { return this.cache.get cacheKey ; } const entity = await this.fetchFromDb id ; if entity { this.cache.set cacheKey, entity ; } return entity; } protected abstract fetchFromDb id: string : Promise<T | null ; async save entity: T & { id: string } : Promise<void { await this.saveToDb entity ; this.cache.set this.getCacheKey entity.id , entity ; } protected abstract saveToDb entity: T : Promise<void ; async delete id: string : Promise<void { await this.deleteFromDb id ; this.invalidateCache id ; } protected abstract deleteFromDb id: string : Promise<void ; } The pattern separates concerns cleanly. The Repository interface defines the public contract that all repositories satisfy. The Cacheable interface defines cache management operations. CachedRepository implements both interfaces while providing shared caching logic. Subclasses implement only database operations—fetching, saving, and deleting—inheriting cache management for free. External code depends on interfaces, not the abstract base. A service accepting Repository<User works with any implementation—cached, uncached, or mock. The flexibility supports testing, allows performance optimizations without API changes, and enables gradual migration between implementation strategies. Decorator patterns extend the approach when cross-cutting concerns multiply. Instead of a single abstract base implementing all interfaces, separate decorators handle individual concerns. Each decorator implements the core interface and wraps another implementation, adding behavior without inheritance coupling. class LoggingRepository<T implements Repository<T { constructor private inner: Repository<T {} async findById id: string : Promise<T | null { console.log Finding entity ${id} ; const result = await this.inner.findById id ; console.log Found: ${result ? "yes" : "no"} ; return result; } async save entity: T : Promise<void { console.log "Saving entity" ; await this.inner.save entity ; console.log "Saved successfully" ; } async delete id: string : Promise<void { console.log Deleting entity ${id} ; await this.inner.delete id ; console.log "Deleted successfully" ; } } Decorators compose freely—wrap a repository in logging, then caching, then metrics. Each decorator remains simple, focused on a single concern. The pattern scales to dozens of cross-cutting behaviors without creating unmanageable inheritance hierarchies. Related content: TypeScript decorators https://jsmanifest.com/typescript-decorators-stable-real-world-use-cases explores decorator patterns in depth. Yes, TypeScript supports this pattern without restriction. A class can extend exactly one abstract class while implementing any number of interfaces, inheriting shared behavior from the base class while satisfying multiple contracts through interfaces. No, interfaces compile away entirely during TypeScript transpilation and produce zero JavaScript. They impose no memory overhead, no prototype chain traversal, and no bundle size increase—purely compile-time type checking. When you need both a public contract for external consumers and shared implementation for subclasses. The interface defines the API that all implementations satisfy; the abstract class provides base behavior that subclasses inherit. Yes, abstract classes support both abstract methods declared without implementation, forcing subclasses to define them and concrete methods with full implementation that subclasses inherit and optionally override . Define an interface matching the abstract class's public API, make the abstract class implement that interface, and gradually update consumers to depend on the interface type instead of the class type. Once all references use the interface, you can replace the abstract base with alternative implementations. That covers the essential patterns for abstract classes versus interfaces in TypeScript. The decision hinges on whether your contract requires shared executable code or purely structural conformance. Apply these patterns in production and the difference—fewer bugs, clearer intent, and faster iteration—will be immediate. When inheritance couples implementations too tightly, interfaces provide the flexibility to compose behavior from multiple sources. When duplication costs accumulate across related classes, abstract bases eliminate it without sacrificing type safety.