Programare funcțională în JavaScript: arity și tuples

x

Confidențialitate și cookie-uri

Acest site utilizează cookie-uri. Continuând, acceptați utilizarea dvs. Obțineți mai multe informații; De exemplu, despre cum să controlați cookie-urile.

inteles

14787298814_2ED9B48A0_K.JPG

Ne întoarcem la seria poștală dedicată programării funcționale în JavaScript. Am explicat importanța utilizării metodelor în lanț pentru a obține un cod mai expresiv.

în postarea de astăzi Vom vorbi despre dezavantajele care ne aduc folosirea metodelor înlănțuite. Vom învăța o nouă modalitate de a ne moderniza codul și de a lua mult mai multă petrecere la reutilizarea codului prin conceptul de țevi care pot fi utilizate în programarea funcțională.

Vom explica ce sunt conductele și Caracteristici Avem nevoie de faptul că îndeplinesc funcțiile pentru a putea atinge această senzație de cod care curge prin intermediul unei țevi conectate. Vom explica care este aritatea și modul în care atingerea sau curricorile ne pot ajuta să gestionăm complexitatea arresilor înalte.

Ca întotdeauna, mă aflu la dispoziția dvs. în comentariile în cazul în care ar putea rezolva oricare dintre îndoielile dvs. . Să începem:

Problema metodelor înlănțuite

Metodele înlănțuite ne ajută foarte mult să scriem un cod mai bun. Am putea vedea-o în capitolul anterior. Care nu se schimbă. Cu toate acestea, găsim o mare problemă la metodele înlănțuite.

Dacă ne amintim, de exemplu, metoda „filtru” a ES5, metoda returnează un nou obiect de matrice care conține metodele din nou. Prin urmare, magia de a fi capabilă săiba. Din păcate, modelul este o armă cu două tăișuri, deoarece metodele sunt atât de cuplate la tipul de obiect care ne convine ne dă foarte puțin flexibilitate de reutilizare.

cu metode concatenate Suntem obligați să folosim numai setul de operațiuni care oferă obiectul însuși. Ar fi ideal că am putea sparge acest lanț și în cadrul adunării am putea organiza funcții la pofta noastră. Metodele înlănțuite nu sunt soluția, deci va trebui să ne căutăm o altă alternativă.

Țevile

și alternativa vine sub formă de țeavă. Dacă, cu metodele înlănțuite am pierdut expresivitatea și câștigând prea multă cuplare, cu organizarea de funcții într-o țeavă am putea avea opusul.

Cheia organizării funcțiilor în conducte este aceea de a fi capabil să aibă un Arsenal de funcții decuplate care pot fi executate secvențial. Ca și într-o țeavă, funcțiile noastre ar petrece stări de o funcție la altul. Parametrii de ieșire ai unei funcții vor presupune parametrii de intrare din următoarele Poate crea un program major.

Dacă folosim notația utilizată în Haskell, putem explica mai bine acest lucru. Putem defini funcții în acest fel:

<nombre_funcion> :: <entradas> -> <salidas>

În cele din urmă este foarte asemănător cu definirea Lambdas, numai în acest caz, suntem mai interesați de cunoașterea a ceea ce Tipurile de date introduc și lasă o funcție. Este specificația unei cutii negre.

Am văzut asta, să vedem un exemplu. Pot să compun prin conducte următoarele funcții:

f :: A -> Bg :: B -> C

unde f și g sunt numele unei funcții și A, B și C sunt diferite tipuri. În acest caz, deoarece ieșirea F se potrivește cu tipul de B. le-aș putea executa ca și cum ar fi o țeavă:

g(f(A)); // donde se devuelve C

Acest lucru pare la prima vedere pare Evident, ne puteți ajuta foarte mult. Nu va fi ușor să obțineți acest lucru în medii mai complexe, deoarece vor exista funcții care returnează obiectele care nu pot fi reutilizate.

Cu toate acestea, este ceva ce trebuie să luăm în considerare la proiectarea funcțiilor. Este important să vedem că trebuie să facem funcții compatibile între ele. Pentru a conștientiza acest lucru în procesul de proiectare, este important să luăm în considerare doi factori: compatibilitatea tipurilor de intrări și ieșiri și aripă a funcțiilor.

