Dacă pentru scurt timp - desigur, da.
Pentru a da un răspuns mai detaliat, să înțelegem cu toții: de ce lucrăm cu ei?
În esență, expresiile lambda sunt necesare deoarece descriu ce calcule trebuie să fie efectuate și nu cum să le execute. În mod tradițional, am lucrat cu o iterație externă, care a indicat în mod clar întreaga secvență de operațiuni, precum și modul în care sunt realizate.
Repetarea exterioară este executată în buclă for. iar acest ciclu indică cu exactitate cum se face. Acest cod este redundant și este reprodus repetat în programe. Cu toate acestea, cu foreach ciclul ordonăm vorbesc de apel de program (aici - prin referire la metoda, care este mai concisă decât lambda) pentru fiecare element, dar nu trebuie să descrie modul în care funcționează ciclul. Iterația este prelucrată intern, la nivelul de buclă forEach.
Această motivație este "ce, și nu cum" în cazul expresiilor lambda este de bază. Dar pentru a înțelege închiderile, trebuie să luați în considerare motivația programării funcționale ca atare.
Lambda-expresii / închideri sunt proiectate pentru a simplifica programarea funcțională. Java 8 - desigur, nu un limbaj funcțional, dar (ca în Python) este acum oferit un sprijin pentru programarea funcțională, aceste capacități sunt construite pe paradigma orientată pe obiecte de bază.
Ideea de bază a programării funcționale este că puteți crea și manipula funcții, în special, să creați funcții în timpul rulării. În consecință, programul dvs. poate gestiona nu numai date, ci și funcții. Imaginați-vă ce oportunități sunt disponibile pentru programator.
Într-un limbaj de programare pur funcțional, există și alte limitări, în special - invarianța datelor. Asta înseamnă că nu aveți variabile, doar valori neschimbate. La prima vedere, această restricție pare excesivă (? Cum funcționează, în general, fără variabile), dar se pare că, de fapt, folosind valorile obținute toate la fel ca și variabila (doresc să facă - să încerce să lui Scala, că limbajul nu este pur funcțională , dar oferă posibilitatea de a folosi valori peste tot). Funcțiile invariante iau argumente și returnează rezultatul fără a schimba mediul; astfel încât acestea sunt mult mai ușor de utilizat pentru programarea paralelă, deoarece funcția invarianta nu blochează resursele partajate.
Înainte de lansarea Java 8, puteți crea funcții la momentul executării într-un singur mod: generați și încărcați octetul (aceasta este o operație destul de confuză și complexă).
Pentru expresiile lambda, următoarele două caracteristici sunt tipice:
- O sintaxă mai concisă pentru crearea funcțiilor
- Abilitatea de a crea funcții în timpul rulării; atunci aceste funcții pot fi transferate într-un alt cod sau alt cod le poate opera.
Închiderea se referă la a doua posibilitate
Ce este o închidere?
La închidere, se folosesc variabile care se află în afara scopului funcției. În programarea tradițională procedurală, aceasta nu este o problemă - utilizați doar o variabilă - dar problema apare odată ce începem să creăm funcții în timpul rulării. Pentru a ilustra această problemă, voi da mai întâi un exemplu cu Python. Aici, make_fun () creează și returnează o funcție numită func_to_return. care este apoi utilizat în restul programului:
Deci, ne confruntăm cu o astfel de problemă: dacă vă întoarceți pur și simplu func_to_return. care va fi cu n. situat în afara domeniului func_to_return. În mod normal, v-ați aștepta ca n să părăsească domeniul de aplicare și să devină indisponibil, dar dacă se întâmplă acest lucru, func_to_return nu va funcționa. Pentru a susține crearea dinamică a funcțiilor func_to_return, trebuie să "închidă" în jurul lui n și să se asigure că "supraviețuiește" până când funcția revine. Prin urmare, termenul "închidere".
Pentru a testa make_fun (). O numim de două ori și stocăm rezultatul funcției în x și y. Faptul că x și y produc rezultate complet diferite demonstrează că, de fiecare dată când make_fun () sună, funcționează complet independent funcția func_to_return cu propriul spațiu de stocare închis pentru n apare.
Expresii Lambda în Java 8
Luați în considerare același exemplu în Java folosind expresiile lambda:
Se pare că expresiile lambda din Java sunt înfășurate numai în jurul valorilor, dar nu în jurul variabilelor. Java cere ca aceste valori să fie neschimbate, ca și cum le-am fi declarat finale. Deci, ei trebuie să fie definitivi, indiferent dacă le-ați declarat sau nu așa. Aceasta este, de fapt, "finală". De aceea, în Java, există "închideri cu constrângeri" și nu închideri "cu drepturi depline", care, totuși, sunt destul de utile.
Totul este compilat fără probleme, pentru a vă asigura de acest lucru, puteți pune pur și simplu ultimul cuvânt cheie în definiția lui n. Desigur, dacă aplicați această mișcare în orice competiție, atunci va exista o problemă cu starea comună modificabilă.
Expresiile Lambda - cel puțin în parte - vă permit să atingeți obiectivul dorit: acum puteți crea funcții dinamic. Dacă plecați în străinătate, veți primi un mesaj de eroare, dar, de obicei, astfel de probleme sunt rezolvate. Rezultatul nu va fi la fel de simplu ca Python, dar este totuși Java. Și rezultatul final, nu fără anumite limitări (să recunoaștem, orice rezultat în Java nu este fără anumite limitări) nu este atât de rău.
Am întrebat de ce aceste structuri erau numite "lambda" și nu doar "închiderile" - de fapt, prin toate indicațiile, ele sunt închideri pure. Mi sa spus că "închiderea" este un termen nefericit și supraîncărcat. Când cineva spune "închidere reală", adesea înseamnă "închideri" pe care a primit-o în primul limbaj de programare dezvoltat, în care erau entități numite "închideri".
Nu văd o dispută între PLO și OP, însă nu am intenționat să o aranjez. Mai mult, nici măcar nu văd "împotrivă" aici. OOP este foarte potrivit pentru captarea de date (și chiar forțele Java să lucrați cu obiecte, aceasta nu înseamnă că orice problemă este rezolvată cu ajutorul obiectelor), iar tranziția de fază - la comportamente abstracte. Ambele paradigme sunt utile, și, în opinia mea, cu atât mai util în cazul în care acestea sunt confundate - și în Python, și Java 8. Am avut recent ocazia de a lucra cu pandoc - convertor, scrise într-un limbaj pur funcțional Haskell, și eu încă mai au cea mai mare parte impresii pozitive. Astfel, limbile pur funcționale merită, de asemenea, un loc sub soare.