Polymorphism via Interfaces - Learning Module

Loading content...

0/246

Interfaces as Contracts

The Power of Behavioral Agreements

In the physical world, contracts are everywhere. When you plug a USB device into any computer, you're relying on a contract—a standardized agreement about how power and data flow through those pins. When you insert a credit card into any payment terminal worldwide, you're depending on contractual specifications that ensure interoperability. The device manufacturer and the terminal manufacturer never coordinated directly, yet their products work together seamlessly.

This is the essence of interfaces in object-oriented programming: they define behavioral contracts that allow unrelated components to work together without knowing each other's internal details.

Interfaces represent one of the most profound concepts in software engineering—the idea that we can specify what something can do without specifying how it does it. This separation of specification from implementation is the cornerstone of flexible, extensible software design.

What You Will Learn

By the end of this page, you will understand what interfaces truly represent at a conceptual level, how they function as behavioral contracts, why they're essential for genuine polymorphism, and how the contract metaphor guides proper interface design. You'll see why interfaces are often described as the most important abstraction mechanism in object-oriented programming.

What Is an Interface?

At its core, an interface is a collection of method signatures—declarations of methods without their implementations. It defines a set of operations that any implementing class must provide, but says nothing about how those operations should be performed.

Think of an interface as a job description. A job description for a "driver" might specify:

Must be able to start the vehicle
Must be able to accelerate
Must be able to brake
Must be able to turn left and right

This job description doesn't care whether the driver learned at a professional school or from a parent, whether they prefer defensive or aggressive driving styles, or what their personal philosophy about lane changes is. It only specifies the capabilities required.

interface-basics.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// An interface defines WHAT operations are available
// It says nothing about HOW they're implemented
 
interface Driver {
    startVehicle(): void;
    accelerate(speed: number): void;
    brake(): void;
    turn(direction: 'left' | 'right'): void;
}
 
// Any class implementing Driver MUST provide all these methods
class ProfessionalDriver implements Driver {
    startVehicle(): void {
        console.log("Professional startup sequence initiated...");
        // Thorough pre-drive checks, mirror adjustment, etc.
    }
    
    accelerate(speed: number): void {
        console.log(`Smoothly accelerating to ${speed} km/h`);
        // Gradual, fuel-efficient acceleration
    }
    
    brake(): void {
        console.log("Applying progressive braking technique");
        // Engine braking followed by gradual pedal application
    }
    
    turn(direction: 'left' | 'right'): void {
        console.log(`Executing precise ${direction} turn with proper signaling`);
        // Perfect timing, signaling, mirror checks
    }
}
 
class NoviceDriver implements Driver {
    startVehicle(): void {
        console.log("Uh... which pedal was the clutch again?");
        // Stalls twice before successfully starting
    }
    
    accelerate(speed: number): void {
        console.log(`Lurching forward toward ${speed} km/h`);
        // Jerky acceleration with occasional stalling
    }
    
    brake(): void {
        console.log("STOPPING HARD!");
        // Abrupt braking that tests seatbelt effectiveness
    }
    
    turn(direction: 'left' | 'right'): void {
        console.log(`Making a ${direction} turn... hopefully`);
        // Wide turns, uncertain timing
    }
}
 
// Both are valid Drivers - the interface doesn't care about skill level
function conductDrivingTest(driver: Driver): void {
    driver.startVehicle();
    driver.accelerate(50);
    driver.turn('left');
    driver.brake();
}

The profound insight here is that conductDrivingTest function doesn't know or care which type of driver it receives. It only knows that whatever object it receives can do the things a Driver should be able to do. The actual behavior—whether the driving is smooth or jerky—is determined by the specific implementation.

This is polymorphism in its purest form: one interface, many implementations.

The Contract Metaphor Deep Dive

The term "contract" isn't just a metaphor—it captures the legal and binding nature of interfaces. When a class declares that it implements an interface, it's making a binding promise to the rest of the system:

"I solemnly swear that I will provide implementations for every method declared in this interface, and any code that uses this interface can rely on me to fulfill these obligations."

