Factory Pattern

A startup in Bangalore had hardcoded Razorpay everywhere. new RazorpayClient() appeared in 47 files across their codebase. When they needed to add Stripe for international customers, they realized every single file that created a payment client needed to change. Not just the payment logic, the creation logic was scattered everywhere.

Three months of refactoring. Dozens of bugs. All because they'd tightly coupled "I need a payment processor" with "give me specifically a Razorpay instance."

The Factory pattern exists to prevent exactly this. Instead of code knowing which class to instantiate, it asks a factory: "give me a payment processor." The factory decides which concrete class to create based on context, region, configuration, feature flags, whatever. The calling code never knows and never cares.

The Factory pattern is about separating what you need from how it's created.

Without a factory, your code says: "I need a PostgresDatabase." That's a direct dependency on a concrete class.

With a factory, your code says: "I need a Database." The factory figures out whether that means Postgres, MySQL, SQLite, or an in-memory mock based on some configuration or context.

Here's why this matters in practice:

Three things get called a "factory", and it helps to keep them apart:

• Simple factory. One class with one creation method that looks at a parameter and picks the class to build: PaymentFactory.create(region) with a switch on region. Refactoring Guru, citing Head First Design Patterns, describes it as "a class that has one creation method with a large conditional that based on method parameters chooses which product class to instantiate and then return." It is not one of the Gang of Four patterns, but it is the one you will write most often in backend code.
• Factory Method (Gang of Four). A base class declares a creation method and lets subclasses decide what it returns. The same page puts it this way: it "provides an interface for creating objects but allows subclasses to alter the type of an object that will be created." The choice is made by which subclass you have, not by a parameter.
• Abstract Factory (Gang of Four). One object that creates a whole family of related objects, like a UI toolkit factory that produces buttons, inputs, and modals that all match a theme.

The payment example in this lesson is a simple factory. A Factory Method version would have a CheckoutFlow base class with an abstract createPaymentClient(), and an IndiaCheckoutFlow subclass that returns a Razorpay client while a USCheckoutFlow subclass returns a Stripe client. Both shapes hide the concrete class from the caller. The difference is where the decision lives: in one conditional, or spread across subclasses.