Problem — Abstraction Coupled to Implementation - Bridge Pattern | OneNoughtOne

0/246

System Design (LLD)Structural Patterns

Bridge Pattern

LevelIntermediate

Duration60 mins

TopicStructural Patterns

1 / 4

Problem — Abstraction Coupled to Implementation

The Hidden Coupling That Haunts Your Hierarchies

You're designing a drawing application. You have shapes—circles, rectangles, triangles. Simple enough, you create a Shape base class with derived classes for each shape type. Then the product manager asks for platform support: Windows and Linux. No problem—you create platform-specific implementations. For circles on Windows. For circles on Linux. For rectangles on Windows. For rectangles on Linux.

And suddenly you're drowning.

What started as a clean hierarchy has exploded into a matrix of classes. Add a new shape, and you must create implementations for every platform. Add a new platform, and you must create implementations for every shape. You've fallen into one of object-oriented design's most insidious traps: abstraction coupled to implementation.

What You Will Learn

By the end of this page, you will understand the fundamental problem that the Bridge Pattern solves: why inheritance-based designs create explosive coupling between abstractions and implementations, how this coupling manifests as a multiplicative explosion of classes, and why traditional inheritance hierarchies are fundamentally inadequate for two-dimensional variation. This understanding is essential before we explore the Bridge Pattern's elegant solution.

The Cartesian Product Problem

At the heart of abstraction-implementation coupling lies a mathematical inevitability: the Cartesian product. When you have M variations along one dimension (e.g., shape types) and N variations along another dimension (e.g., rendering platforms), inheritance forces you to create M × N concrete classes.

This isn't merely inconvenient—it's fundamentally hostile to maintainability.

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
// Starting with a simple hierarchy
abstract class Shape {
    abstract draw(): void;
}
 
// Two shape types × two platforms = FOUR classes (minimum)
class WindowsCircle extends Shape {
    draw(): void {
        // Windows-specific circle rendering
        console.log("Drawing circle using Windows GDI");
    }
}
 
class LinuxCircle extends Shape {
    draw(): void {
        // Linux-specific circle rendering  
        console.log("Drawing circle using Linux X11");
    }
}
 
class WindowsRectangle extends Shape {
    draw(): void {
        // Windows-specific rectangle rendering
        console.log("Drawing rectangle using Windows GDI");
    }
}
 
class LinuxRectangle extends Shape {
    draw(): void {
        // Linux-specific rectangle rendering
        console.log("Drawing rectangle using Linux X11");
    }
}
 
// Add macOS? Add 2 more classes (now 6 total)
// Add Triangle? Add 3 more classes (now 9 total)
// Add WebGL platform? You see where this is going...

The mathematics are unforgiving:

Consider a modest drawing application with:

5 shape types (Circle, Rectangle, Triangle, Polygon, Ellipse)
4 rendering platforms (Windows, Linux, macOS, WebGL)
3 rendering modes (Filled, Outlined, Gradient)

With pure inheritance, you need 5 × 4 × 3 = 60 classes. Each class contains duplicated logic. Each new variation affects every existing combination. The maintenance burden grows geometrically while functionality grows linearly.

Class Explosion in Inheritance-Based Design
Shapes	Platforms	Modes	Total Classes	Classes per New Shape	Classes per New Platform
3	2	1	6	2	3
5	3	1	15	3	5
5	4	1	20	4	5
5	4	3	60	12	15
10	5	3	150	15	30

The Scaling Wall

This isn't hypothetical future pain—it's immediate design paralysis. When adding a single new feature requires creating dozens of classes that differ only in small ways, developers start avoiding new features. The codebase becomes rigid not because it's technically locked, but because modification costs are prohibitively high.

Inheritance as a Single-Dimensional Tool

To understand why this problem is inherent to inheritance—not a misuse of it—we must examine what inheritance actually models.

Inheritance expresses exactly one thing: specialization along a single dimension.

