Skip to content

Latest commit

 

History

History
273 lines (182 loc) · 6.77 KB

File metadata and controls

273 lines (182 loc) · 6.77 KB

📝 Factory Pattern

The Factory Design Pattern is a creational design pattern used to centralize object creation logic. Instead of creating objects directly using new, the responsibility of creating objects is delegated to a factory class.

This helps in decoupling client code from concrete implementations, making the system more flexible, maintainable, and scalable.

The .net core dependecy injection use factory-like behavior internally. DI itself is not a factory pattern—it is a mechanism to achieve inversion of control.”


🔷 Key Idea

“Encapsulate object creation and return objects through a common interface instead of exposing concrete classes.”


🔷 When to Use

  • When object creation is complex
  • When multiple implementations exist for a single interface
  • When you want to avoid if-else or switch scattered in code
  • When future extensibility is required

🔷 Real-Time Example: Notification System

We want to send notifications via:

  • Email
  • SMS
  • Push Notification

Instead of creating objects everywhere, we centralize creation using a Factory.

🔷 Step 1: Common Interface (Product)

public interface INotification
{
    void Send(string message);
}

🔷 Step 2: Concrete Implementations

public class EmailNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("Email sent: " + message);
    }
}

public class SmsNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("SMS sent: " + message);
    }
}

public class PushNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("Push Notification sent: " + message);
    }
}

🔷 Step 3: Factory Class

public class NotificationFactory
{
    public static INotification Create(string type)
    {
        switch (type.ToLower())
        {
            case "email":
                return new EmailNotification();

            case "sms":
                return new SmsNotification();

            case "push":
                return new PushNotification();

            default:
                throw new ArgumentException("Invalid notification type");
        }
    }
}

🔷 Step 4: Usage (Client Code)

class Program
{
    static void Main()
    {
        INotification notification;

        notification = NotificationFactory.Create("email");
        notification.Send("Welcome to our system!");

        notification = NotificationFactory.Create("sms");
        notification.Send("Your OTP is 1234");
    }
}

🔷 Output

Email sent: Welcome to our system!
SMS sent: Your OTP is 1234

🔷 Advantages

✔ Centralized object creation ✔ Loose coupling between client and concrete classes ✔ Easy to extend (add new notification types easily) ✔ Removes repeated new and if-else logic ✔ Improves maintainability


🔷 Disadvantages

❌ Can introduce extra abstraction (overhead for small apps) ❌ Factory may become a “God class” if not designed well ❌ Switch-case needs modification for new types (Simple Factory limitation) ❌ String-based selection can cause runtime errors


🔷 Key Interview Summary

“Factory Pattern centralizes object creation by providing a single place to instantiate objects. It hides concrete implementations from the client, reduces coupling, and improves extensibility. However, it should be used wisely as it can introduce extra complexity and maintenance overhead if overused.”


🔷 One-Line Definition (Memorize)

“Factory Pattern provides a centralized way to create objects without exposing the instantiation logic to the client, promoting loose coupling and flexibility.”

Got it—that makes more sense 👍 But still, your statement needs a correction.


Factory Vs IOC (Inversion of Control) Vs Factory Pattern

Inversion of Control (IoC) is a design principle in which the control of object creation and dependency management is transferred from the application code to an external system, such as a framework or container.

Factory Pattern is a creational design pattern that centralizes object creation by providing a method or class to create objects without exposing the instantiation logic to the client

Dependency Injection (DI) is a technique where dependencies are provided to a class from an external source instead of the class creating them itself.

❌ “Factory pattern is a way to certify/achieve IoC” ✔ Factory pattern can help achieve IoC partially, but it is not the main way


🔷 Correct Understanding

✅ IoC (Principle)

Control of object creation is moved outside the class


✅ DI (Primary Technique for IoC)

Dependencies are injected from outside (most common and complete solution)


✅ Factory Pattern (Supporting Pattern)

Helps centralize object creation, but:

✔ You still call the factory manually ✔ So control is not fully inverted


🔥 Key Difference (Very Important)

❌ Using Factory

var obj = NotificationFactory.Create("email");

✔ You are still controlling:

  • when to create
  • what to create

👉 So IoC is NOT fully achieved


✔ Using DI (True IoC)

public Service(INotification notification)

✔ You don’t control creation ✔ You don’t call anything

👉 Control is fully inverted


🔷 So Where Factory Fits?

👉 Factory helps move:

❌ scattered new ➡️ ✔ centralized creation

👉 But IoC requires:

❌ no control at all ➡️ ✔ container/framework handles everything


🔥 Best Interview Answer

“Factory pattern helps in centralizing object creation and can partially support IoC by reducing direct instantiation. However, it does not fully achieve IoC because the client still controls when and what to create. Dependency Injection is the primary technique used to fully implement IoC.”


🔷 Relationship Summary

Concept Role
IoC Principle (goal)
DI Main way to achieve IoC
Factory Supports object creation, partial IoC

🔥 One-Line Smart Answer

“Factory pattern supports IoC but does not fully implement it—Dependency Injection is the proper way to achieve IoC.”


🔴 Simple Memory Trick

  • Factory → “I create for you”
  • DI → “You don’t create at all”

If you want next: 👉 I can give one real enterprise example combining Factory + DI + Strategy (very powerful for interviews) 👉 Or common mistakes developers make with DI and Factory in .NET