Let's explore what this contract entails and the obligations it creates:

Contract Obligations

•Syntactic Obligation — The implementing class MUST provide methods with exactly the signatures declared in the interface. Wrong parameter types, wrong return types, or missing methods are contractual violations caught at compile time.
•Semantic Obligation — The implementing methods SHOULD behave in ways consistent with the interface's intended purpose. If brake() accelerates the car, you've technically fulfilled the syntactic contract but violated the semantic one.
•Availability Guarantee — Any code holding a reference to the interface type can safely call any interface method without checking whether it exists. The compiler has already verified fulfillment.
•Substitutability Promise — Any implementation can be used wherever the interface type is expected. The client code will work correctly regardless of which specific implementation is provided.

Syntactic vs Semantic Contracts

Compilers can only verify syntactic contracts—that methods exist with correct signatures. Semantic contracts—that methods behave correctly—cannot be verified by compilers. A sort() method that reverses instead of sorts still compiles. Upholding semantic contracts requires developer discipline, documentation, and testing. This is why interface documentation and clear naming are crucial.

contract-obligations.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
// The PaymentProcessor interface establishes a contract
interface PaymentProcessor {
    // Methods define capabilities any processor must have
    processPayment(amount: number, currency: string): PaymentResult;
    refundPayment(transactionId: string): RefundResult;
    getTransactionStatus(transactionId: string): TransactionStatus;
}
 
interface PaymentResult {
    success: boolean;
    transactionId: string;
    timestamp: Date;
}
 
interface RefundResult {
    success: boolean;
    refundId: string;
    originalTransactionId: string;
}
 
type TransactionStatus = 'pending' | 'completed' | 'failed' | 'refunded';
 
// Stripe implementation fulfills the contract
class StripeProcessor implements PaymentProcessor {
    processPayment(amount: number, currency: string): PaymentResult {
        // Stripe-specific API calls
        console.log(`Processing ${amount} ${currency} via Stripe`);
        return {
            success: true,
            transactionId: `stripe_${Date.now()}`,
            timestamp: new Date()
        };
    }
    
    refundPayment(transactionId: string): RefundResult {
        // Stripe-specific refund logic
        console.log(`Refunding ${transactionId} via Stripe`);
        return {
            success: true,
            refundId: `stripe_refund_${Date.now()}`,
            originalTransactionId: transactionId
        };
    }
    
    getTransactionStatus(transactionId: string): TransactionStatus {
        // Stripe-specific status check
        return 'completed';
    }
}
 
// PayPal implementation fulfills the SAME contract, differently
class PayPalProcessor implements PaymentProcessor {
    processPayment(amount: number, currency: string): PaymentResult {
        // PayPal-specific API calls
        console.log(`Processing ${amount} ${currency} via PayPal`);
        return {
            success: true,
            transactionId: `paypal_${Date.now()}`,
            timestamp: new Date()
        };
    }
    
    refundPayment(transactionId: string): RefundResult {
        // PayPal-specific refund logic  
        console.log(`Refunding ${transactionId} via PayPal`);
        return {
            success: true,
            refundId: `paypal_refund_${Date.now()}`,
            originalTransactionId: transactionId
        };
    }
    
    getTransactionStatus(transactionId: string): TransactionStatus {
        // PayPal-specific status check
        return 'completed';
    }
}
 
// Client code depends ONLY on the contract, not specific implementations
class CheckoutService {
    private processor: PaymentProcessor; // Dependency on interface, not class
    
    constructor(processor: PaymentProcessor) {
        this.processor = processor;
    }
    
    checkout(amount: number): PaymentResult {
        // Works with ANY PaymentProcessor implementation
        return this.processor.processPayment(amount, 'USD');
    }
}
 
// Usage - easily swap implementations
const stripeCheckout = new CheckoutService(new StripeProcessor());
const paypalCheckout = new CheckoutService(new PayPalProcessor());
 
// Both work identically from the client's perspective
stripeCheckout.checkout(99.99);
paypalCheckout.checkout(99.99);

Why Contracts Enable Polymorphism

