Factory pattern, completely violates one of the SOLID principle

Hey Vishal Yelve ,

Thanks for sharing  valuable links, helped me a lot. 
Assume one requirement, I have 3 types of credit cards which will inherited from ICreditCard. Dynamic instance returned from CreditCard Factory. If I want to add more card type, then we have to change creditcardFactory class.

As per my knowledge and based on this example, I thought Factory pattern violates Open closed principle

Hi Jayraj Chhaya,

Thanks for detailed explanation, two points have to discuss..
one is that SRP, as per this principle responsiblity should be single in your example that is satisfying. Responsibility means it should generate an object instance as per interface. Its not a matter is it interface coming as classA or classB. So SRP is completely satisfied. 
other one,at our modified code, factory design pattern almost converted to abstract factory, but don't want to do changes like that. We should use factory pattern and include SOLID prinicples.
 

Hi Siva,

No, it doesn’t violate the Open/Closed principle at all.

Open/Closed means you can modify the way a system works without modifying the code that already exists.

Do refer complete article 

https://tarunjain07.medium.com/factory-pattern-notes-e464b4a399ad#:~:text=No%2C%20it%20doesn't%20violate,the%20code%20that%20already%20exists.

https://stackoverflow.com/questions/2381167/does-the-factory-method-pattern-violate-the-open-closed-principle

The Factory pattern is a widely used design pattern in software development that provides an interface for creating objects without specifying their concrete classes. It promotes loose coupling and encapsulation by delegating the responsibility of object creation to a separate factory class.

Regarding the SOLID principles, the Factory pattern can potentially violate the Single Responsibility Principle (SRP). The SRP states that a class should have only one reason to change. In the context of the Factory pattern, if the factory class is responsible for creating multiple types of objects, it violates the SRP.

To include the SRP in the Factory pattern, we can introduce a separate factory class for each type of object. This way, each factory class will have a single responsibility of creating a specific type of object. By adhering to this approach, we ensure that each class has a clear and focused responsibility, reducing the risk of violating the SRP.

Here's an example in C# to illustrate this:

public interface IProduct
{
    void DoSomething();
}

public class ConcreteProductA : IProduct
{
    public void DoSomething()
    {
        // Implementation for Product A
    }
}

public class ConcreteProductB : IProduct
{
    public void DoSomething()
    {
        // Implementation for Product B
    }
}

public interface IProductFactory
{
    IProduct CreateProduct();
}

public class ConcreteProductAFactory : IProductFactory
{
    public IProduct CreateProduct()
    {
        return new ConcreteProductA();
    }
}

public class ConcreteProductBFactory : IProductFactory
{
    public IProduct CreateProduct()
    {
        return new ConcreteProductB();
    }
}

In this example, we have separate factory classes (ConcreteProductAFactory and ConcreteProductBFactory) responsible for creating specific types of products (ConcreteProductA and ConcreteProductB). Each factory class has a single responsibility, adhering to the SRP.

By following this approach, we can ensure that the Factory pattern aligns with the SOLID principles, specifically the Single Responsibility Principle.