When Circle extends Shape, we're saying "Circle is a more specific kind of Shape." The relationship is vertical—child below parent on a single axis of variation. But real-world design problems frequently involve multiple independent axes of variation. Shapes vary by geometry. Rendering varies by platform. Styles vary by visual treatment. These aren't nested specializations—they're orthogonal concerns.

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
// Inheritance can only model ONE dimension at a time
// We're trying to express TWO independent concerns:
 
// Dimension 1: Shape Geometry
// - Circle (defined by center and radius)
// - Rectangle (defined by width and height)
// - Triangle (defined by three vertices)
 
// Dimension 2: Rendering Platform
// - Windows (GDI/Direct2D APIs)
// - Linux (X11/Cairo APIs)
// - WebGL (Canvas/WebGL APIs)
 
// Inheritance forces us to FLATTEN these into one hierarchy:
// 
//                    Shape
//         ┌───────────┼───────────┐
//      Circle     Rectangle    Triangle
//    ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
// WinCircle LinCircle WinRect LinRect WinTri LinTri
//
// The hierarchy encodes Shape-type as primary, Platform as secondary
// But this is arbitrary! We could have flattened the other way:
//
//                    Shape
//         ┌───────────┼───────────┐
//      Windows      Linux       WebGL
//    ┌────┴────┐   ┌────┴────┐
// WinCircle WinRect LinCircle LinRect ...
//
// Neither is correct because the problem ISN'T hierarchical!

The geometric analogy:

Imagine trying to represent a two-dimensional grid using only vertical stacks. You could place columns side-by-side, but you've lost the structural integrity of the grid. You can't traverse rows naturally. You can't add a row without modifying every column.

This is exactly what inheritance does to multi-dimensional variation. It collapses a matrix into chains, destroying the independence that made each dimension meaningful.

Symptoms of Dimensional Mismatch

•Repetitive Code Across Siblings — Multiple classes contain nearly identical code, differing only in the 'other' dimension's specifics. Every shape has the same platform-specific rendering boilerplate.
•Synchronization Burden — Bug fixes must be applied to M × N classes. Forgetting one creates silent inconsistency that surfaces as platform-specific bugs.
•Arbitrary Primary Dimension — The hierarchy privileges one dimension over another, but the choice is arbitrary. Either flattening produces the same problems.
•Deep, Brittle Hierarchies — Adding dimensions means adding depth, making the inheritance chain fragile. Changes near the root cascade unpredictably.
•Testing Combinatorial Explosion — Each concrete class needs tests. M × N combinations mean M × N test suites with mostly-duplicated assertions.

Real-World Manifestations

The abstraction-implementation coupling problem isn't confined to academic examples. It appears throughout production software, often disguised until the maintenance burden becomes crushing.

Production Examples of Coupling Explosion

•UI Frameworks and Themes — Button, TextField, Dropdown × LightTheme, DarkTheme, HighContrast × Windows, macOS, Linux. A modest UI toolkit can easily reach hundreds of concrete classes.
•Messaging Systems — EmailNotifier, SMSNotifier, PushNotifier × AWS, Azure, GCP × Sync, Async, Batched. Each combination requires explicit implementation.
•Persistence Layers — UserRepository, OrderRepository, ProductRepository × SQL, MongoDB, Redis × ReadReplica, Primary, Cached. The data layer multiplies across storage backends.
•Report Generators — SalesReport, InventoryReport, FinanceReport × PDF, Excel, HTML, CSV × Detailed, Summary, Executive. Business reports explode across formats and detail levels.
•Media Players — AudioPlayer, VideoPlayer × MP3, AAC, FLAC, H264, HEVC × Hardware, Software decoding. Codecs and playback modes multiply independently.

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
// Starting design: simple and reasonable
abstract class Notifier {
    abstract send(message: string, recipient: string): Promise<void>;
}
 
class EmailNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // Send email
    }
}
 
class SMSNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // Send SMS
    }
}
 
// Requirement: Support multiple cloud providers
// "We need AWS for region A, Azure for region B"
 
class AWSEmailNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // AWS SES email implementation
    }
}
 
class AzureEmailNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // Azure Communication Services email implementation
    }
}
 
class AWSSMSNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // AWS SNS SMS implementation
    }
}
 
class AzureSMSNotifier extends Notifier {
    async send(message: string, recipient: string): Promise<void> {
        // Azure Communication Services SMS implementation
    }
}
 
// Requirement: Add push notifications
// Now we need AWSPushNotifier, AzurePushNotifier...
 
// Requirement: Add GCP support
// Now we need GCPEmailNotifier, GCPSMSNotifier, GCPPushNotifier...
 
// Requirement: Support batch vs individual sending
// Now EVERY class above needs a batch variant...
 
// Final count for 3 channels × 3 providers × 2 modes = 18 classes
// Each class is mostly copy-paste with small variations

The Copy-Paste Trap

When developers face 18 nearly-identical classes, copy-paste becomes the path of least resistance. But each paste creates a synchronization liability. When the email template format changes, will all 6 email classes be updated consistently? When AWS updates their SDK, will all 6 AWS classes be patched? History shows: they won't.

The Tight Coupling Mechanics

Let's examine precisely how abstraction and implementation become entangled through inheritance, and why this coupling is so pernicious.

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
// Consider this seemingly reasonable class:
class WindowsCircle extends Shape {
    private readonly gdiHandle: number;
    private readonly antiAliasEnabled: boolean;
    
    constructor(private center: Point, private radius: number) {
        super();
        // Windows-specific initialization
        this.gdiHandle = this.initializeGDI();
        this.antiAliasEnabled = this.checkAntiAliasSupport();
    }
    
    draw(): void {
        if (this.antiAliasEnabled) {
            this.drawWithAntiAlias();
        } else {
            this.drawBasic();
        }
    }
    
    private initializeGDI(): number {
        // Platform-specific handle acquisition
        return 0; // Placeholder
    }
    
    private checkAntiAliasSupport(): boolean {
        // Platform-specific capability check
        return true;
    }
    
    private drawWithAntiAlias(): void {
        // Specialized Windows rendering path
    }
    
    private drawBasic(): void {
        // Basic Windows rendering path
    }
    
    // Circle-specific operations
    getArea(): number {
        return Math.PI * this.radius ** 2;
    }
    
    getCircumference(): number {
        return 2 * Math.PI * this.radius;
    }
}
 
// PROBLEM 1: Geometric logic (getArea, getCircumference) is duplicated
// in LinuxCircle, WebGLCircle, etc. Change the formula? Change everywhere.
 
// PROBLEM 2: Platform logic (GDI initialization, anti-alias checks) is 
// duplicated in WindowsRectangle, WindowsTriangle, etc.
 
// PROBLEM 3: The class has TWO reasons to change:
// - Circle geometry logic changes (math, properties)
// - Windows rendering logic changes (API updates, capability changes)
// This violates the Single Responsibility Principle.
 
// PROBLEM 4: Testing requires BOTH concerns simultaneously.
// Can't test circle math without Windows. Can't test Windows rendering
// without specific shapes and their geometric properties.

The four binding forces:

Tight coupling in inheritance manifests through multiple mechanisms:

Compile-Time Binding — The concrete class is known at compile time. You can't substitute a different implementation without changing the code. new WindowsCircle() is hardcoded—there's no seam for injection.
Identity Conflation — The class's identity merges both dimensions. It's not a Circle that uses Windows rendering; it is a WindowsCircle. This makes decomposition conceptually awkward.
Lifecycle Coupling — The object's lifecycle binds both concerns. Creating a circle requires initializing Windows resources. Destroying it requires cleanup of both. You can't manage them independently.
Testing Coupling — Unit testing requires both halves. Mocking is difficult because behaviors are intertwined. Integration testing is forced where unit testing should suffice.

