# Factory Method

<figure><img src="https://1722711354-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwNXdoUkfmcozr29fRrfb%2Fuploads%2F6Ykjz3mtOs2wzOIlMHSD%2Fimage.png?alt=media&#x26;token=fe08e494-3565-478e-a91f-9c3eccc3924f" alt=""><figcaption></figcaption></figure>

### Introduction

Factory Method provides an interface and method for creating an object in the class. But let its inheriting subclasses be able to override to specify which object will be created. Factory method assigns the creation of a specific object to a subclass&#x20;

#### Purpose

* Creates a new way of initializing objects through a common interface&#x20;
* Hides the logic processing of the initialization method&#x20;
* Reduces complexity&#x20;
* Dependent, easy to extend&#x20;
* Reduces the possibility of compile errors

#### Solution

The Factory Method pattern suggests that you replace direct object construction calls (using the `new` operator) with calls to a special *factory* method. Don’t worry: the objects are still created via the `new` operator, but it’s being called from within the factory method. Objects returned by a factory method are often referred to as *products.*

<figure><img src="https://refactoring.guru/images/patterns/diagrams/factory-method/solution1.png" alt="The structure of creator classes" width="620"><figcaption><p>Subclasses can alter the class of objects being returned by the factory method.</p></figcaption></figure>

At first glance, this change may look pointless: we just moved the constructor call from one part of the program to another. However, consider this: now you can override the factory method in a subclass and change the class of products being created by the method.

There’s a slight limitation though: subclasses may return different types of products only if these products have a common base class or interface. Also, the factory method in the base class should have its return type declared as this interface.

<figure><img src="https://refactoring.guru/images/patterns/diagrams/factory-method/solution2-en.png" alt="The structure of the products hierarchy" width="490"><figcaption><p>All products must follow the same interface.</p></figcaption></figure>

For example, both `Truck` and `Ship` classes should implement the `Transport` interface, which declares a method called `deliver`. Each class implements this method differently: trucks deliver cargo by land, ships deliver cargo by sea. The factory method in the `RoadLogistics` class returns truck objects, whereas the factory method in the `SeaLogistics` class returns ships.

<figure><img src="https://refactoring.guru/images/patterns/diagrams/factory-method/solution3-en.png" alt="The structure of the code after applying the factory method pattern" width="640"><figcaption><p>As long as all product classes implement a common interface, you can pass their objects to the client code without breaking it.</p></figcaption></figure>

The code that uses the factory method (often called the *client* code) doesn’t see a difference between the actual products returned by various subclasses. The client treats all the products as abstract `Transport`. The client knows that all transport objects are supposed to have the `deliver` method, but exactly how it works isn’t important to the client.

### Structure <a href="#structure" id="structure"></a>

<figure><img src="https://1722711354-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwNXdoUkfmcozr29fRrfb%2Fuploads%2FZwhOSPmyUDSUgM5vyocv%2FScreenshot%202023-09-13%20at%2022.25.42.png?alt=media&#x26;token=e1913933-a7f0-4092-b7f9-85980655d156" alt=""><figcaption></figcaption></figure>

Components in the model:

* Product : Defines an interface of objects that the factory method creates.&#x20;
* Concreteproduct: classes that implement the product template.&#x20;
* Creator: Declare a factory method, returning an object of type product. The Creator can also define a default implementation of the factory method whose return value is a default concreteproduct object. Call the factory method to create an object of type product.&#x20;
* ConcreteCrator: override factory method to return an instance of concreteproduct.

### Pros and Cons <a href="#pros-cons" id="pros-cons"></a>

#### Pros

* Hides the logic processing of the constructor&#x20;
* Limit dependencies between creator and concrete products&#x20;
* Easily expand and add new code to the program without breaking the original objects&#x20;
* Helps collect the code that creates the product into one place in the program, thus making it easier to track and manipulate.
* Reduce the possibility of compile errors, in case we need to create an object and forget to declare a class, we can also handle errors in the Factory and declare the class for them later.&#x20;

\=> Because of the above characteristics, the factory pattern is often used in libraries (the user achieves the purpose of creating a new object and does not need to care about how it is created).

#### Cons

* The source code can become more complex than usual because it requires the use of multiple classes to implement this pattern.&#x20;
* Refactoring an existing normal class into a class with a Factory Method can lead to many errors in the system, disrupting the existence of clients.&#x20;
* Factory method pattern depends on the use of private constructors so classes cannot be extended and inherited

### How to Implement <a href="#checklist" id="checklist"></a>

1. Make all products follow the same interface. This interface should declare methods that make sense in every product.
2. Add an empty factory method inside the creator class. The return type of the method should match the common product interface.
3. In the creator’s code find all references to product constructors. One by one, replace them with calls to the factory method, while extracting the product creation code into the factory method.

   You might need to add a temporary parameter to the factory method to control the type of returned product.

   At this point, the code of the factory method may look pretty ugly. It may have a large `switch` statement that picks which product class to instantiate. But don’t worry, we’ll fix it soon enough.
4. Now, create a set of creator subclasses for each type of product listed in the factory method. Override the factory method in the subclasses and extract the appropriate bits of construction code from the base method.
5. If there are too many product types and it doesn’t make sense to create subclasses for all of them, you can reuse the control parameter from the base class in subclasses.

   For instance, imagine that you have the following hierarchy of classes: the base `Mail` class with a couple of subclasses: `AirMail` and `GroundMail`; the `Transport` classes are `Plane`, `Truck` and `Train`. While the `AirMail` class only uses `Plane` objects, `GroundMail` may work with both `Truck` and `Train` objects. You can create a new subclass (say `TrainMail`) to handle both cases, but there’s another option. The client code can pass an argument to the factory method of the `GroundMail` class to control which product it wants to receive.
6. If, after all of the extractions, the base factory method has become empty, you can make it abstract. If there’s something left, you can make it a default behavior of the method

### When to use

* We have a super class with many subclasses and based on the input we need to return a subclass. This model helps us put the responsibility of initializing a class from the user (client) side to the Factory class, helping to save system resources because of reusing existing objects instead of rebuilding each one. section with additional product&#x20;
* We don't know what subclasses we will need later. When you need to expand, create a sub class and implement a factory method for initializing this sub class.

### Related Design Patterns&#x20;

* Abstract factory: often used with factory method&#x20;
* Prototypes: does not require subclassing from creator. However, they often require initialization on the product class. Creator uses Initialize to initialize the object.
