Pattern bridge
Fermé
plouch
-
11 juin 2016 à 01:55
KX Messages postés 16760 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 12 février 2025 - 11 juin 2016 à 09:27
KX Messages postés 16760 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 12 février 2025 - 11 juin 2016 à 09:27
Bonjour,
je ne comprends pas tres bien le pattern bridge.Je sais qu'il permet de séparer une classe de son implémentation, mais pourquoi faire?pourquoi dans le modele UML on a deux classes interfaces?
Merci d'avance!
je ne comprends pas tres bien le pattern bridge.Je sais qu'il permet de séparer une classe de son implémentation, mais pourquoi faire?pourquoi dans le modele UML on a deux classes interfaces?
Merci d'avance!
1 réponse
KX
Messages postés
16760
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
12 février 2025
3 020
11 juin 2016 à 09:27
11 juin 2016 à 09:27
Bonjour,
Prenons par exemple la classe LinkedList en Java.
https://docs.oracle.com/javase/8/docs/api/java/util/LinkedList.html
Cette classe implémente 7 interfaces pour mixer les comportements dont :
Si cela peut paraître étonnant d'être à la fois LIFO et FIFO, c'est parce que l'on se place au niveau de la classe LinkedList qui elle peut "tout" faire.
Mais si on se place au niveau des interfaces, elles ont des ensembles de méthodes disjointes qui respecte la cohérence.
Donc pour être cohérent ce n'est pas la classe LinkedList qu'il faut considérer, mais l'une de ses interfaces.
Exemple :
En travaillant avec l'interface (et ses méthodes associées) cela permet également de changer d'implémentation. Ici pour avoir une pile, une file et une liste j'ai pris trois LinkedList mais je peux changer de classe, tout en conservant les même interfaces. Exemple :
Ce changement d'implémentation ne change rien pour ton code, car le contrat des interfaces est toujours respecté. Cela apporte plus de souplesse au code.
"Mauvais" code :
En travaillant avec le code précédent, tu as accès à toutes les méthodes de LinkedList, que ce soit celles de Deque, Queue, List, ou les autres méthodes de LinkedList.
Si tu veux changer d'implémentation, tu vas devoir expurger ton code de toutes les méthodes de LinkedList que tu utilisais qui n'étais pas compatible.
Par exemple si par facilité (ou par erreur) tu utilisais une méthode de liste sur ta pile (ce qui est possible puisque l'objet LinkedList a les deux), en passant à une autre implémentation de pile, cette méthode de liste ne sera probablement pas présente dans la nouvelle pile, ce qui va te bloquer pour le changement d'implémentation.
Prenons par exemple la classe LinkedList en Java.
https://docs.oracle.com/javase/8/docs/api/java/util/LinkedList.html
Cette classe implémente 7 interfaces pour mixer les comportements dont :
- Deque : c'est une pile avec un comportement LIFO
- Queue : c'est une file avec un comportement FIFO
- List : c'est une liste avec un accès "direct" à tout les éléments
Si cela peut paraître étonnant d'être à la fois LIFO et FIFO, c'est parce que l'on se place au niveau de la classe LinkedList qui elle peut "tout" faire.
Mais si on se place au niveau des interfaces, elles ont des ensembles de méthodes disjointes qui respecte la cohérence.
- L'interface Deque ne travaille qu'avec des méthodes LIFO
- L'interface Queue ne travaille qu'avec des méthodes FIFO
- L'interface List ne travaille qu'avec des méthodes à accès direct
Donc pour être cohérent ce n'est pas la classe LinkedList qu'il faut considérer, mais l'une de ses interfaces.
Exemple :
Deque<E> pile = new LinkedList<>(); // c'est une pile Queue<E> file = new LinkedList<>(); // c'est une file List<E> liste = new LinkedList<>(); // c'est une liste
En travaillant avec l'interface (et ses méthodes associées) cela permet également de changer d'implémentation. Ici pour avoir une pile, une file et une liste j'ai pris trois LinkedList mais je peux changer de classe, tout en conservant les même interfaces. Exemple :
Deque<E> pile = new ArrayDeque<>(); // c'est encore une pile Queue<E> file = new PriorityQueue<>(); // c'est encore une file List<E> liste = new ArrayList<>(); // c'est encore une liste
Ce changement d'implémentation ne change rien pour ton code, car le contrat des interfaces est toujours respecté. Cela apporte plus de souplesse au code.
"Mauvais" code :
LinkedList<E> pile = new LinkedList<>(); LinkedList<E> file = new LinkedList<>(); LinkedList<E> liste = new LinkedList<>();
En travaillant avec le code précédent, tu as accès à toutes les méthodes de LinkedList, que ce soit celles de Deque, Queue, List, ou les autres méthodes de LinkedList.
Si tu veux changer d'implémentation, tu vas devoir expurger ton code de toutes les méthodes de LinkedList que tu utilisais qui n'étais pas compatible.
Par exemple si par facilité (ou par erreur) tu utilisais une méthode de liste sur ta pile (ce qui est possible puisque l'objet LinkedList a les deux), en passant à une autre implémentation de pile, cette méthode de liste ne sera probablement pas présente dans la nouvelle pile, ce qui va te bloquer pour le changement d'implémentation.