Factory And Abstract Factor Design Pattern for C++
In our software, we may sometimes want to hide creation information from objects that will use the created object.
void orderCar()
{
/* CREATION */
Car car();
/* USE */
car.prepareTailgate();
car.preparePassangerGate();
car.prepareWheels();
car.prepareEngine();
}In the example above, there is a method named orderCar. Both creation car and use of car in the orderCar() method. .
Well, let’s imagine that the car creation process involves many functions. If there is a change in the creation process, for example the ctor has changed, we will have to change every function where the creation process takes place.
Let’s imagine that car production is conditional;
void orderCar(CarType carType)
{
/* CREATION */
std::unique_ptr<Car> car;
if (carType == FIAT)
{
car = std::make_unique<Fiat>();
}
else if (carType == FORD)
{
car = std::make_unique<Ford>();
}
else if (carType == RENAULT)
{
car = std::make_unique<Renault>();
}
else
{
car = std::make_unique<Togg>();
}
/* USE */
car->drive();
car->prepareTailgate();
car->preparePassangerGate();
car->prepareWheels();
car->prepareEngine();
}Things are getting more complicated. Currently, car production is included in a single function. What if this conditional production exists in many functions? When we add another condition to this conditional production, will we write a new “if” to all functions? This situation makes the maintenance of our software difficult. Also all the conditions we use for production are known to all objects that need this production.
What a terrible situation !
Doesn’t it make sense to write a factory class that is only responsible for creation operations for these cases? I think it’s very logical. We will write a class and this class will only be responsible for creation operations. In this way, we will isolate the processes of creation and use of what is created.
Yes, we found the factory design pattern !
The Factory Design Pattern is a creational design pattern used in object-oriented software development. It provides an interface for creating objects in a super class but allows subclasses to alter the type of objects that will be created.
Our goal is to hide the creation information from the client code.
Let’s rewrite our example above in accordance with the factory pattern;
enum CarType
{
TOGG,
FIAT,
FORD,
RENAULT
};
class Car
{
public:
virtual void drive() = 0;
static std::unique_ptr<Car> create(CarType cardType);
};
class Togg : public Car
{
public:
void drive()
{
std::cout<<"TOGG\n";
}
};
class Ford : public Car
{
public:
void drive()
{
std::cout<<"FORD\n";
}
};
class Fiat : public Car
{
public:
void drive()
{
std::cout<<"Fiat\n";
}
};
class Renault : public Car
{
public:
void drive()
{
std::cout<<"Renault\n";
}
};
std::unique_ptr<Car> Car::create(CarType cardType)
{
std::unique_ptr<Car> car;
if (cardType == TOGG)
{
car = std::make_unique<Togg>();
}
else if (cardType == FIAT)
{
car = std::make_unique<Fiat>();
}
else if (cardType == FORD)
{
car = std::make_unique<Ford>();
}
else if (cardType == RENAULT)
{
car = std::make_unique<Renault>();
}
else
{
car = std::make_unique<Togg>();
}
return car;
}
class CarOrder
{
public:
explicit CarOrder(CarType orderCarType)
{
_car = Car::create(orderCarType);
}
std::unique_ptr<Car> getCar()
{
return std::move(_car);
}
private:
std::unique_ptr<Car> _car;
};
int main()
{
CarOrder orderedCar{TOGG};
std::unique_ptr<Car> car = orderedCar.getCar();
car->drive();
return 0;
}There is an enumeration CarType that defines four car types: TOGG, FIAT, FORD, and RENAULT. There’s an abstract base class called Car with a pure virtual function drive(). This means that any class derived from Carmust provide an implementation of the drive function. Four derived classes (Togg, Fiat, Ford, Renault) inherit from the Car class. Each of these classes implements the drive() function to specify how the respective car type should behave when driven. A static member function create() is defined in the Car class. This function takes a CarType argument and returns a smart pointer (std::unique_ptr) to a Car object. It acts as a factory method to create instances of the different car types based on the CarType passed as an argument. In the create() function, it checks the value of carType and creates an instance of the appropriate car type using std::make_Unique. A class called CarOrder is defined, which represents an order for a specific car type. The constructor of this class takes a CarType as an argument and creates a car of the specified type using the Car::create factory method. The created car is stored in a private member _car. The CarOrderclass also provides a member function getCar to retrieve the ordered car as a std::unique_ptr<Car>. It uses std::move to transfer ownership of the car to the caller, ensuring that the _car member is empty after the call. Finally, in the main function, an instance of CarOrder is created with the car type TOGG. It then calls the getCar function to obtain the ordered car and calls the drive method on the car to print its name.
The code demonstrates the factory pattern and how it can be used to create objects of different types in a clean and organized manner.
As you know, cars basically have doors, wheels, transmission, engine, etc. If we are going to produce a togg car, it must have a togg door, a togg engine, and a togg transmission. If we are going to produce a Ford, there must be a Ford door, a Ford engine and a Ford transmission compatible with the car we produce. In other words, to create the ford object, there must be other objects compatible with this object.
Here is the Abstruct factory Design Pattern!
Abstract Factor Design Pattern
The Abstract Factory Design Pattern is a creational pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes. It falls under the category of factory patterns and emphasizes creating objects in a way that is independent of the instantiated classes.
Components:
- Abstract Factory: Declares an interface for creating a set of related objects, without specifying their concrete classes. It defines a method for each distinct object to be created.
- Concrete Factories: Implement the Abstract Factory interface to produce sets of related objects. Each concrete factory is responsible for creating a specific variant of the product family.
- Abstract Product: Declares an interface for a type of product object. Each distinct product of the family must follow this interface.
- Concrete Products: Implement the Abstract Product interface to define specific objects that are produced by the corresponding concrete factory.
How It Works:
- Clients interact with the Abstract Factory to create families of related objects. They are shielded from the knowledge of which specific concrete classes are being instantiated.
- Depending on the chosen concrete factory, different variants of related objects are created. These objects conform to the common interfaces declared in the Abstract Product.
Benefits:
- Encapsulates the object creation logic, providing a consistent interface for creating families of related objects.
- Ensures that the created objects are compatible with each other as they belong to the same family.
- Allows easy swapping of entire families of products by using different concrete factories, without impacting the client code.
Consider a scenario where you have different types of cars with related parts (engine, wheels, etc.). The Abstract Factory might define methods to create different car components (e.g., Engine, Wheels) and concrete factories (e.g., FiatFactory, FordFactory, ToggFactory) that produce specific variants of these components (e.g., FiatEngine, FordEngine, ToggFactory).
This pattern allows you to create and use different car models (Fiat, Ford, Togg) with their corresponding parts (FiatEngine, FordEngine, ) without tightly coupling the client code to specific classes.
#include <iostream>
#include <memory>
class Car {
public:
virtual void produceComponent() = 0;
virtual ~Car() {}
};
class ToggEngine : public Car {
public:
void produceComponent() override { std::cout << "ToggEngine\n"; }
};
class ToggTransmission : public Car {
public:
void produceComponent() override { std::cout << "ToggTransmission\n"; }
};
class FordEngine : public Car {
public:
void produceComponent() override { std::cout << "FordEngine\n"; }
};
class FordTransmission : public Car {
public:
void produceComponent() override { std::cout << "FordTransmission\n"; }
};
class Factory {
public:
virtual std::unique_ptr<Car> createEngine() = 0;
virtual std::unique_ptr<Car> createTransmission() = 0;
virtual ~Factory() {}
};
class ToggFactory : public Factory {
public:
std::unique_ptr<Car> createEngine() override { return std::make_unique<ToggEngine>(); }
std::unique_ptr<Car> createTransmission() override { return std::make_unique<ToggTransmission>(); }
};
class FordFactory : public Factory {
public:
std::unique_ptr<Car> createEngine() override { return std::make_unique<FordEngine>(); }
std::unique_ptr<Car> createTransmission() override { return std::make_unique<FordTransmission>(); }
};
class Custumer {
private:
std::unique_ptr<Factory> _factory;
public:
Custumer(std::unique_ptr<Factory> f) : _factory(std::move(f)) { }
void drive()
{
_factory->createEngine()->produceComponent();
_factory->createTransmission()->produceComponent();
std::cout << "Driving...\n";
}
};
int main() {
std::unique_ptr<Factory> factory = std::make_unique<ToggFactory>();
Custumer custumer(std::move(factory));
custumer.drive();
return 0;
}
