Bridge
Catégorie
Patron structurel
Problème
Découpler une abstraction de son implémentation afin que les deux puissent évoluer indépendamment. Utile lorsque l’extension de la classe et des implémentations possibles doit se faire au moment de l’exécution.
Solution
- Créer une hiérarchie d’abstractions qui délègue à une hiérarchie d’implémentations
- L’abstraction conserve une référence à l’interface d’implémentation, pas à une classe concrète
- Les modifications de l’une des hiérarchies n’affectent pas l’autre
Structure
- Abstraction : Définit l’interface d’abstraction ; conserve une référence à l’Implementor
- RefinedAbstraction : Étend l’interface Abstraction
- Implementor : Définit l’interface pour les classes d’implémentation
- ConcreteImplementor : Implémente l’interface Implementor
- Client : Utilise l’Abstraction via l’Implementor
Avantages clés
- Séparation des préoccupations — L’abstraction et l’implémentation évoluent indépendamment
- Réduction de l’explosion des classes — Évite les combinaisons N x M de classes issues de l’héritage
- Changement à l’exécution — L’implémentation peut être modifiée au moment de l’exécution
Compromis
- Ajoute une couche d’abstraction qui augmente la complexité
- Nécessite une conception minutieuse pour s’assurer que le délégation fonctionne correctement
Quand l’utiliser
- Vous souhaitez éviter un lien permanent entre une abstraction et son implémentation
- L’abstraction et ses implémentations doivent toutes deux être extensibles par sous-classement
- Des modifications de l’implémentation ne doivent pas affecter les clients
- Vous souhaitez masquer l’implémentation aux clients