Factory Method Design Pattern seems to just be an If/Else or Switch statement. What am I missing?

Question

So I have been trying to brush up on my design patterns (thank you college for not teaching these...) and the Factory Method design pattern is giving me trouble.

---

Will refer to this Factory Method Design Pattern In C# for the sake of keeping the question area from having a ton of code in it. I have no personal code, just trying to understand design patterns

---

I understand that there are a few parts to it:

1. Product - CreditCard
2. ConcreteProduct- MoneyBackCreditCard, TitaniumCreditCard, PlatinumCreditCard
3. Creator- CardFactory
4. ConcreteCreator- MoneyBackCardFactory, TitaniumCardFactory, PlatinumCardFactory

When I look at the implementation though, all I see is a set of objects (with a common ancestor) whose constructor is decided and called based on some variable.

I assume there is something more correct? Last I knew, creating an object in a if/else or switch statement did not define a design pattern. I don't understand what makes this special.

Thanks to all who respond.

Answer 1

You can most definitely create a factory without any use of if-else.
Avoiding if-else is often a sign of you maturing as a developer.

Here's an example of a factory without switch and if-else.

public class CarFactory {
  private readonly Dictionary<string, Car> cars;

  public CarFactory() {
    cars = new Dictionary<string, Car>();
  }

  public Car this[string carType] => cars[carType];

  public string[] RegisteredTypes => cars.Keys.ToArray();

  public Car CreateCar(string carType) => cars[carType];

  public void RegisterCar(string carType, Func<Car> factoryAction) {
    if (string.IsNullOrEmpty(carType)) return;
    if (factoryAction is null) return;

    cars[carType] = factoryAction();
  }
}

You'll then register all car types on e.g. application startup with the DI container.

If you don't like this, then you can also use reflection instead. This comes with a performance penality.

Answer 2

It seems there were no satisfying answer. So let me try to explain or provide you links.

1st: Yes, if you narrow things down it is more or less an object creation based on a condition.

Why is it so special and declared as a design pattern? Design patterns are nothing more than a suggested "best" practice solution. The factory method pattern is one of few "creational" patterns to introduce such abstraction that covers the main case of "dynamic" type and dependencies of the object, like the abstract factory pattern. So the special thing is the abstraction of object creation.

For more detail read this: https://refactoring.guru/design-patterns/factory-method .In my opinion the best website for explaining design patterns.

Probably any enclosures of algorithms/code based on a condition IS a special thing about any "Factory-patterns".

• Because just helps to prevent scattered if/switch statements with the same condition.
• Hence less side-effects / bugs.
• Although very very dry in my opinion, I still recommend you watching at least the first 20 mins of the the following youtube video for truly understanding why Ifs are a "bad" thing https://www.youtube.com/watch?v=z43bmaMwagI

Answer 3

In short, an interface is used for creating an object, however a subclass decides which class to instantiate. The creation of object is done when it is required. The Factory method allows a class later instantiation to subclasses.

interface Product {}

class ConcreteProductA : Product {}

class ConcreteProductB : Product {}

abstract class Creator
{
    public abstract Product FactoryMethod(string type);
}

class ConcreteCreator : Creator
{
    public override Product FactoryMethod(string type)
    {
        switch (type)
        {
           case "A": return new ConcreteProductA();
           case "B": return new ConcreteProductB();
           default: throw new ArgumentException("Invalid type", "type");
        }
    }
 }

Original

There is no mystery to the Factory Pattern, in-fact its one of the most simple and easy Design Pattern there is.

At its simplest, you take a bunch of classes that are related through an interface or a base class, and you use a switch (or some other branching) to decide which one to create, then return it.

interface IMyLovelyHorse {...}

public class MyGreenHorse : IMyLovelyHorse {...}

public class MyYellowHorse : IMyLovelyHorse {...}

public class MyLittleHorse : IMyLovelyHorse {...}

...

public override IMyLovelyHorse CreateMyHorse(sometype somevalue)
{  
    switch(sometype)
    {
        case "MyGreenHorse" : return new MyGreenHorse();
        ...
    }
}

Answer 4

The refered article does not offer a good explanation of Factory Method pattern. In the UML diagram there is the AnOperation method but in the code there is not. Actually that method is the most interesting point of Factory Method pattern.

The motivation of this pattern is that, in some AnOperation method of a class, you want to create a new instance of another class in a flexible way. At first, you simply instance it by using the new keyword. But later on, as your program elvoves, you find that it is not flexible enough since the class mentioned after the new keyword must be always a concrete class. So you abstract this creation into an abstract method and let derived classes implement it. This is called Factory Method pattern. You can even achieve more flexibility by putting such abstract methods into a separated class/interface. This is called Abstract Factory pattern and of course it is more complex.

The if/else/switch/case statements in the article are totally unrelated to Factory Method pattern. The pattern does not concern which concrete factory is selected by users, that's a different story. Usually this selection happens in the CompositionRoot of your program. The main method is such a place.