Tip compatibilitate

ca Am spus, compatibilitatea tipului se referă la tipurile de ieșire ale funcției se referă la tipurile de parametri de intrare de la altul. Nu este o problemă pe care trebuie să ne îngrijorăm foarte mult în JavaScript, deoarece, la sfârșit, la întâlnirea cu un limbaj slab tipic, putem avea mult mai multă flexibilitate.

În cele din urmă este ceea ce se numește de obicei „tipuri de rață”, nu sunt interesat de conductele JavaScript atât de mult încât tipurile sunt identice și că obiectul care returnează o funcție, se comportă ca tipul de tip parametrul de intrare care așteaptă următoarea funcție. Asta este, dacă merge ca o rață și grasna ca o rață, este o rață. Dacă un obiect se comportă un tip specific și are atributele pe care le aștept în acest tip, pentru mine este tipul ăla. Este cel bun și lucrul rău despre JavaScript.

Dacă am vrut să facem ca funcțiile noastre strict compatibile, o idee bună ar fi să folosim TipsCript. Am lăsat chat-ul lui Micael Galician din nou aici, în cazul în care sunteți interesat de această alternativă.

Prin urmare, atunci când proiectăm funcții, trebuie să avem foarte clar băieții cu care funcționează funcțiile noastre. Imaginați-vă că vrem să facem un sistem care să dăm un număr de identitate, eliminăm spațiile și scripturile pentru a funcționa mai bine cu ea. Vom proiecta două funcții ca acestea:

iv id = „64Aec4bda5”

Am creat două funcții compatibile pentru compoziție, deoarece intrarea unuia se potrivește cu tipul celuilalt. Ele sunt, de asemenea, comutative deoarece, dacă am rulat tălg și apoi normalizez, am același rezultat ca și cum aș rula mai întâi „normalize” și apoi „Trim”. Să vedem implementarea.

vale, exemplul este foarte prost, dar este important să fim conștienți de el în viitor. Vom avea mai multe probleme în JavaScript cu numărul de parametri care pot permite o funcție.

Atitudinea și tuplele

Știm prin aritime la numărul de parametri de intrare care acceptă o funcție . Este obișnuit să se indice ca o lungime a unei funcții.

Atitudinea unei funcții poate face o funcție de o funcție în complexitate. Că o funcție acceptă mai mulți parametri face ca toate argumentele să fie calculate mai întâi, acest lucru le face să piardă versatilitatea.

În plus, poate fi cazul că complexitatea internă a unei funcții este mai mare (care este o mare aritică Nu se comportă întotdeauna o complexitate mai mare, poate fi pur și simplu un simptom al acestuia).

având arrate crescute în plus, ne face să avem funcții mai puțin flexibile. Funcțiile cu un parametru (sau unitate) sunt, de obicei, mai flexibile deoarece, în general, au doar o singură responsabilitate, să efectueze un anumit tip de funcționare sau să calculeze parametrul de intrare și să returneze rezultatul.

Din păcate, În viața reală, este complicat să se întâlnească numai de unire. Cu toate acestea, putem face o funcție returnează o tuplă, în felul acesta, următoarea funcție ar fi o respinsă și aș avea deja tot statul de care aveți nevoie.

A TUPLA este o listă finită și ordonată a valorilor Care sunt reprezentate după cum urmează (a, b, c). Tuples sunt un pachet de valori imuabile, care au o relație și care pot fi folosite pentru a returna mai multe valori la alte funcții.

Putem simula acest comportament cu un obiect JSON sau cu obiecte de matrice, de îndată După cum vedem apoi cu tuplele avem mai multe avantaje:

  • sunt imuabile.
  • evita crearea de noi tipuri. De multe ori pentru a crea clase pentru o singură utilizare specifică poate fi destul de ieftină pentru dezvoltator.
  • Evitați crearea de matrice eterogene: Lucrul cu aceste mastere eterogene presupune o mulțime de verificări de tip. Arrays este mai bine să le folosească atunci când lucrați cu colecții de obiecte cu același tip.

Problema pe care o avem este că, deși Tupes este un element în majoritatea limbajelor de programare funcționale ca Scala, în JavaScript Nu există nimic care să accepte tuplele. Cea mai bună opțiune este că credem că un mic librărie care susține tuplele. Opțiunea pe care Luis atenția propune în cartea dvs. este:

const Tuple = function () { const typeInfo = Array.prototype.slice.call(arguments, 0); const _T = function () { const values = Array.prototype.slice.call(arguments, 0); if (values.some((val) => val === null || val === undefined) { throw new ReferenceError('Tuples may not have any null values'); } if (values.length !== typeInfo.length) { throw new TypeErro('Tuple arity does not match its prototype'); } values.map(function (val, index) { this = checkType(typeInfo)(val); }, this); Object.freeze(this); }; _T.prototype.values = function () { return Object.keys(this).map(function (k) { return this; } } return _T;}

uf, da, o mulțime de Chicha să taie. Dacă ne dăm seama că este o funcție de tuplă care va returna o clasă. Funcția servește astfel încât să putem indica dimensiunea și tipurile elementelor Tupla. Prin urmare, putem face acest lucru, de exemplu:

const Status = Tuple(Number, String);

„Stare” este o clasă. Dacă vă dați tuble, se întoarce _t. Prin intermediul unui client, o clasă preconfigurată este returnată cu ceea ce avem nevoie. Magic. Acum putem defini un nou tuplu în acest fel:

const status = new Status(401, 'No Authorize');

atunci când am instanțiat „statutul”, face o verificare că valorile nulă nu se întâmplă și asta Dimensiunea tuplei create corespunde cu dimensiunea TUPLA predefinită. De asemenea, verifică că tipul care sa întâmplat este de așteptat.

În cele din urmă, are o metodă, astfel încât să putem obține valorile în format de matrice.Este foarte util, deoarece dacă folosim din nou distrugerea, putem obține valorile TUPI în acest fel:

const = status.values();

bun … ei nu sunt cele mai confortabile ale lumii tuples în JavaScript, dar avem modalități de ao simula. Dacă nu trebuia să le simulăm? Ce se întâmplă dacă le-au adus Js și le-a adus în mod serios? Ei bine, din nou, TipsCript ne ajută în acest sens. Aș putea face acest lucru:

let status: ; status = ; // OK status = ; // Error

mult mai bine :). Repet, păstrez în minte, a ajuns să rămână.

tuples sunt un mecanism bun pentru a evita arestarea funcțiilor. Cu toate acestea, există o altă metodă numită curricorială, care nu numai că ne va ajuta cu aratia, dar este un mecanism bun de îmbunătățire a modularității și reutilizabilității, dar … cred că vom pleca aici pentru ziua de azi 🙂

Concluzie

Înțelegerea țevilor și căile lor de a le folosi, ne va ajuta să dezvoltăm un cod mai ușor de citit. Vom continua să vorbim despre tehnici necesare pentru a acoperi toate conceptele care sunt prezente în țevi.

Pentru moment, cred că este un pas bun, știind că funcțiile de proiectare, astfel încât să aibă o redusă și să cunoască Tipuri din parametrii de intrare și ieșire a funcțiilor noastre, ne vom ajuta să facem un cod mult mai menit, modulularizabil și reutilizabil.

Am citit 🙂

Pd: Plec conceptual Harta acestei intrări:

The-țevi-en-javascript

Posturi de programare funcționale JavaScript Posturi:

Introducere

  1. Programare funcțională în JavaScript
  2. Programare funcțională în JavaScript: Obiectele
  3. Funcțional Programare în JavaScript: Funcții

Controlul fluxului funcțional

  1. Programare funcțională în JavaScript: Metode funcționale
  2. Programare funcțională în JavaScript: RECURRION

modularitate funcțională

  1. Programare funcțională în JavaScript: Aritive și Tuples
  2. Programare funcțională în JavaScript: Curricory

acoperire imagine | Flickr

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *