Adaptor Ethernet alimentat de Chris Grooms

Editie JavaScript

In mod traditional, modelele structurale sunt descrise ca fiind lucrul care ajuta la simplificarea procesului de compozitie a obiectelor. Scopul sau este de a ajuta la identificarea relatiei dintre diferite obiecte, asigurandu-se ca, daca ceva se schimba in interiorul sistemului, nu forteaza intregul sistem sa se schimbe odata cu acesta.

Sa incepem cu modelul adaptorului.

Imaginati-va ca trebuie sa construiti o alta solutie de carucior pentru seful dvs. Dar exista o avertizare – nu aveti voie sa schimbati codul original care scuipa datele despre cos.

Array

De ce? Pentru ca nimeni nu stie cum va afecta aceasta schimbare restul aplicatiei. Este o piesa de arta fragila pe care nimeni nu vrea sa o atinga, nici acum, niciodata. Situatia este unul dintre acele momente in care pur si simplu nu ai timp sau spatiu mental pentru a o pune la indoiala. Va trebui doar sa acceptati ca va fi asa pana cand veti trece complet din sistemele dvs.

Array

vechi.

Dar procesul de tranzitie va dura mult timp si nu doriti ca codul dvs. sa fie prea impletit cu vechiul cod. Ce faci?

In astfel de situatii, modelul adaptorului este util.

Modelul adaptor introduce o bucata de cod intermediara care face ca doua parti ale unui sistem sa fie compatibile intre ele.

Array

De asemenea, injecteaza un element de cuplare de pierdere, pastrand cele doua bucati de cod separate. Inseamna ca va puteti scrie codul oricum doriti, fara a fi nevoie sa luati in considerare cealalta bucata de cod. Codul adaptorului dvs. va face traducerea necesara si va va oferi ceea ce aveti nevoie si in orice format doriti.

Cand se modifica o parte a codului, trebuie sa schimbati doar adaptorul pentru acea parte, in loc de ambele parti ale aplicatiei.

Deci, cum scrieti exact un model de adaptor in JavaScript?

Nu exista nicio modalitate reala de a-l scrie ca atare. Este mai mult o idee conceptuala, iar codul in sine depinde de situatia pe care incercati sa o legati. Este un proces de abstractizare a datelor de care aveti nevoie dintr-un obiect extern sau terta parte. Pentru a face acest lucru, cream adesea o interfata care sa ne reprezinte adaptorul si sa cream conexiunile necesare intre cele doua parti.

Un lucru de luat in considerare este ca adaptorul are o singura directie de dependenta. Adaptorul consuma doar ceea ce isi propune sa traduca. In majoritatea cazurilor, este API vechi sau biblioteci terte. Nu face altceva decat sa formeze o conexiune intre cele doua parti ale unei aplicatii. Nu ar trebui sa contina nicio logica de afaceri.

In mod conventional, un adaptor se afla intr-un folder utils si apoi este importat intr-un fisier atunci cand este necesar. Cu toate acestea, poate fi si o functie autonoma.

Sa aruncam o privire mai intai la versiunea de clasa exportata.

// serviciul dvs. cos de date originale

// acesta este doar un nume ipotetic de

import {v4 ca cos} din „cartServiceV4“ clasa CartServiceAdapter { getCart () { // un cod de cos // folosind date de la serviciul importat cos // poate transformati iesirea originala pentru a se potrivi cu nevoile dvs. cos de returnare; }

removeItemFromCart () {

// un cod de

cos returneaza cosul de cumparaturi;

}

// etc

} export implicit nou CartService ();

importul aduce ceea ce doriti sa traduceti. exportul face ca CartServiceAdapter sa fie disponibil pentru utilizare de catre orice persoana care il importa.

Cand aveti nevoie de datele despre cos, trebuie doar sa importati adaptorul in cod folosind import.

import cos din “./utils/CartServiceAdapter” console.log (cart.getCart ());

Cum arata acest cod ipotetic in forma de diagrama:

diagrama de Aphinya Dechalert

Aceasta inseamna ca, mai degraba decat sa fortezi noul cod de cos sa se conformeze nevoilor misteriosului cod original, poti scrie doar un adaptor care traduce originalul pentru a se potrivi cu noul cod. Ca urmare, sunteti liber sa va construiti codul oricum doriti.

De asemenea, puteti scrie adaptoarele ca functii normale, mai degraba decat ca o clasa. Nu exista restrictii cu privire la modul in care il scrieti. Iata un exemplu de cum poate arata o posibila interfata ca functie:

// date originale despre cos care nu pot fi modificate la sursa

// sa ne prefacem ca provin dintr-un serviciu de date misterios

// nu avem acces direct la acest

var cart = [

{item: “vintage clock”, sku: 9284, valoare: 15,99 },

{item: „carute“, motiva N: 9232, valoarea: 19,99}

] // vechi trage de interfata in datele de la serviciul de date misterios // suntem nu este permis sa atinga aceasta functie cos () { this.cart retur ; } // codul nostru adaptor pentru a traduce date // ne impiedica de la consumul Cart () in mod direct functiona CartAdapter () { var originalCart = cos (); var adapterCart = originalCart.map (functie (obj) { return {

item: obj.item,

productId: obj.sku,

pret: obj.value

}

});

return adapterCart;

} // acum putem folosi rezultatul CartAdapter () , dar noi vrem // schimbari in cos () va avea ca rezultat doar o modificare a adaptorului // restul ramasitelor de cod necontaminate odata ce adaptorul este fixat consola. log (CartAdapter ());

In exemplul de mai sus, ne prefacem ca formatul de date al cosului nu poate fi modificat, fiind introdus in aplicatie prin intermediul functiei Cart (). Cart () poate fi vazut ca vechea interfata pe care nu vrem sa o atingem. CartAdapter () ca element intermediar de cod care ne impiedica sa consumam direct Cart (). Cand ceva se schimba in Cart (), trebuie doar sa schimbam CartAdapter (), mai degraba decat familia de functii care ar putea consuma direct datele din Cart ().

Modelul adaptorului este util atunci cand lucrati pe mai multe platforme, surse de date, biblioteci si cadre. Acesta umple golurile cauzate de diferitele cerinte si diferentele de mediu. Contextul codului original poate avea sens, dar nu si in cazul in care trebuie consumat. Modelul adaptorului face acest lucru posibil prin conectarea diferitelor surse.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR