@gavenkoa l'autre question ne concerne que le proxy et le décorateur
user310291
2
Incroyable car certaines questions fermées se révèlent si utiles.
Luke
Réponses:
286
L'adaptateur 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 enveloppé par un objet adaptateur conforme et transmis. Le problème que nous résolvons ici est celui des interfaces non compatibles .
La façade ressemble plus à une simple passerelle vers un ensemble complexe 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 proxied-for et s'occupe généralement de certaines tâches administratives. (Donc, au lieu de faire plusieurs copies d'un objet lourd, Xvous faites des copies d'un proxy léger Pqui à son tour gère Xet traduit vos appels selon les besoins.) Vous résolvez 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 pas / n'altérez pas les interfaces existantes de l'objet, mais vous l' étendez simplement lors de l'exécution .
Maintenant que vous avez un décorateur impliqué, vous voudrez probablement savoir pourquoi l'accent mis sur le mot objet - certains langages (comme Java) ne permettent tout simplement pas l'héritage virtuel (c'est-à-dire l'héritage multiple comme le fait C ++) pour vous permettre d'accomplir cela à temps de compilation.
Depuis que nous avons traîné dans plusieurs héritages (et le diamant redouté), vous rechercherez des mixins - qui sont un chaînage linéaire ordonné des interfaces pour contourner les problèmes d'héritage multiple. Cependant, les mixins ne se mélangent pas très bien. Et nous nous retrouvons avec des 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 traits tentent d'aborder les problèmes de composition et de décomposition du comportement de manière élégante sans aller ni pour les héritages multiples ni pour le chaînage ordonné.
HTH! J'ai essayé d'en mettre le plus possible sans être trop vague. Excusez mon incapacité à faire mieux. J'ai lu des articles (thèse de doctorat) sur les seuls traits. Mes connaissances sont donc plutôt limitées et je ne suis pas assez bon pour s'adapter à tous les modèles de cet espace;)
dirkgently
Vous avez anticipé une question future sur les mixins et les traits mais je ne les ai pas encore vus!
user310291
1
Un bon lien de comparaison (via wikipedia) pour les trois premiers (le décorateur étant assez différent): NetObjectives
Liviu
@Liviu Votre lien est mort. Je suppose que vous pointiez là à l'origine , mais le contenu semble maintenant être derrière une connexion.
Jonathan H
@Sheljohn Lien mis à jour: p: Un bon lien de comparaison (via wikipedia) pour les trois premiers (le décorateur étant assez différent) NetObjectives (Récupération de texte, voir "entre": "Une des questions les plus fréquentes que je reçois en classe est" qu'est-ce la différence entre l'adaptateur, le proxy et la façade? Ils me semblent vraiment identiques ".)
Liviu
16
Façade
Vous pouvez utiliser une façade, par exemple, pour faciliter les appels à une API. Jetez un œil à cet exemple de façade éloignée. 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 API qui, à son tour, peut effectuer 1 ou plusieurs appels API sur le serveur.
Adaptateur
Un bon exemple de ceci peut être trouvé ici , sur Wikipedia. Un objet client Sourceaimerait appeler une méthode sur un autre objet Target, mais l'interface de cet autre objet diffère de ce que le client attend.
Entrez l'objet adaptateur.
Il peut prendre un appel de l' Sourceobjet et, dans les coulisses, appeler la Targetméthode qui doit être utilisée.
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
Quant à Proxy, je n'ai aucune expérience de ce modèle de conception.
Réponses:
L'adaptateur 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 enveloppé par un objet adaptateur conforme et transmis. Le problème que nous résolvons ici est celui des interfaces non compatibles .
La façade ressemble plus à une simple passerelle vers un ensemble complexe 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 proxied-for et s'occupe généralement de certaines tâches administratives. (Donc, au lieu de faire plusieurs copies d'un objet lourd,
Xvous faites des copies d'un proxy légerPqui à son tour gèreXet traduit vos appels selon les besoins.) Vous résolvez 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 pas / n'altérez pas les interfaces existantes de l'objet, mais vous l' étendez simplement lors de l'exécution .
Maintenant que vous avez un décorateur impliqué, vous voudrez probablement savoir pourquoi l'accent mis sur le mot objet - certains langages (comme Java) ne permettent tout simplement pas l'héritage virtuel (c'est-à-dire l'héritage multiple comme le fait C ++) pour vous permettre d'accomplir cela à temps de compilation.
Depuis que nous avons traîné dans plusieurs héritages (et le diamant redouté), vous rechercherez des mixins - qui sont un chaînage linéaire ordonné des interfaces pour contourner les problèmes d'héritage multiple. Cependant, les mixins ne se mélangent pas très bien. Et nous nous retrouvons avec des 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 traits tentent d'aborder les problèmes de composition et de décomposition du comportement de manière élégante sans aller ni pour les héritages multiples ni pour le chaînage ordonné.
la source
Façade
Vous pouvez utiliser une façade, par exemple, pour faciliter les appels à une API. Jetez un œil à cet exemple de façade éloignée. 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 API qui, à son tour, peut effectuer 1 ou plusieurs appels API sur le serveur.
Adaptateur
Un bon exemple de ceci peut être trouvé ici , sur Wikipedia. Un objet client
Sourceaimerait appeler une méthode sur un autre objetTarget, mais l'interface de cet autre objet diffère de ce que le client attend.Entrez l'objet adaptateur.
Il peut prendre un appel de l'
Sourceobjet et, dans les coulisses, appeler laTargetméthode qui doit être utilisée.Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)Quant à Proxy, je n'ai aucune expérience de ce modèle de conception.
la source