Parfois, pendant le processus de développement, nous constatons que les interfaces requises par le client et les interfaces fournies sont incompatibles. Nous ne pouvons pas modifier l'interface client pour des raisons spéciales. Dans ce cas, nous devons nous adapter aux interfaces existantes et aux classes incompatibles, ce qui nécessite le mode adaptateur. Avec les adaptateurs, nous pouvons les utiliser sans modifier l'ancien code, qui est la capacité de l'adaptateur.
Le mode d'adaptation peut être utilisé pour s'adapter entre une interface existante et une classe incompatible. Les objets utilisant ce mode sont également appelés emballages car ils enveloppent un autre objet avec une nouvelle interface.
En surface, le mode adaptateur ressemble beaucoup au mode d'apparence. Ils ont tous besoin d'envelopper d'autres objets et de modifier les interfaces qu'ils rendent. La différence entre les deux est la façon dont ils modifient l'interface. L'élément d'apparence présente une interface simplifiée qui ne fournit pas d'options supplémentaires, et parfois il fait quelques hypothèses pour faciliter les tâches courantes. L'adaptateur convertit une interface à une autre, qui ne filtrera pas certaines capacités et ne simplifiera pas l'interface. Si l'API du système client n'est pas disponible, un adaptateur est requis.
Théorie de base
Mode adaptateur: convertissez une interface en une interface requise par le client sans modifier le code client, afin que le code incompatible puisse fonctionner ensemble.
L'adaptateur se compose principalement de 3 rôles:
(1) Client: la classe qui appelle l'interface
(2) Adaptateur: Classe utilisée pour connecter l'interface et l'interface du client fournissant des services
(3) Adaptateur: fournit des services, mais est incompatible avec les exigences de l'interface client.
Implémentation du mode adaptateur
1. L'adaptateur le plus facile
Le mode adaptateur n'est pas aussi compliqué que vous le pensez, alors donnons l'exemple le plus simple.
Le client appelle une méthode de calcul d'addition:
Var Result = Add (1,2);
Cependant, nous n'avons pas fourni la méthode d'ajout et avons fourni la méthode de somme avec la même fonction similaire:
Sum de fonction (v1, v2) {return v1 + v2;}Afin d'éviter de modifier le client et le serveur, nous ajoutons une fonction de wrapper:
fonction Add (v1, v2) {Reutrn sum (v1, v2);}Il s'agit du mode adaptateur le plus simple, nous ajoutons une méthode de wrapper entre deux interfaces incompatibles et utilisons cette méthode pour connecter les deux pour les faire fonctionner ensemble.
2. Application pratique
Avec le développement de cadres frontaux, de plus en plus de développeurs ont commencé à utiliser le framework MVVM pour le développement, n'ayant besoin que de manipuler des données sans éléments DOM, et jQuery a de moins en moins d'effet. De nombreux projets se réfèrent toujours à la classe d'outils de la bibliothèque JQuery, car nous devons utiliser l'Ajax fourni par jQuery pour demander des données au serveur. Si le rôle de JQuery dans le projet n'est utilisé que comme bibliothèque d'outils Ajax, j'ai l'impression que c'est un peu comme tuer un poulet et provoquer un gaspillage de ressources. Pour le moment, nous pouvons encapsuler complètement notre propre bibliothèque Ajax.
Supposons que l'Ajax que nous avons encapsulé soit utilisé par une fonction:
ajax ({url: '/ getData', type: 'post', dataType: 'json', data: {id: "123"}}). Done (function () {})À l'exception de la différence entre l'interface d'appel Ajax et $ .ajax de jQuery, les autres sont exactement les mêmes.
Il doit y avoir de nombreux endroits dans le projet qui demandent Ajax. Lorsque nous remplaçons jQuery, nous ne pouvons pas modifier $ .ajax un par un. Que devons-nous faire? Pour le moment, nous pouvons ajouter un adaptateur:
var $ = {ajax: fonction (options) {return ajax (options); }}Cela sera compatible avec l'ancien code et les nouvelles interfaces, en évitant les modifications du code existant.
Résumer
Le principe du mode adaptateur est très simple, qui consiste à ajouter une nouvelle classe de wrapper pour envelopper la nouvelle interface pour s'adapter aux appels de l'ancien code, et éviter de modifier l'interface et d'appeler le code.
Scénarios applicables: il existe de nombreux appels de code anciennes interfaces. Afin d'éviter de modifier l'ancien code et de remplacer de nouvelles interfaces, les scénarios d'application n'affectent pas les méthodes d'implémentation existantes.
1. Occasions applicables pour le mode adaptateur:
Les adaptateurs conviennent aux situations où les interfaces attendues par le système client sont incompatibles avec celles fournies par l'API existante. Les deux méthodes adaptées à l'adaptateur doivent effectuer des tâches similaires, sinon le problème ne sera pas résolu. Tout comme les éléments de pont et les éléments d'apparence, en créant des adaptateurs, l'abstraction peut être isolée de leurs implémentations afin que les deux puissent être modifiés indépendamment.
2. Avantages en mode adaptateur:
Enveloppez l'interface d'une classe existante avec une nouvelle interface afin que le programme client puisse utiliser cette classe qui n'est pas adaptée sans chirurgie majeure.
3. Inconvénients du mode orchestrateur:
Certaines personnes pensent que les adaptateurs sont des frais généraux inutiles qui peuvent être entièrement évités en réécrivant le code existant. De plus, le mode Adaptateur introduira également un lot de nouveaux outils qui doivent être pris en charge. Si l'API existante n'est pas encore en forme ou si la nouvelle interface n'est pas encore en forme, l'adaptateur peut ne pas toujours fonctionner.
Ses avantages ont tendance à se démarquer plus que ses inconvénients lorsqu'il implique de grands systèmes et des cadres hérités.