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.”
“Encapsulate object creation and return objects through a common interface instead of exposing concrete classes.”
- When object creation is complex
- When multiple implementations exist for a single interface
- When you want to avoid
if-elseorswitchscattered in code - When future extensibility is required
We want to send notifications via:
- SMS
- Push Notification
public interface INotification
{
void Send(string message);
}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);
}
}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");
}
}
}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");
}
}Email sent: Welcome to our system!
SMS sent: Your OTP is 1234
✔ 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
❌ 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
“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.”
“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.
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
Control of object creation is moved outside the class
Dependencies are injected from outside (most common and complete solution)
Helps centralize object creation, but:
✔ You still call the factory manually ✔ So control is not fully inverted
var obj = NotificationFactory.Create("email");✔ You are still controlling:
- when to create
- what to create
👉 So IoC is NOT fully achieved
public Service(INotification notification)✔ You don’t control creation ✔ You don’t call anything
👉 Control is fully inverted
👉 Factory helps move:
❌ scattered new
➡️ ✔ centralized creation
👉 But IoC requires:
❌ no control at all ➡️ ✔ container/framework handles everything
“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.”
| Concept | Role |
|---|---|
| IoC | Principle (goal) |
| DI | Main way to achieve IoC |
| Factory | Supports object creation, partial IoC |
“Factory pattern supports IoC but does not fully implement it—Dependency Injection is the proper way to achieve IoC.”
- 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