The contract metaphor illuminates why interfaces are the foundation of true polymorphism. When code depends on an interface rather than a concrete class, it's depending on a guaranteed capability rather than a specific implementation.

This creates the conditions for polymorphism:

1. Substitutability: Any implementation of the interface can be substituted for any other. Client code treats all implementations uniformly because they all fulfill the same contract.

2. Extensibility: New implementations can be added without modifying existing code. The new class simply signs the same contract.

3. Testability: Test implementations (mocks, stubs, fakes) can be substituted for production implementations because tests can provide their own contract fulfillment.

4. Decoupling: Client code is insulated from implementation changes. As long as the contract is maintained, internal implementations can evolve freely.

Contract-Based Polymorphism vs Direct Dependency
Aspect	Direct Class Dependency	Interface Contract Dependency
Coupling	Tight coupling to specific implementation	Loose coupling to behavioral contract
Substitutability	Cannot substitute different implementations	Any implementation freely substitutable
Testing	Must use production classes or invasive mocking	Easy injection of test doubles
Extensibility	Changes require modifying client code	New implementations added without changes
Flexibility	Locked to one behavior	Behavior varies by implementation
Maintenance	Ripple effects from implementation changes	Isolated changes within implementations

Consider what happens when you depend directly on StripeProcessor class versus the PaymentProcessor interface:

Direct Dependency on StripeProcessor:

Your code only works with Stripe
Adding PayPal requires changing your code
Testing requires real Stripe API calls or complex mocking
Stripe internal changes might break your code

Contract Dependency on PaymentProcessor:

Your code works with any payment processor
Adding PayPal requires zero changes to your code
Testing uses a simple MockProcessor implementing the interface
Any processor's internal changes are invisible to your code

This is the transformative power of programming to interfaces: your code becomes oblivious to implementation details while remaining fully functional.

The Dependency Inversion Insight

When you depend on interfaces instead of concrete classes, you're inverting the traditional dependency direction. Instead of high-level code depending on low-level implementation details, both depend on the abstraction (interface). This is the Dependency Inversion Principle in action—one of the most important principles in software architecture.

Anatomy of a Well-Designed Interface

Not all interfaces are created equal. A well-designed interface is like a well-drafted legal contract: clear, focused, and enforceable. Let's examine the characteristics that distinguish excellent interface design from poor design.

Hallmarks of Excellent Interface Design

•Cohesion — All methods in the interface relate to a single, well-defined capability. An interface should represent ONE thing that an object can do, not a grab-bag of unrelated operations.
•Minimalism — Include only the methods genuinely needed by clients. Every additional method is a burden on implementers and increases coupling. Favor small, focused interfaces.
•Clarity — Method names, parameters, and return types should clearly communicate purpose. A reader should understand what the interface does without examining implementations.
•Stability — Interfaces are hard to change once published because every implementer must update. Design interfaces to be stable and think carefully before adding methods.
•Implementation Independence — Interface design should not leak implementation assumptions. Don't include methods that only make sense for certain implementation strategies.

Poorly Designed Interface

•Too many methods ("fat" interface)
•Methods for unrelated capabilities
•Implementation-specific methods
•Unclear method purposes
•Frequently changing contract

Well-Designed Interface

•Minimal, focused method set
•Single cohesive capability
•Implementation-agnostic design
•Self-documenting method names
•Stable, rarely-changing contract

interface-design-comparison.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ❌ POOR: Fat interface with unrelated responsibilities
interface BadUserService {
    // User CRUD operations
    createUser(data: UserData): User;
    getUser(id: string): User;
    updateUser(id: string, data: UserData): User;
    deleteUser(id: string): void;
    
    // Authentication - different responsibility!
    login(email: string, password: string): Session;
    logout(sessionId: string): void;
    
    // Email - different responsibility!
    sendWelcomeEmail(user: User): void;
    sendPasswordReset(email: string): void;
    
    // Database-specific - implementation leak!
    beginTransaction(): void;
    commitTransaction(): void;
    rollbackTransaction(): void;
}
 
// ✅ GOOD: Separate, focused interfaces
interface UserRepository {
    create(data: UserData): User;
    findById(id: string): User | null;
    update(id: string, data: Partial<UserData>): User;
    delete(id: string): void;
}
 
interface Authenticator {
    login(credentials: Credentials): Session;
    logout(sessionId: string): void;
    validateSession(sessionId: string): boolean;
}
 
interface NotificationSender {
    send(recipient: string, message: Message): void;
}
 
// Each interface:
// - Has a single, clear purpose
// - Contains only related methods
// - Makes no implementation assumptions
// - Is easy to implement and test
 
// Classes can implement multiple focused interfaces as needed
class UserService implements UserRepository {
    create(data: UserData): User { /* ... */ }
    findById(id: string): User | null { /* ... */ }
    update(id: string, data: Partial<UserData>): User { /* ... */ }
    delete(id: string): void { /* ... */ }
}
 
class AuthService implements Authenticator {
    login(credentials: Credentials): Session { /* ... */ }
    logout(sessionId: string): void { /* ... */ }
    validateSession(sessionId: string): boolean { /* ... */ }
}

The Interface Segregation Principle

The SOLID principles include the Interface Segregation Principle (ISP), which states:

"Clients should not be forced to depend on interfaces they do not use."

This principle captures a critical insight about interface design: large, general-purpose interfaces force implementers to provide functionality they may not need, and force clients to depend on methods they never call.

Consider what happens when you have a "god interface" with 20 methods:

Problems with Fat Interfaces

•Implementer Burden: Classes must implement all 20 methods, even if they only need 5. The other 15 become stub implementations or throw exceptions.
•False Coupling: Clients depending on the interface are technically coupled to all 20 methods, even if they only use 2.
•Change Amplification: Adding a 21st method requires updating every implementer, even if most don't care about the new capability.
•Reduced Clarity: It's harder to understand what the interface represents when it contains wildly different operations.
•Testing Complexity: Test doubles must implement all 20 methods even when testing code that only uses 3.

interface-segregation.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
// ❌ Violates Interface Segregation Principle
interface Machine {
    print(document: Document): void;
    scan(): Image;
    fax(document: Document, number: string): void;
    copy(document: Document): void;
    staple(documents: Document[]): void;
}
 
// Problem: A simple printer must implement fax() and scan()
class SimplePrinter implements Machine {
    print(document: Document): void {
        // This is what we actually do
    }
    
    scan(): Image {
        throw new Error("SimplePrinter cannot scan!");
    }
    
    fax(document: Document, number: string): void {
        throw new Error("SimplePrinter cannot fax!");
    }
    
    copy(document: Document): void {
        throw new Error("SimplePrinter cannot copy!");
    }
    
    staple(documents: Document[]): void {
        throw new Error("SimplePrinter cannot staple!");
    }
}
 
// ✅ Follows Interface Segregation Principle
interface Printer {
    print(document: Document): void;
}
 
interface Scanner {
    scan(): Image;
}
 
interface Fax {
    fax(document: Document, number: string): void;
}
 
// Simple printer only implements what it can do
class SimplePrinter implements Printer {
    print(document: Document): void {
        console.log("Printing document...");
    }
}
 
// Multi-function device implements multiple interfaces
class MultiFunctionDevice implements Printer, Scanner, Fax {
    print(document: Document): void {
        console.log("Printing document...");
    }
    
    scan(): Image {
        console.log("Scanning...");
        return new Image();
    }
    
    fax(document: Document, number: string): void {
        console.log(`Faxing to ${number}...`);
    }
}
 
// Client code can depend on exactly what it needs
function printReport(printer: Printer, report: Document) {
    // Only depends on Printer, doesn't care about scan/fax capability
    printer.print(report);
}
 
// Works with SimplePrinter (just a printer)
// Also works with MultiFunctionDevice (printer + more)
printReport(new SimplePrinter(), report);
printReport(new MultiFunctionDevice(), report);

Small Interfaces, Big Flexibility

When you segregate interfaces by capability, you create building blocks that can be composed freely. A class can implement exactly the interfaces that match its actual capabilities, and clients can depend only on the capabilities they need. This principle will be explored in depth in the SOLID principles chapter.

Interfaces vs Type Aliases (TypeScript Perspective)

In TypeScript, you might wonder about the difference between interface and type since both can define object shapes. While they share many capabilities, they have distinct purposes and trade-offs:

Interface vs Type Alias Comparison
Aspect	Interface	Type Alias
Primary Purpose	Define object shapes and contracts	Name any type (objects, unions, primitives, etc.)
Extension	Uses `extends` keyword, can extend multiple	Uses intersections (`&`) for composition
Declaration Merging	Multiple declarations merge into one	Cannot be merged, must be unique
Class Implementation	Classes can `implement` interfaces	Classes can `implement` type aliases (if object types)
Computed Properties	Cannot use computed properties	Can use `in` for mapped types
Unions	Cannot represent union types directly	Can represent union types naturally
Best For	Object shapes, class contracts, public APIs	Complex types, unions, mapped types

interface-vs-type.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// INTERFACE: Best for object shapes and contracts
interface User {
    id: string;
    name: string;
    email: string;
}
 
// Declaration merging - interfaces can be extended across files
interface User {
    age?: number;  // This MERGES with the above definition
}
 
// Extending interfaces
interface Admin extends User {
    permissions: string[];
}
 
// TYPE ALIAS: Best for complex types, unions, utilities
type Status = 'active' | 'inactive' | 'pending';  // Union type
 
type Nullable<T> = T | null;  // Generic type alias
 
type UserOrAdmin = User | Admin;  // Union of interfaces
 
// Intersection types with type aliases
type UserWithMetadata = User & {
    createdAt: Date;
    updatedAt: Date;
};
 
// Mapped types (only possible with type aliases)
type Readonly<T> = {
    readonly [P in keyof T]: T[P];
};
 
type PartialUser = Partial<User>;
 
// RECOMMENDATION:
// - Use INTERFACES for defining the shapes of objects that 
//   classes will implement (contracts)
// - Use TYPE ALIASES for:
//   - Union types
//   - Intersection types  
//   - Mapped/conditional types
//   - Aliasing primitives or tuples
 
// For polymorphism and contracts, interfaces are generally preferred
interface Repository<T> {
    findById(id: string): T | null;
    save(entity: T): T;
    delete(id: string): void;
}
 
class UserRepository implements Repository<User> {
    findById(id: string): User | null { /* ... */ }
    save(entity: User): User { /* ... */ }
    delete(id: string): void { /* ... */ }
}

Practical Guideline

For defining behavioral contracts that classes will implement—the topic of this module—use interfaces. They communicate intent more clearly ('this is a contract that must be fulfilled') and support declaration merging which can be valuable for extending third-party types. Use type aliases when you need unions, mapped types, or other advanced type operations.

Real-World Interface Examples

Let's examine interfaces from real-world systems to see how contracts enable flexible, maintainable designs. These examples illustrate how interfaces solve genuine engineering problems.

real-world-interfaces.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
// EXAMPLE 1: Logger Interface
// Multiple logging implementations (console, file, cloud service)
// can be swapped without changing application code
 
interface Logger {
    debug(message: string, context?: object): void;
    info(message: string, context?: object): void;
    warn(message: string, context?: object): void;
    error(message: string, error?: Error, context?: object): void;
}
 
class ConsoleLogger implements Logger {
    debug(message: string, context?: object): void {
        console.debug(`[DEBUG] ${message}`, context);
    }
    info(message: string, context?: object): void {
        console.info(`[INFO] ${message}`, context);
    }
    warn(message: string, context?: object): void {
        console.warn(`[WARN] ${message}`, context);
    }
    error(message: string, error?: Error, context?: object): void {
        console.error(`[ERROR] ${message}`, error, context);
    }
}
 
class CloudWatchLogger implements Logger {
    // Sends logs to AWS CloudWatch instead of console
    // Same interface, completely different implementation
    debug(message: string, context?: object): void { /* AWS API calls */ }
    info(message: string, context?: object): void { /* AWS API calls */ }
    warn(message: string, context?: object): void { /* AWS API calls */ }
    error(message: string, error?: Error, context?: object): void { /* AWS API calls */ }
}
 
