Le design pattern Factory permet d’instancier un objet sans utiliser la méthode de création « classique » mais utilise une méthode commune.

Pour illustrer ce design pattern, prenons le cas d’un système d’export de données dans plusieurs format PDF, CSV, etc…

interface Document {
    public function export(): mixed;
}

class DocumentException extends Exception
{
}

enum TypeDocumentEnum: string {
    case DocumentTypePdf = 'DOCUMENT_TYPE_PDF';
    case DocumentTypeCsv = 'DOCUMENT_TYPE_CSV';
}

class PdfDocument implements Document
{
    public function export(): mixed
    {
        // do something
    }
}

class CsvDocument implements Document
{
    public function export(): mixed
    {
        // do something
    }
}

class DocumentFactory
{
    public static function create(TypeDocumentEnum $type): Document
    {
        return match ($type) {
            TypeDocumentEnum::DocumentTypePdf => new PdfDocument(),
            TypeDocumentEnum::DocumentTypeCsv => new CsvDocument(),
            default => throw new DocumentException('Invalid type of document')
        };
    }
}

$document = DocumentFactory::create(TypeDocumentEnum::DocumentTypePdf);
// do something
$document->export();

Le code ainsi créé permet très facilement de prendre en charge un nouveau type de document.

Avantage du design pattern Factory

La Factory sépare la création d’un objet de son utilisation, ce qui réduit les dépendances et facilite la maintenance.
Toute la logique de création est centralisée à un seul endroit, facilitant les modifications futures. Les clients manipulent des interfaces ou des classes abstraites, permettant un code plus souple et modulaire et il est facile d’ajouter de nouveaux types de produits sans modifier le code client existant.
Le code est plus réutilisable car la logique de création est isolée.

Inconvénient du design pattern Factory

Ce design pattern intoduit une couche d’abstraction supplémentaire et des classes supplémentaires qui peuvent, s’il est appliqué à des cas simple, complexifier le code.