Indicators of Tight Coupling

•Classes have multiple 'and' in their names: WindowsFilledCircle
•Constructor performs multi-concern initialization
•Methods mix business logic with infrastructure calls
•Changes require synchronized edits across sibling classes
•Can't test one aspect without instantiating the full object

Signs of Proper Separation

•Classes represent single concepts
•Concerns are injectable/configurable
•Changes are localized to relevant classes
•Each class has one reason to change
•Aspects are independently testable

Why Simple Fixes Fail

Developers often attempt to work around the explosion without fundamentally restructuring. These approaches provide temporary relief but don't solve the core problem.

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
// "Let's just use conditionals to avoid multiple classes"
class Circle extends Shape {
    private platform: 'windows' | 'linux' | 'webgl';
    
    constructor(private center: Point, private radius: number, platform: string) {
        super();
        this.platform = platform as any;
    }
    
    draw(): void {
        switch (this.platform) {
            case 'windows':
                this.drawWindows();
                break;
            case 'linux':
                this.drawLinux();
                break;
            case 'webgl':
                this.drawWebGL();
                break;
        }
    }
    
    private drawWindows(): void { /* ... */ }
    private drawLinux(): void { /* ... */ }
    private drawWebGL(): void { /* ... */ }
}
 
// PROBLEMS:
// 1. Every shape class has the same switch statement
// 2. Adding a platform requires modifying EVERY shape class
// 3. The class violates Open-Closed Principle
// 4. All platform-specific code is in every class (bloat)
// 5. Type safety is weakened (runtime string matching)

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
// "Let's mix in platform capabilities"
// TypeScript doesn't support multiple inheritance, but imagine it did:
 
// class WindowsCircle extends Circle, WindowsPlatform { }
 
// Even with mixins, we have problems:
const WindowsMixin = <T extends Constructor<Shape>>(Base: T) => {
    return class extends Base {
        initPlatform(): void {
            // Windows initialization
        }
        
        renderPlatform(geometry: any): void {
            // Windows rendering
        }
    };
};
 
class Circle extends Shape {
    constructor(private center: Point, private radius: number) {
        super();
    }
    
    getGeometry() {
        return { type: 'circle', center: this.center, radius: this.radius };
    }
    
    draw(): void {
        // How do we call the platform's renderPlatform?
        // We need to know the mixin is applied, but the base class can't assume it
    }
}
 
const WindowsCircle = WindowsMixin(Circle);
 
// PROBLEMS:
// 1. Still creates M × N combinations (just via composition of mixins)
// 2. Mixin conflicts and diamond problems
// 3. Type inference becomes complex
// 4. The class explosion moves to instantiation sites
// 5. Base class can't rely on mixin capabilities

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
// "Let's use hooks that subclasses override"
abstract class Shape {
    draw(): void {
        this.initializeRendering();
        this.performDraw();
        this.cleanupRendering();
    }
    
    protected abstract initializeRendering(): void;
    protected abstract performDraw(): void;
    protected abstract cleanupRendering(): void;
}
 
// This helps structure the algorithm, but doesn't reduce class count
// We still need WindowsCircle, LinuxCircle, etc.
 
class WindowsCircle extends Shape {
    protected initializeRendering(): void {
        // Windows GDI setup
    }
    
    protected performDraw(): void {
        // Windows circle drawing
    }
    
    protected cleanupRendering(): void {
        // Windows GDI cleanup  
    }
}
 
// PROBLEMS:
// 1. Same M × N classes still required
// 2. Hook methods are duplicated across shape variants
// 3. Adding a hook point requires updating all concrete classes
// 4. Rigid algorithm structure limits platform-specific optimization

Why These Fail

