Factory Method Pattern vs Facade Pattern vs Registry Pattern

1. Factory Method Pattern

• Centralisation et personnalisation de la création d'objets : Définit une interface pour créer des objets, laissant aux sous-classes décider de la classe concrète à instancier.
• Encapsulation de la logique de création : Chaque type de notification (email, SMS, push) est créé via une factory spécifique.
• Exemple : Générer des notifications (email, SMS, push) via des factories spécialisées.

2. Facade Pattern

• Simplification de l'accès à des systèmes complexes : Masque la complexité des différents services de notification (email, SMS, push) derrière une interface simple.
• Découplage des sous-systèmes : Fournit une interface unifiée pour envoyer les notifications sans gérer la complexité de chaque service.
• Exemple : Utilisation d'une façade pour simplifier l'envoi de notifications via email, SMS, ou push.

3. Registry Pattern

• Point d'accès global aux services partagés : Centralise l'accès aux services de notification (email, SMS, push) dans un registre global.
• Réduction des dépendances multiples : Les services sont enregistrés et récupérés dans un registre global, facilitant leur utilisation à plusieurs endroits.
• Exemple : Accès centralisé aux services de notification via un registre global.

Comparaison directe :

Caractéristique	Factory Method Pattern	Facade Pattern	Registry Pattern
Objectif principal	Centraliser et personnaliser la création de notifications	Simplifier l'accès aux services de notification	Centraliser l'accès global aux services de notification
Changement dynamique	Oui, permet de choisir la factory spécifique pour chaque type de notification	Non, fournit une interface unique pour tous les services	Non, centralise l'accès mais ne permet pas de changements dynamiques
Complexité cachée	Non, se concentre sur la création des objets de notification	Oui, cache la complexité des services sous-jacents	Non, centralise mais ne masque pas de complexité interne
Flexibilité dans l'ajout de fonctionnalités	Moyenne, limitée aux classes concrètes implémentées	Faible, l'ajout de nouvelles fonctionnalités nécessite de modifier la façade	Moyenne, permet d'ajouter et retirer des services globalement
Exemple d'application	Création de notifications (email, SMS, push) via des factories	Envoi simplifié des notifications via une interface unifiée	Accès centralisé aux services de notification via un registre global

Exemples

Dans tous les cas, tu veux développer un système de notifications qui supporte l'envoi de notifications par email, SMS, et push.

1. Factory Method Pattern

Chaque type de notification est créé via une factory spécifique.

$emailFactory = new EmailNotificationFactory();
$emailNotification = $emailFactory->createNotification();
echo $emailNotification->send('Hello via Email', 'John Doe');

$smsFactory = new SmsNotificationFactory();
$smsNotification = $smsFactory->createNotification();
echo $smsNotification->send('Hello via SMS', 'John Doe');

2. Facade Pattern

La façade masque la complexité d'envoi de notifications par email, SMS et push via une seule interface simple.

$notificationFacade = new NotificationFacade();
$notificationFacade->sendEmail('John Doe', 'Hello via Email');
$notificationFacade->sendSms('John Doe', 'Hello via SMS');
$notificationFacade->sendPush('John Doe', 'Hello via Push');

3. Registry Pattern

Les services de notification sont centralisés dans un registre et peuvent être récupérés partout dans l'application.

Registry::set('email', new EmailNotificationService());
Registry::set('sms', new SmsNotificationService());

$emailService = Registry::get('email');
echo $emailService->send('John Doe', 'Hello via Email');

$smsService = Registry::get('sms');
echo $smsService->send('John Doe', 'Hello via SMS');

Explications

• Avec le Factory Method Pattern, chaque notification (email, SMS, push) est créée via des factories distinctes, permettant une personnalisation fine de la logique de création pour chaque type de service.

• Le Facade Pattern masque la complexité des différents services de notification derrière une interface unifiée, simplifiant grandement l'envoi de notifications par email, SMS ou push.

• Le Registry Pattern centralise l'accès à ces services dans un registre global, permettant de stocker et de récupérer les services de notification de manière simple et sans avoir à les instancier à chaque fois.

Cas d'utilisation des patterns

• Le Factory Method Pattern est idéal lorsque tu as besoin de personnaliser la création de notifications ou d'autres services selon des implémentations spécifiques.

• Le Facade Pattern est parfait lorsque tu veux simplifier l'accès à plusieurs services de notification et les gérer via une interface unique et facile à utiliser.

• Le Registry Pattern est utile lorsque tu veux centraliser l'accès aux services partagés dans ton application, comme l'email, le SMS, ou le push, et éviter de les instancier à plusieurs endroits.

Conclusion

• Le Factory Method Pattern permet de personnaliser la création de services, tout en gardant une structure extensible.
• Le Facade Pattern simplifie l'interaction avec plusieurs systèmes complexes en les encapsulant dans une seule interface.
• Le Registry Pattern centralise l'accès aux services partagés dans un conteneur global, simplifiant leur gestion et leur utilisation à travers l'application.

Ces trois patterns offrent des solutions adaptées à des situations différentes, chacun ayant ses propres avantages en termes de modularité, simplification et gestion des dépendances.