A veces, durante el proceso de desarrollo, encontraremos que las interfaces requeridas por el cliente y las interfaces proporcionadas son incompatibles. No podemos modificar la interfaz del cliente por razones especiales. En este caso, necesitamos adaptarnos a las interfaces existentes y las clases incompatibles, lo que requiere el modo adaptador. Con los adaptadores, podemos usarlos sin modificar el código antiguo, que es la capacidad del adaptador.
El modo de adaptación se puede usar para adaptarse entre una interfaz existente y una clase incompatible. Los objetos que usan este modo también se llaman envoltorios porque están envolviendo otro objeto con una nueva interfaz.
En la superficie, el modo adaptador es muy parecido al modo de apariencia. Todos necesitan envolver otros objetos y cambiar las interfaces que renderizan. La diferencia entre los dos es cómo cambian la interfaz. El elemento de apariencia presenta una interfaz simplificada que no proporciona opciones adicionales, y a veces hace algunas suposiciones para facilitar las tareas comunes. El adaptador convierte una interfaz a otra, que no filtrará ciertas capacidades y no simplificará la interfaz. Si la API del sistema del cliente no está disponible, se requiere un adaptador.
Teoría básica
Modo adaptador: convierta una interfaz en una interfaz requerida por el cliente sin modificar el código del cliente, para que el código incompatible pueda funcionar juntos.
El adaptador consta principalmente de 3 roles:
(1) Cliente: la clase que llama a la interfaz
(2) Adaptador: Clase utilizada para conectar la interfaz e interfaz del cliente que proporciona servicios
(3) Adaptador: proporciona servicios, pero es incompatible con los requisitos de la interfaz del cliente.
Implementación del modo adaptador
1. El adaptador más fácil
El modo adaptador no es tan complicado como piensas, así que le damos el ejemplo más simple.
El cliente llama a un método para el cálculo de adición:
resultado var = add (1,2);
Sin embargo, no proporcionamos el método ADD y proporcionamos el método de suma con la misma función similar:
función suma (v1, v2) {return v1 + v2;}Para evitar modificar el cliente y el servidor, agregamos una función de envoltura:
function add (v1, v2) {reutrn sum (v1, v2);}Este es el modo adaptador más simple, agregamos un método de envoltura entre dos interfaces incompatibles y usamos este método para conectar los dos para que funcionen juntos.
2. Aplicación práctica
Con el desarrollo de marcos frontales, cada vez más desarrolladores han comenzado a usar el marco MVVM para el desarrollo, solo necesitan manipular datos sin elementos DOM, y JQuery tiene cada vez menos efecto. Muchos proyectos aún se refieren a la clase de herramientas de la biblioteca JQuery, porque necesitamos usar el AJAX proporcionado por JQuery para solicitar datos al servidor. Si el papel de JQuery en el proyecto solo se usa como biblioteca de herramientas AJAX, parece que es un poco como matar un pollo y causar un desperdicio de recursos. En este momento, podemos encapsular por completo nuestra propia biblioteca AJAX.
Supongamos que el AJAX que encapsulamos se usa a través de una función:
Ajax ({url: '/getData', type: 'post', dataType: 'json', data: {id: "123"}}). Done (function () {})Excepto por la diferencia entre la interfaz de llamadas Ajax y los $ .AJAX de JQuery, los otros son exactamente lo mismo.
Debe haber muchos lugares en el proyecto que soliciten AJAX. Cuando reemplazamos a jQuery, no podemos modificar $ .AJAX uno por uno. ¿Qué debemos hacer? En este momento, podemos agregar un adaptador:
var $ = {ajax: function (options) {return aJax (opciones); }}Esto será compatible con el código anterior y las nuevas interfaces, evitando las modificaciones al código existente.
Resumir
El principio del modo adaptador es muy simple, que es agregar una nueva clase de envoltorio para envolver la nueva interfaz para adaptarse a las llamadas del código anterior y evitar modificar la interfaz y llamar al código.
Escenarios aplicables: hay muchas llamadas de código interfaces antiguas. Para evitar modificar el código anterior y reemplazar nuevas interfaces, los escenarios de aplicación no afectan los métodos de implementación existentes.
1. Ocasiones aplicables para el modo adaptador:
Los adaptadores son adecuados para situaciones en las que las interfaces esperadas por el sistema del cliente son incompatibles con las proporcionadas por la API existente. Los dos métodos adaptados al adaptador deben realizar tareas similares, de lo contrario el problema no se resolverá. Al igual que los elementos del puente y los elementos de apariencia, al crear adaptadores, la abstracción se puede aislar de sus implementaciones para que los dos puedan cambiarse de forma independiente.
2. Beneficios del modo adaptador:
Envuelva la interfaz de una clase existente con una nueva interfaz para que el programa del cliente pueda usar esta clase que no esté diseñada sin cirugía mayor.
3. Desventajas del modo Orchestrator:
Algunas personas piensan que los adaptadores son una sobrecarga innecesaria que se puede evitar completamente reescribiendo el código existente. Además, el modo adaptador también introducirá un lote de nuevas herramientas que deben ser compatibles. Si la API existente aún no está en forma, o la nueva interfaz aún no está en forma, el adaptador no siempre funciona.
Sus ventajas tienden a destacarse más que sus desventajas cuando involucra grandes sistemas y marcos heredados.