Bridge Pattern: TV Remote and TVs
The Bridge Pattern lets you keep different parts of your software separate, so you can change one part without affecting the other. This is useful in systems that have different options or features that should not be tightly linked together.
For example, you may have many shapes in a graphics program, and each shape can be drawn in different ways. By separating shape from drawing method, you can add new shapes or new ways to draw without making the code messy. The Bridge Pattern keeps your code flexible and easy to grow.
Instead of combining features into one class with inheritance, the Bridge Pattern uses composition — one class holds a reference to another — making your code cleaner and easier to extend.
Real-Life Analogy: TV Remote and TVs
Imagine you have a universal remote control. You use the same remote to control different TV brands — Sony, Samsung, LG.
The remote has buttons like Power, Volume, and Channel. No matter which TV you connect it to, the remote works in the same way. The remote is the abstraction, and the TV is the implementation.
The two are connected through a bridge. You can create new remotes with different buttons or new TVs with new technologies — without needing to change both sides at once.

Benefits of Bridge Pattern
The Bridge Pattern reduces code duplication and avoids creating lots of classes when your code grows in more than one direction.
Some key benefits include:
- Separates abstraction and implementation so they can change independently
- Supports adding new features without breaking existing ones
- Keeps class hierarchies small and easy to understand
What to Implement
To implement the Bridge Pattern, you need:
- Abstraction: Defines the top-level logic, like a remote control
- Implementor Interface: Defines what the implementation must do — for example, turn on a TV
- Concrete Implementors: The actual objects that do the real work — like different TV brands
How It Works in C#
// The Implementor
public interface ITV
{
void On();
void Off();
void SetChannel(int number);
}
// Concrete Implementations
public class SonyTV : ITV
{
public void On() => Console.WriteLine("Sony TV is ON");
public void Off() => Console.WriteLine("Sony TV is OFF");
public void SetChannel(int number) => Console.WriteLine($"Sony TV channel set to {number}");
}
public class SamsungTV : ITV
{
public void On() => Console.WriteLine("Samsung TV is ON");
public void Off() => Console.WriteLine("Samsung TV is OFF");
public void SetChannel(int number) => Console.WriteLine($"Samsung TV tuned to channel {number}");
}
// The Abstraction
public class RemoteControl
{
protected ITV tv;
public RemoteControl(ITV tv)
{
this.tv = tv;
}
public void TurnOn() => tv.On();
public void TurnOff() => tv.Off();
public void SetChannel(int number) => tv.SetChannel(number);
}
Usage example:
ITV sony = new SonyTV();
var remote = new RemoteControl(sony);
remote.TurnOn();
remote.SetChannel(5);
remote.TurnOff();
When Should You Use It?
Use the Bridge Pattern when your class might have many variants of both the interface and implementation. Instead of writing a class for every combination, use Bridge to keep them separate but linked.
- You have classes that vary in both behaviour and implementation
- You want to avoid creating lots of subclass combinations
- You want to change one part (like the abstraction) without touching the other (implementation)
When Not to Use It: Don't use Bridge if your system is simple and doesn't need this level of separation — it might just add extra complexity.
Where Is It Used in the Real World?
The Bridge Pattern is used where systems must support many combinations of features and implementations. It is popular in graphics, device drivers, and multi-platform frameworks.
- Graphics and UI toolkits (theme/skin + rendering backend)
- Cross-platform apps (one interface, many platforms)
- Device drivers (interface separated from hardware)
- Remote controls for multiple devices
Final Thoughts
Think of the Bridge Pattern like a universal remote. You can control many types of TVs without changing how the remote looks or behaves.
This pattern is powerful when your system is growing in multiple ways — like adding new features and supporting new platforms — because it helps keep each part clean and flexible.