ebben a blogbejegyzésben bemutatom az interfészek fogalmát és azt, hogy ezek hogyan lehetnek hasznosak még dinamikus nyelveken is. Én is használni a könyvtár végre.js, hogy a koncepció a JavaScript, és megmutatja, hogyan lehet egy kis extra segédprogram ki interfészek.
a Google úgy definiálja az interfészt, mint “egy pontot, ahol két rendszer, alany, szervezet stb. meet and interact”, és ez a meghatározás igaz a programozási interfészekre. A szoftverfejlesztésben az interfész olyan struktúra, amely bizonyos tulajdonságokat érvényesít egy objektumon — a legtöbb nyelven ez az objektum osztály.
itt van egy példa egy interfészre a Java-ban:
a fenti példában a Car interfész egy olyan osztályt ír le, amelynek két metódusa van visszatérési típus nélkül, mindkettő egyetlen egész argumentumot vesz fel. Az egyes funkciók végrehajtásának részletei az osztályra hárulnak, ezért a módszereknek nincs testük. Annak érdekében, hogy egy osztály megvalósítsa a Car felületet, a implements kulcsszót használjuk:
interfészek a JavaScript-ben
az interfészek nem egy dolog a JavaScript-ben, nem igazán. A JavaScript egy dinamikus nyelv, olyan, ahol a típusokat olyan gyakran változtatják meg, hogy a fejlesztő talán még észre sem vette, ezért az emberek azzal érvelnek, hogy nincs szükség interfész hozzáadására az ECMAScript szabványhoz, amelyen a JavaScript alapul.
a JavaScript azonban nagymértékben nőtt háttérnyelvként Node formájában.js, és ezzel együtt más követelmények és más tömeg, akiknek más véleménye lehet. Ehhez hozzá kell tenni, hogy a nyelv gyorsan a front-end eszközzé válik; odáig jutott, hogy sok fejlesztő HTML-jének túlnyomó részét belül írja .js fájlok formájában JSX.
tehát ahogy a nyelv egyre több szerepet tölt be, hasznos, ha megbizonyosodunk arról, hogy az egyik legfontosabb adatstruktúránk az, amire számítottunk. A JavaScript lehet a class kulcsszó, de valójában ez csak egy eltávolított konstruktor függvény, és egyszer csak objektumnak hívják. A tárgyak mindenütt jelen vannak, ezért néha előnyös annak biztosítása, hogy megfeleljenek egy adott alaknak.
nemrég a munkahelyen találtam egy esetet, amikor egy fejlesztő azt várta, hogy egy API-válasz részeként visszaküldött tulajdonság true, de ehelyett "true" hibát okoz. Könnyű hiba, amelyet szintén elkerülhettünk volna, ha lenne interfészünk.
de várj, van még!
interfészek, néhány kisebb módosítással, felhasználhatók objektumok átalakítására. Képzelje el egy “szigorú” felület megvalósítását, ahol az interfészen kívüli tulajdonságok nem engedélyezettek, törölhetjük vagy átnevezhetjük ezeket a tulajdonságokat, vagy akár hibát is dobhatunk, ha találkozunk velük.
tehát most van egy felületünk, amely megmondja nekünk, ha hiányoznak bizonyos tulajdonságok, de akkor is, ha váratlan tulajdonságaink vannak, vagy ha a tulajdonságok típusai nem olyanok, mint amire számítunk. Ez más lehetőségeket is hozzáad, mondjuk például egy API válaszának újratervezését, miközben hozzáadja ezt az extra biztonsági réteget az interfész szokásos viselkedéséhez. Használhatnánk interfészeket az egységtesztekben is, ha vannak hibák.
végrehajtása.js
végrehajtása.js egy könyvtár, amely megpróbálja, hogy interfészek JavaScript. Az ötlet egyszerű: definiáljon egy interfészt, határozza meg a tulajdonságok típusát, és használja azt annak biztosítására, hogy egy objektum az legyen, amire számít.
Beállítás
először telepítse a csomagot:
npm install implement-js
ezután hozzon létre egy .implementInterface, és type:
az első interfészünk
egy interfész létrehozásához egyszerűen hívja a Interface — t, és adja át egy karakterláncban a felület nevét-ez nem ajánlott, de ha kihagyja a nevet, egy egyedi azonosító jön létre. Ez egy olyan függvényt ad vissza, amely elfogad egy objektumot, ahol a tulajdonságok mindegyike type objektumok, egy második argumentum is átadható a figyelmeztetések megjelenítésére, hibák eldobására, tulajdonságok törlésére vagy átnevezésére, annak biztosítására, hogy csak az interfész tulajdonságai legyenek jelen, vagy egy meglévő Interface.
itt van egy felület, amely leírja az autót:
van egy seats tulajdonság, amelynek típusszámúnak kell lennie, egy utas tömb, amely olyan objektumokat tartalmaz, amelyeknek maguknak kell végrehajtaniuk a Passenger felületet, és tartalmaz egy seats tulajdonság, amelynek függvénynek kell lennie. A error és strict opciók true értékre lettek állítva, ami azt jelenti, hogy a hibák akkor jelennek meg, ha az interfész egyik tulajdonsága hiányzik, illetve ha a felületen nem található tulajdonság található.
az interfész megvalósítása
most végre akarjuk hajtani az interfészünket, egy egyszerű példában létrehozunk egy objektumot egy objektum literál használatával, és meglátjuk, hogy képesek vagyunk-e megvalósítani az interfészünket.
először létrehozunk egy Ford objektumot, majd megpróbáljuk megvalósítani a Car interfész:
amint azt a a fenti megjegyzés, Ez hibát dob. Nézzük vissza a Car interfészünket:
láthatjuk, hogy bár az összes tulajdonság jelen van, a szigorú mód is igaz, ami azt jelenti, hogy a kiegészítő tulajdonság fuelType hibát okoz. Továbbá, bár van egy passengers tulajdonságunk, ez nem tömb.
Az interfész helyes megvalósítása érdekében eltávolítjuk a fuelType értéket, és megváltoztatjuk a passengers értékét, hogy ez egy olyan tömb legyen, amely objektumokat tartalmaz, amelyek végrehajtják a Passenger interfészt:
” de a JavaScript nem objektum-orientált nyelv!”
igaz, hogy míg az interfészek jellemzően objektumorientált nyelvekhez vannak társítva, és a JavaScript egy több paradigmás nyelv, amely prototípus örökséget használ, az interfészek továbbra is nagyon hasznosak lehetnek.
például a implement-js használatával könnyedén refaktorálhatunk egy API-választ, miközben biztosítjuk, hogy az ne térjen el attól, amit várunk. Íme egy példa, amelyet a redux-thunk:
először definiáljuk a TwitterUser interfészt, amely kiterjeszti a User interfészt, mint objektumot a twitterId és twitterUsername tulajdonságok. trim igaz jelentése, hogy elvetünk minden olyan tulajdonságot, amely nem szerepel a TwitterUser felületen. Mivel az API barátságtalan formátumban adja vissza a tulajdonságokat, átneveztük a twitter_username és twitter_id tulajdonságokat camelcase verziókra.
ezután definiálunk egy aszinkron műveletet a redux-thunk paranccsal, a művelet API-hívást indít, és a TwitterUser interfészünkkel eldobjuk azokat a tulajdonságokat, amelyeket nem akarunk, és biztosítjuk, hogy a várt tulajdonságokat a megfelelő típusokkal valósítsa meg. Ha inkább tisztán szeretné tartani az akcióalkotóit (er), vagy nem használja a redux-thunk, akkor érdemes ellenőrizni a twitterService.getUser belső felületet, és visszaadni az eredményt.
Megjegyzés: Az interfész kiterjesztésekor az opciók nem öröklődnek
az Egységtesztek szintén megfelelő helyek az interfészek használatához:
összefoglalva
láttuk, hogy az interfészek hasznosak lehetnek a JavaScript-ben: annak ellenére, hogy rendkívül dinamikus nyelv, az objektum alakjának és tulajdonságainak ellenőrzése egy adott adattípus, egy extra biztonsági réteget ad nekünk, amelyet egyébként kihagynánk. Az interfészek koncepciójára építve és a implement-js használatával a hozzáadott biztonság mellett további hasznosságot is szereztünk.