Each workaround treats symptoms rather than the disease. The fundamental issue isn't how we organize the inheritance—it's that inheritance itself is the wrong tool for multi-dimensional variation. What we need is a way to compose independent hierarchies rather than merge them into one.

The Fragile Base Class Problem

Tight coupling between abstraction and implementation exacerbates one of inheritance's most notorious issues: the fragile base class problem. This occurs when changes to a base class break subclasses in unexpected ways.

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
// Original design
abstract class Shape {
    abstract draw(): void;
    
    render(): void {
        console.log("Preparing canvas...");
        this.draw();
        console.log("Render complete.");
    }
}
 
class WindowsCircle extends Shape {
    draw(): void {
        this.setupGDI();
        this.drawCircle();
        this.teardownGDI();
    }
    
    private setupGDI(): void { /* ... */ }
    private drawCircle(): void { /* ... */ }
    private teardownGDI(): void { /* ... */ }
}
 
// 6 months later: "We need pre-render and post-render hooks"
abstract class Shape {
    abstract draw(): void;
    
    render(): void {
        console.log("Preparing canvas...");
        this.preRender();  // NEW HOOK
        this.draw();
        this.postRender(); // NEW HOOK
        console.log("Render complete.");
    }
    
    protected preRender(): void { }  // Default empty
    protected postRender(): void { } // Default empty
}
 
// WindowsCircle doesn't implement these, so defaults are used.
// Seems fine, right? But wait...
 
// A developer working on MacOSCircle does this:
class MacOSCircle extends Shape {
    draw(): void {
        this.initMetal();
        this.drawCircle();
    }
    
    protected preRender(): void {
        // MacOS-specific setup
        this.prepareMetalContext();
    }
    
    protected postRender(): void {
        // Cleanup
        this.flushMetalCommands();
    }
    
    // ...
}
 
// Another developer sees this and refactors WindowsCircle to match:
class WindowsCircle extends Shape {
    draw(): void {
        // Removed setupGDI since it should be in preRender
        this.drawCircle();
        // Removed teardownGDI since it should be in postRender
    }
    
    protected preRender(): void {
        this.setupGDI();
    }
    
    protected postRender(): void {
        this.teardownGDI();
    }
}
 
// Months later: performance team changes Shape.render():
abstract class Shape {
    render(): void {
        console.log("Preparing canvas...");
        // Changed: only call preRender if draw will actually execute
        if (this.shouldDraw()) {
            this.preRender();
            this.draw();
            // BUG: forgot to add shouldDraw check around postRender
        }
        this.postRender(); // This now runs even when draw doesn't!
        console.log("Render complete.");
    }
    
    protected shouldDraw(): boolean { return true; }
    protected preRender(): void { }
    protected postRender(): void { }
}
 
// Now WindowsCircle.postRender() runs teardownGDI() 
// even when setupGDI() was never called in preRender()!
// CRASH on Windows. Works fine on systems without cleanup logic.

The deeper issue:

The fragile base class problem is amplified in tightly-coupled hierarchies because:

More classes inherit — M × N concrete classes all depend on the base class. A single change affects dozens of classes.
Changes have cross-dimensional impact — A change intended for one dimension (e.g., adding a platform hook) affects all implementations of the other dimension.
Coupling hides assumptions — Subclasses make implicit assumptions about base class behavior that aren't specified in contracts. These assumptions break differently across the product matrix.
Testing doesn't catch all cases — Even with good test coverage, the combinatorial explosion means some Shape × Platform combinations aren't tested with every base class change.

The Semantic Coupling Trap

Documentation can't prevent this. The subclass developer can't read the base class author's mind about future changes. And the base class author can't anticipate how every subclass uses the extension points. This semantic fragility is fundamental to deep inheritance in multi-dimensional designs.

Compile-Time vs Runtime Binding

Another critical facet of the coupling problem is binding time. In inheritance-based designs, the relationship between abstraction and implementation is fixed at compile time. This creates rigidity that's impossible to overcome without code changes.

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
// Application startup
class DrawingApplication {
    private shapes: Shape[] = [];
    