// EXAMPLE 2: Event Emitter Interface
// Different event systems can be substituted
 
interface EventEmitter<Events extends Record<string, unknown>> {
    on<K extends keyof Events>(event: K, handler: (data: Events[K]) => void): void;
    off<K extends keyof Events>(event: K, handler: (data: Events[K]) => void): void;
    emit<K extends keyof Events>(event: K, data: Events[K]): void;
}
 
// EXAMPLE 3: Cache Interface
// In-memory, Redis, Memcached - all implement the same contract
 
interface Cache<T> {
    get(key: string): Promise<T | null>;
    set(key: string, value: T, ttlSeconds?: number): Promise<void>;
    delete(key: string): Promise<boolean>;
    has(key: string): Promise<boolean>;
    clear(): Promise<void>;
}
 
class InMemoryCache<T> implements Cache<T> {
    private store = new Map<string, { value: T; expiry?: number }>();
    
    async get(key: string): Promise<T | null> {
        const item = this.store.get(key);
        if (!item) return null;
        if (item.expiry && Date.now() > item.expiry) {
            this.store.delete(key);
            return null;
        }
        return item.value;
    }
    
    async set(key: string, value: T, ttlSeconds?: number): Promise<void> {
        this.store.set(key, {
            value,
            expiry: ttlSeconds ? Date.now() + ttlSeconds * 1000 : undefined
        });
    }
    
    async delete(key: string): Promise<boolean> {
        return this.store.delete(key);
    }
    
    async has(key: string): Promise<boolean> {
        return this.store.has(key);
    }
    
    async clear(): Promise<void> {
        this.store.clear();
    }
}
 
class RedisCache<T> implements Cache<T> {
    // Connects to Redis instead of in-memory storage
    // Same interface, distributed caching capability
    async get(key: string): Promise<T | null> { /* Redis calls */ }
    async set(key: string, value: T, ttlSeconds?: number): Promise<void> { /* Redis calls */ }
    async delete(key: string): Promise<boolean> { /* Redis calls */ }
    async has(key: string): Promise<boolean> { /* Redis calls */ }
    async clear(): Promise<void> { /* Redis calls */ }
}
 
// Application code works with any cache implementation
class ProductService {
    constructor(private cache: Cache<Product>) {}
    
    async getProduct(id: string): Promise<Product | null> {
        // Check cache first
        const cached = await this.cache.get(id);
        if (cached) return cached;
        
        // Fetch from database
        const product = await this.fetchFromDatabase(id);
        if (product) {
            await this.cache.set(id, product, 3600); // 1 hour TTL
        }
        return product;
    }
}

Summary: Interfaces as Contracts

We've explored the foundational concept of interfaces as contracts—the mechanism that enables the most powerful and flexible form of polymorphism in object-oriented design.

Key Takeaways

•Interfaces define behavioral contracts — They specify WHAT operations are available without dictating HOW they're implemented.
•Contracts have syntactic and semantic components — Compilers verify syntax; developers must uphold semantic correctness through discipline and testing.
•Contracts enable polymorphism — Any implementation can be substituted for another, enabling flexibility, testability, and extensibility.
•Well-designed interfaces are small and focused — Follow Interface Segregation: clients should only depend on methods they use.
•Programming to interfaces decouples systems — Client code becomes oblivious to implementation details while remaining fully functional.
•Interfaces are the foundation of dependency inversion — High-level and low-level code both depend on abstractions, not on each other.

What's Next:

Now that we understand interfaces as contracts, we'll explore one of their most powerful capabilities: implementing multiple interfaces. Unlike single inheritance, a class can fulfill many interface contracts simultaneously, enabling rich polymorphic behavior that would be impossible with class inheritance alone.

Page Complete

You now understand the fundamental concept of interfaces as behavioral contracts. This understanding is essential for everything that follows—from multiple interface implementation to programming-to-interfaces principles. The contract metaphor will guide you in designing flexible, maintainable systems.