I Finally Understood Design Patterns When I Stopped Looking at Code

During my SDET interview preparation, there was one topic that kept appearing everywhere: Design Patterns.

I watched YouTube videos, read blog posts, and went through countless code examples. Yet something felt missing.

• I could memorize definitions.
• I could explain them in interviews.
• But I didn’t truly understand why these patterns existed.

The breakthrough came when I stopped looking at code and started looking at everyday life.

That’s when I realized something interesting:

Design Patterns are not software concepts. They are human solutions to common problems that software has adopted.

In fact, we use Design Patterns every day without realizing it.

Let’s understand some of the most popular Design Patterns through examples that all of us can relate to.

Why Do Design Patterns Exist?

Imagine if every city designed traffic signals differently.

• One city uses red for stop
• Another uses blue
• A third uses blinking lights

Driving would become confusing very quickly.

Instead, we follow proven standards because they work.

Software development faces similar challenges. Developers across the world encounter the same problems repeatedly:

• How should objects be created?
• How can systems communicate efficiently?
• How do we avoid duplicate code?
• How do we make applications easier to maintain?

Instead of reinventing solutions every time, we use Design Patterns — proven approaches that have worked for years.

Think of them as reusable blueprints for solving common software problems.

1. Factory Pattern — Ordering Coffee at a Café

Imagine walking into your favorite coffee shop.

You don’t know:

• Which coffee beans are used
• How much milk is required
• What temperature it’s brewed at
• Which machine prepares it

You simply say:

“I’d like a Cappuccino.”

A few minutes later, you get exactly what you asked for.

You don’t care about how it’s made — only what you receive.

That’s the Factory Pattern.

Real-Life Flow

Customer → Coffee Factory (Barista) → Cappuccino / Latte / Espresso

The customer requests a coffee. The factory decides how to create it.

Software Example

Coffee coffee = CoffeeFactory.getCoffee("CAPPUCCINO");

SDET Example

Browser browser = BrowserFactory.createBrowser("chrome");

Tomorrow you can support:

• Firefox
• Edge
• Safari

Without changing your test code.

Benefits

• ✔ Cleaner code
• ✔ Better scalability
• ✔ Easier maintenance
• ✔ Centralized object creation

2. Singleton Pattern — The Office Printer

Imagine a company with 500 employees. Would everyone get their own printer? Probably not. Instead, everyone shares one printer. This is the Singleton Pattern.

What Problem Does It Solve?

Some resources should exist only once:

• Configuration Manager
• Logger
• Database Connection
• Test Execution Manager

Multiple instances can lead to:

• Data inconsistency
• Memory waste

Real-Life Example

Think about a company’s CEO. There’s only one CEO, not multiple versions.

Software Example

ConfigManager.getInstance();

Always returns the same instance.

SDET Example

A Singleton Config Reader ensures all tests use the same configuration.

Benefits

• ✔ Consistent data
• ✔ Reduced memory usage
• ✔ Easy access
• ✔ Better resource management

3. Observer Pattern — YouTube Notifications

You subscribe to a YouTube channel. When the creator uploads a video, you instantly receive a notification. The creator doesn’t manually notify everyone. Subscribers register interest and get updates automatically.This is the Observer Pattern.

Real-Life Flow

Publisher (YouTube Channel) → Subscribers (Observers) → Notifications

Software Concept

A subject maintains a list of observers and notifies all when a change occurs.

SDET Example

After test execution:

• Email reports
• Slack notifications
• Dashboard updates
• Jira tickets

All get triggered automatically via observers.

Benefits

• ✔ Loose coupling
• ✔ Easy to extend
• ✔ Better maintainability
• ✔ Cleaner architecture

4. Strategy Pattern — Google Maps Route Selection

You want to travel from Pune to Mumbai. Google Maps gives multiple routes:

• Fastest
• Shortest
• Toll-free
• Scenic

The destination is the same. Only the strategy changes.

This is the Strategy Pattern.

Core Idea

Same goal, different approaches.

Software Example

PaymentStrategy strategy = new CreditCardPayment();
strategy.pay();

Later:

PaymentStrategy strategy = new UpiPayment();
strategy.pay();

No change in client code.

SDET Example

Execution strategies:

• Local
• Docker
• Browser Stack

Same test logic, different execution strategy.

Benefits

• ✔ Flexible design
• ✔ Easy extension
• ✔ Reduced duplication
• ✔ Better maintainability

5. Builder Pattern — Ordering a Custom Pizza

When ordering a pizza, you choose:

• Crust
• Cheese
• Toppings

Every order is different.

Instead of fixed combinations, you build your own.

This is the Builder Pattern.

Software Example

Instead of:

User("Nishi", "Admin", "India", true, false, ...);

Use:

User user = UserBuilder()
    .withName("Nishi")
    .withRole("Admin")
    .withCountry("India")
    .build();
``

Cleaner and more readable.

SDET Example

Used for:

• Test data creation
• API payloads
• Complex objects

Benefits

• ✔ Improved readability
• ✔ Flexible construction
• ✔ Easier maintenance
• ✔ Cleaner test code

Interview Corner: How SDETs Are Asked

Interviewers focus on applications, not definitions.

Factory Pattern

• How would you initialize different browsers?
• Why use BrowserFactory?

Singleton Pattern

• Why should ConfigReader be Singleton?
• What issues arise with multiple instances?

Observer Pattern

• How would you send Slack/Email after tests?

Strategy Pattern

• How to support Local, Docker, and BrowserStack?

Builder Pattern

• How to create complex test data cleanly?

Real-world explanations instantly show true understanding.

How Design Patterns Help SDETs

The difference between scripts and a scalable framework is often the use of design patterns.

Final Thoughts

The biggest lesson I learned:

Don’t try to memorize Design Patterns. Learn to recognize them.

Once you do, you’ll see them everywhere:

• Coffee shops → Factory
• Office printers → Singleton
• YouTube → Observer
• Google Maps → Strategy
• Pizza ordering → Builder

Technology changes. Languages change. Frameworks change.

But these ideas remain timeless.

So next time someone asks you about Design Patterns…

Don’t start with code. Start with coffee, YouTube, Google Maps, or pizza.

You’ll understand them better than ever.