Quelle est la différence entre les patrons de conception Bridge et Adapter?
Réponses
Trop de publicités?À mon avis, il semble être une réponse plus courte et plus claire selon une autre réponse de stackoverflow ici:
-
Adapter est utilisé lorsque vous avez une interface abstraite, et que vous voulez la mapper à un autre objet qui a un rôle fonctionnel similaire, mais une interface différente.
-
Bridge est très similaire à Adapter, mais nous l'appelons Bridge lorsque vous définissez à la fois l'interface abstraite et l'implémentation sous-jacente. Autrement dit, vous n'adaptez pas à du code hérité ou tiers, vous êtes le concepteur de tout le code mais vous devez être en mesure de remplacer différentes implémentations.
Bridge est une amélioration de l'Adaptateur. Bridge inclut un adaptateur et ajoute une flexibilité supplémentaire à celui-ci. Voici comment les éléments de la réponse de Ravindra se situent entre les modèles :
Adaptateur | Bridge
-----------|---------------
Cible | Abstraction
-----------|---------------
| RefinedAbstraction
|
| Cet élément est spécifique au Bridge. S'il existe un groupe d'implémentations qui partagent la même logique, la logique peut être placée ici. Par exemple, toutes les voitures peuvent être divisées en deux grands groupes : manuel et automatique. Par conséquent, il y aura deux classes RefinedAbstraction.
-----------|---------------
Adaptateur | Implementor
-----------|---------------
Adapté | ConcreteImplementor
Bridge est très similaire à Adapter, mais nous l'appelons Bridge lorsque vous définissez à la fois l'interface abstraite et l'implémentation sous-jacente, ce qui signifie ne pas s'adapter au code externe, vous êtes le concepteur de tout le code mais vous devez être capable d'échanger différentes implémentations.
Je pense que c'est simple.
L'adaptateur est conçu pour permettre à une application tierce de fonctionner avec votre application. Inversement, pour que votre application puisse fonctionner avec des applications tierces.
En utilisant le modèle du pont, il est censé connecter deux ou plusieurs applications sans implémenter un adaptateur.
En fait, un pont est une interface à travers laquelle deux applications vont interagir. Comme exemple de pont, ce sont les interfaces PSR en PHP.
Exemple:
AutreApp
MaAppli
Dans l'exemple précédent, nous avons implémenté 2 adaptateurs par requête et par réponse. Si nous réécrivons l'exemple et essayons d'implémenter le pont.
AutreApp
``
MaAppli
`
Dans l'architecture hexagonale, les Ports (Interfaces, Contrats) peuvent agir comme des «Ponts» si vous écrivez une application dès le départ et êtes prêt à accepter les règles d'une autre application à utiliser. Sinon, vous devrez écrire des «Adaptateurs».
` `` ``` ```` `````
Supposons que vous avez une classe Shape abstraite avec une fonctionnalité de dessin (générique/abstraite) et un Cercle qui implémente la forme. Le motif de conception Bridge est simplement une approche d'abstraction à double sens pour découpler l'implémentation (dessin dans Cercle) et la fonctionnalité générique/abstraite (dessin dans la classe Shape).
Qu'est-ce que cela signifie vraiment? À première vue, cela semble être quelque chose que vous faites déjà (par inversion de dépendance). Donc, pas de soucis à avoir une base de code moins rigide ou plus modulaire. Mais il y a une philosophie un peu plus profonde derrière cela.
D'après ce que je comprends, le besoin de modèle d'utilisation peut apparaître lorsque j'ai besoin d'ajouter de nouvelles classes qui sont étroitement liées au système actuel (comme RedCircle ou GreenCircle) et qui diffèrent uniquement par une fonctionnalité (comme la couleur). Et j'aurai besoin du motif Bridge en particulier si les classes de système existantes (Cercle ou Forme) doivent être fréquemment modifiées et que vous ne voulez pas que les classes nouvellement ajoutées soient affectées par ces changements. C'est pourquoi la fonctionnalité de dessin générique est abstraite dans une nouvelle interface afin que vous puissiez modifier le comportement de dessin indépendamment de Forme ou Cercle.
0 votes
Peut-être envisager d'offrir une édition de clarification pour orienter la discussion sur l'endroit où vous pensez avoir besoin d'utiliser l'un ou l'autre.
0 votes
stackoverflow.com/questions/350404/…
0 votes
Aucune explication ici ne remplacera jamais la lecture de Design Patterns: Elements of Reusable Object-Oriented Software