Différence entre les modèles de conception Façade, Proxy, Adaptateur et Décorateur?
Quelle est la différence entre les modèles de conception Façade, Proxy, Adaptateur et Décorateur?
Je n'ai jamais lu d'explication claire, quelle est la tienne?
Adapter adapte une classe/un objet donné à une nouvelle interface. Dans le premier cas, l'héritage multiple est généralement utilisé. Dans ce dernier cas, l'objet est encapsulé par un objet adaptateur conforme et transmis. Le problème que nous résolvons ici est celui des interfaces non compatibles .
Facade ressemble plus à une simple passerelle vers un ensemble compliqué de fonctionnalités. Vous créez une boîte noire pour que vos clients s’inquiètent moins, c’est-à-dire simplifient les interfaces .
Proxy fournit la même interface que la classe avec proxy et effectue généralement certaines tâches de maintenance de manière autonome. (Ainsi, au lieu de faire plusieurs copies d’un objet lourd X, vous faites des copies d’un proxy léger P, qui à son tour gère X et traduit vos appels selon vos besoins.) résoudre le problème du client d'avoir à gérer un objet lourd et/ou complexe .
Decorator est utilisé pour ajouter plus de poudre à canon à vos objets (notez le terme objets - vous décorez généralement les objets de manière dynamique au moment de l'exécution). Vous ne masquez/n'altérez pas les interfaces existantes de l'objet, mais l'étendez simplement au moment de l'exécution .
Maintenant que vous avez un décorateur impliqué, vous voudrez probablement savoir pourquoi l'accent est mis sur l'objet Word - certains langages (comme Java) n'autorisent tout simplement pas l'héritage virtuel (c'est-à-dire l'héritage multiple comme le fait C++) pour vous permettre de le faire à temps de compilation.
Puisque nous avons traîné dans plusieurs héritages (et le diamant redouté), vous rechercherez des mixins - qui sont chaînage linéaire ordonné des interfaces pour contourner les problèmes d'héritage multiple. Cependant, les mixins ne font pas bon ménage. Et nous nous retrouvons avec traits - oui ces petites taches de comportement sans état que vous voyez apparaître tout le temps dans les paramètres de modèle en C++. Les caractères tentent de traiter les problèmes de composition et de décomposition du comportement de manière élégante sans éviter les héritages multiples ni l'enchaînement ordonné.
Façade
Vous pouvez utiliser une façade, par exemple, pour faciliter les appels vers une API. Jetez un oeil à this exemple d'une façade distante. L'idée ici est que l'implémentation complète du code sur le serveur est cachée au client. Le client appelle 1 méthode d'API qui, à son tour, peut effectuer un ou plusieurs appels d'API sur le serveur.
Adaptateur
Un bon exemple de ceci peut être trouvé ici , sur Wikipedia. Un objet client Source voudrait appeler une méthode sur un autre objet Target, mais l'interface de cet autre objet diffère de celle attendue par le client.
Entrez l'objet adaptateur.
Il peut prendre un appel depuis l'objet Source et, en coulisse, appeler la méthode Target à utiliser.
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
En ce qui concerne Proxy, je n'ai aucune expérience de ce modèle de conception.