Factory Method

The factory design pattern is a fundamental creational pattern in object-oriented programming that deals with object creation. It offers a way to create objects without directly specifying the exact class of the object you're creating.

Here's a breakdown of the key aspects of the factory design pattern:

1. Centralized Object Creation: The factory pattern introduces a concept called a factory. This factory class acts as a central location for creating objects. Instead of directly using a class constructor, you interact with the factory to get the object you need.

2.Decoupling Creation from Usage: By using a factory, you decouple the code that uses the object (the client) from the specific class responsible for creating the object. This makes your code more flexible and adaptable.

3.Subclasses Define Object Types: The factory class typically defines an interface or an abstract class that represents the type of object being created. Subclasses of the factory then implement the logic to create specific concrete classes that adhere to the interface or inherit from the abstract class.

4.Factory Method Selection: The factory class might use different methods to decide which concrete class to instantiate. This decision could be based on factors like configuration settings, input parameters, or runtime conditions.

5.The factory design pattern offers several advantages:

Loose Coupling: The client code doesn't depend on specific concrete classes, making it more adaptable to changes.
Flexibility: You can easily introduce new types of objects without modifying the client code.
Reusability: Factory classes promote code reuse by centralizing object creation logic.

Imagine a Car Dealership (Factory) that sells various car types (Concrete Classes). The dealership (Factory Class) doesn't manufacture the cars itself, but it has partnerships with different car manufacturers (Subclasses).

1.Centralized Object Creation: You (Client) visit the dealership (Factory) to buy a car (Object). You don't need to know the specifics of each manufacturer (Subclass) beforehand.

2.Decoupling Creation from Usage: The dealership (Factory) handles interacting with the manufacturers (Subclasses) to get you the car (Object) you need. You don't have to contact manufacturers directly.

3.Subclasses Define Object Types: The dealership (Factory Class) might have different departments (Subclasses) specializing in sedans, SUVs, or trucks (Concrete Classes).

4.Factory Method Selection: The salesperson (Factory Method) at the dealership (Factory Class) might ask your preferences (Input Parameters) and then direct you to the relevant department (Subclass) to find your ideal car (Concrete Class).

5.The factory design pattern offers several advantages:

Loose Coupling: You are not tied to a specific manufacturer (Subclass). If you need a truck later, you can still go to the same dealership (Factory).
Flexibility: The dealership (Factory Class) can easily add new departments (Subclasses) to sell new car types (Concrete Classes) without affecting you.
Reusability: The dealership (Factory Class) has a standardized process for acquiring cars (Objects), making it efficient.

/**
 * The Creator class declares the factory method that is supposed to return an
 * object of a Product class. The Creator's subclasses usually provide the
 * implementation of this method.
 */
abstract class Creator {
    /**
     * Note that the Creator may also provide some default implementation of the
     * factory method.
     */
    public abstract factoryMethod(): Product;

    /**
     * Also note that, despite its name, the Creator's primary responsibility is
     * not creating products. Usually, it contains some core business logic that
     * relies on Product objects, returned by the factory method. Subclasses can
     * indirectly change that business logic by overriding the factory method
     * and returning a different type of product from it.
     */
    public someOperation(): string {
        // Call the factory method to create a Product object.
        const product = this.factoryMethod();
        // Now, use the product.
        return `Creator: The same creator's code has just worked with ${product.operation()}`;
    }
}

/**
 * Concrete Creators override the factory method in order to change the
 * resulting product's type.
 */
class ConcreteCreator1 extends Creator {
    /**
     * Note that the signature of the method still uses the abstract product
     * type, even though the concrete product is actually returned from the
     * method. This way the Creator can stay independent of concrete product
     * classes.
     */
    public factoryMethod(): Product {
        return new ConcreteProduct1();
    }
}

class ConcreteCreator2 extends Creator {
    public factoryMethod(): Product {
        return new ConcreteProduct2();
    }
}

/**
 * The Product interface declares the operations that all concrete products must
 * implement.
 */
interface Product {
    operation(): string;
}

/**
 * Concrete Products provide various implementations of the Product interface.
 */
class ConcreteProduct1 implements Product {
    public operation(): string {
        return '{Result of the ConcreteProduct1}';
    }
}

class ConcreteProduct2 implements Product {
    public operation(): string {
        return '{Result of the ConcreteProduct2}';
    }
}

/**
 * The client code works with an instance of a concrete creator, albeit through
 * its base interface. As long as the client keeps working with the creator via
 * the base interface, you can pass it any creator's subclass.
 */
function clientCode(creator: Creator) {
    // ...
    console.log('Client: I\'m not aware of the creator\'s class, but it still works.');
    console.log(creator.someOperation());
    // ...
}

/**
 * The Application picks a creator's type depending on the configuration or
 * environment.
 */
console.log('App: Launched with the ConcreteCreator1.');
clientCode(new ConcreteCreator1());
console.log('');

console.log('App: Launched with the ConcreteCreator2.');
clientCode(new ConcreteCreator2());