Bridge Design Pattern

Are your classes exploding? Use the Bridge Pattern to save your architecture. 🌉

“Inheritance is great until it isn’t. When you find yourself creating classes like RedSquare, BlueSquare, and GreenSquare, you aren't coding—you're creating a maintenance graveyard."

The fix? Stop using “Is-A” and start using “Has-A”. By bridging your hierarchies, you keep your shapes independent of your colors (or your Remotes independent of your TVs).

The Bridge Pattern is the “Structural” answer to the “Abstract Factory.” While the Abstract Factory handles how objects are created, the Bridge handles how they are structured so that they don’t become a nightmare to maintain.

1. The Problem: Class Explosion 💥

Imagine you’re building a Graphics App. You have different Shapes (Square, Circle) and you want them to support different Colors (Red, Blue).

If you use normal inheritance, your class tree looks like this:

Get Snigdhaa Katthula’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Shape

• RedSquare
• BlueSquare
• RedCircle
• BlueCircle

Now, imagine you add a Green color. You have to create GreenSquare and GreenCircle. Now add a Triangle shape... you see the problem? Every new feature multiplies the number of classes. This is Class Explosion.

2. The Solution: The Bridge

Instead of saying “A Red Square is a type of Square,” we say “A Square has a Color.” We pull the “Color” logic out into its own interface and “bridge” it back to the Shape.

3. Java Implementation

Step 1: The Implementation Interface (The “Color”)

interface Color {
    void applyColor();
}

class Red implements Color {
    public void applyColor() { System.out.println("Applying Red color."); }
}

class Blue implements Color {
    public void applyColor() { System.out.println("Applying Blue color."); }
}

Step 2: The Abstraction (The “Shape”)1

The Shape “holds” a reference to a Color. This is the Bridge.

abstract class Shape {
    // This protected field is the "Bridge"
    protected Color color;
    public Shape(Color color) {
        this.color = color;
    }
    abstract void draw();
}

Step 3: Refined Abstractions

class Circle extends Shape {
    public Circle(Color color) { super(color); }
    public void draw() {
        System.out.print("Drawing Circle. ");
        color.applyColor();
    }
}
class Square extends Shape {
    public Square(Color color) { super(color); }
    public void draw() {
        System.out.print("Drawing Square. ");
        color.applyColor();
    }
}

Step 4: The Client Code

public class Main {
    public static void main(String[] args) {
        // We can mix and match any Shape with any Color at runtime!
        Shape redCircle = new Circle(new Red());
        Shape blueSquare = new Square(new Blue());
        redCircle.draw();
        blueSquare.draw();
    }
}

4. Why is this better?

• Independence: You can add 10 new colors without touching the Shape classes.
• Cleaner Code: You went from $N \times M$ classes to $N + M$ classes. (For 5 shapes and 5 colors, you go from 25 classes down to 10).
• Runtime Flexibility: You can change the color of a shape dynamically while the program is running.