    createCircle(center: Point, radius: number): Shape {
        // Decision is hardcoded at compile time
        if (process.platform === 'win32') {
            return new WindowsCircle(center, radius);
        } else if (process.platform === 'linux') {
            return new LinuxCircle(center, radius);
        } else if (process.platform === 'darwin') {
            return new MacOSCircle(center, radius);
        }
        throw new Error('Unsupported platform');
    }
    
    // Same pattern for createRectangle, createTriangle...
    // Each factory method has the same conditional logic
}
 
// PROBLEMS WITH COMPILE-TIME BINDING:
 
// 1. Can't change platform at runtime
// What if the user wants to switch from hardware to software rendering
// mid-session? We'd need to recreate all shapes.
 
// 2. Can't test with different implementations
// Unit tests need to somehow mock the platform check.
// Integration tests need actual platform-specific code.
 
// 3. Binary doesn't contain just needed code
// The Windows build includes Linux and macOS classes (dead code).
// Or we need complex build configurations to exclude them.
 
// 4. Can't inject implementations
// Dependency injection frameworks can't help when classes are
// hardcoded at instantiation sites throughout the codebase.
 
// 5. Can't share shapes across renderers
// What if we need to render the same circle in both a preview window
// (software renderer) and the main canvas (hardware renderer)?
// The circle's identity is bound to one renderer.

The runtime flexibility requirement:

Production systems frequently need runtime flexibility:

A/B Testing — Render using algorithm A for 10% of users, algorithm B for 90%. With compile-time binding, this requires conditional instantiation everywhere.
Graceful Degradation — If hardware rendering fails, fall back to software rendering. But objects already exist with hardware implementation baked in.
User Preferences — Let users choose rendering quality. 'Performance mode' uses simpler implementations, 'Quality mode' uses complex ones.
Hot Swapping — Update implementation without restart. Cloud systems do this for zero-downtime deployments.

Compile-time binding makes all of these difficult to impossible.

Compile-Time Binding

•Fixed at code-writing time
•Change requires recompilation
•Testing requires actual implementations
•No runtime variation possible
•Dead code in binary

Runtime Binding

•Determined at execution time
•Configuration without code change
•Mocks and stubs for testing
•A/B testing, fallbacks, preferences
•Load only needed implementations

Summary — The Problem Crystallized

We've dissected the fundamental problem that the Bridge Pattern addresses. Let's crystallize our understanding:

The Core Problem

•Inheritance models single-dimensional specialization — But real problems often involve multiple independent dimensions of variation (abstraction and implementation).
•Flattening dimensions creates M × N classes — The Cartesian product of variations overwhelms codebases with combinatorial explosion.
•Tight coupling fuses concerns together — Each concrete class binds abstraction logic and implementation logic into an inseparable whole.
•Simple fixes don't address the root cause — Conditionals, mixins, and template methods treat symptoms while preserving the coupling.
•Fragile base class problems are amplified — Changes cascade unpredictably across the product matrix of concrete classes.
•Compile-time binding prevents runtime flexibility — The implementation is fixed at code-writing time, foreclosing runtime variation.

What we need:

The solution must:

Allow abstraction and implementation to vary independently
Avoid multiplicative class explosion
Enable runtime binding between abstraction and implementation
Support independent evolution of both hierarchies
Provide compile-time type safety while maintaining flexibility

In the next page, we'll explore how the Bridge Pattern delivers exactly this: a structural approach that separates abstraction from implementation, connecting them through composition rather than inheritance.

Page Complete

You now understand the fundamental problem that the Bridge Pattern solves: the tight coupling between abstraction and implementation that leads to combinatorial explosion and rigid, unmaintainable code. In the next page, we'll discover how the Bridge Pattern elegantly delivers the solution: separating abstraction and implementation into independent hierarchies connected through composition.