7 näpunäidet, kuidas panna oma Kotlini raamatukogu särama

Eessõna

Kui alustame programmeerimist uues keeles, peame alguses kinni paradigmadest ja harjumustest, mida saate programmeerida juba meile teadaolevas keeles. Ehkki see võib alguses tunduda korras, on inimeste jaoks, kes programmeerivad keelt, mida proovite mõnda aega õppida, see ebatasasus üsna ilmne.

Kui olin umbes kaks aastat tagasi Java-st Kotlini poole üle läinud, tegelesin põhimõtteliselt Java programmeerimisega, kuid Kotlinis. Ehkki Kotlin oli minu jaoks justkui värske õhu hingetõmbejõud, kasutasin Android-insenerina kõiki neid vastikaid sõmedaid laiendusfunktsioone ja andmeklasse ega olnud alati järjekindel. Teisendasin olemasoleva Java-koodi Kotliniks ja selle vaatamine aitas mõne aja pärast mul meeles pidada mõnda ideed, kui kavandasin Kotlini erinevate korduvkasutatavate komponentide või raamatukogude jaoks API-sid.

BUX-is töötame kahe rakenduse kallal, millel on paar ühist teeki. Kui Stocks'i rakendus (mida veel ei avaldata) kirjutati Kotlinis algusest peale, siis esimene CFD-rakendus kirjutati Java-keeles ja teisendati mõne aja pärast Kotliniks. Praegu on CFD rakendus 78,7% Kotlin, mis tähendab, et me töötame selle kallal endiselt ja seetõttu on oluline pöörata tähelepanu raamatukogu API-dele, mida haldavad kaks meeskonda, kes kasutavad korraga nii Java kui Kotlin.

Nii et kui teil on olemas Kotlini või Java raamatukogu, mida soovite Kotlinifitseerida, või kavandate API-d Kotlini abil nullist, võtke minuga ette ideid, mida saaksite teha oma raamatukogu kasutajate elu lihtsustamiseks.

1. Laiendusfunktsioonid

Enamasti, kui peate olemasolevat klassi laiendama uue funktsionaalsusega, kasutate kas mingisugust kompositsiooni või tuletate uue klassi (mis laialdase kasutamise korral võib muuta teie klassi hierarhia sama habras nagu IKEA klaasist tassid). Pole tähtis, mida te eelistate, on Kotlinil selle jaoks oma vastus, mida nimetatakse laiendusfunktsioonideks. Lühidalt - see võimaldab teil olemasolevale klassile uue funktsiooni lisada üsna ilusa süntaksiga. Näiteks Androidis saate määratleda uue meetodi Vaade klassi jaoks järgmisel viisil:

Seda silmas pidades võivad paljud raamatukogud, mis pakuvad olemasolevatele klassidele lisafunktsioone (ntView, Context jne), selle asemel et kasutada dekoraatoreid, staatilisi tehasemeetodeid või midagi muud, saavad kasu nende funktsionaalsuse pakkumisest, kuna laiendfunktsioonid toimivad sujuvalt, justkui funktsionaalsus eksisteeriks algklassides algusest peale.

2. Argumendi vaikeväärtused

Kotlin oli algselt mõeldud Java lühikeseks, ilusaks ja korrektseks versiooniks ning selgub, et see teeb funktsiooni vaikimisi argumentide vaikeväärtustega seda väga hästi. API pakkuja saab määratleda vaikimisi väärtused argumentide jaoks, mille võib ära jätta. Oleksin tõesti üllatunud, kui te pole Androidi SQLite'iga töötades sarnast koodi näinud:

Ehkki selles meetodis on rohkem vigu kui nende koledate nullide lõpus, ei ole ma siin selleks, et kohut mõista, vaid pigem öelda, et need ajad on möödas, ja seaksin tõsiselt kahtluse alla Kotlini niimoodi kirjutatud koodi. Niisuguseid näiteid on palju, kuid õnneks saame nüüd paremini hakkama ja kui varustate Builderi asemel või lisaks sellele Builderi pakkumisega välise API koos teatud häälestamisparameetritega, kaaluge vaikimisi argumentide väärtuste kasutamist. Sellel on vähemalt kaks eelist: esiteks, te ei sunni kasutajat määrama valikulisi parameetreid või mida iganes te ennustate, ning teine ​​on see, et kasutajal on vaikekonfiguratsioon, mis töötab lihtsalt välja -boks:

Samuti tasub siinkohal mainida, et kui lisate vaikeväärtustega argumendid lõppu, ei pea kasutaja määrama kohustuslike parameetrite nimesid.

3. Objektid

Kas olete kunagi pidanud Java-s Singletoni mustrit rakendama? Tõenäoliselt oli teil ja kui jah, siis peaksite teadma, kui tülikas see mõnikord võib olla:

Rakendusi on erinevaid, millel on oma plussid ja miinused. Kotlin käsitleb kõiki neid 50 Singletoni mustri teostuse varjundit ühe struktuuriga, mida nimetatakse objektideklaratsiooniks. Vaadake, pole "kahekordse kontrollimisega lukustust":

Mis on süntaksi kõrval lahe, on see, et objektideklaratsiooni initsialiseerimine on nii lõimekindel kui ka esmakordselt lahtiselt vormindatud:

Selliste raamatukogude jaoks nagu Fabric, Glide, Picasso või mõni muu, mis kasutab kogu raamatukogu API peamise sisenemispunktina objekti üksikut eksemplari, on nüüd loomulik viis minna edasi ja pole põhjust kasutada vana Java viisi tee samu asju.

4. Lähtefailid

Samamoodi mõtleb Kotlin paljudele süntaktilistele väljakutsetele, millega igapäevaselt silmitsi seisame, see mõeldab ka seda, kuidas me oma loodud koodi korraldame. Kotlini lähtefailid on koduks mitmele semantiliselt lähedasele deklaratsioonile. Selgub, et need on ideaalne koht mõne sama klassiga seotud laiendusfunktsiooni määratlemiseks. Vaadake seda Kotlini lähtekoodi lihtsustatud katkendit, kus kõik teksti manipuleerimiseks kasutatavad laiendifunktsioonid asuvad samas failis “Strings.kt”:

Teine sobiv näide selle kasutamisest on teie API-ga suhtlusprotokolli määratlemine koos andmeklasside ja liidestega ühes lähtefailis. See võimaldab kasutajal mitte kaotada fookust, vahetades erinevate failide vahel voolu jälgides:

Kuid ärge minge sellega liiga kaugele, kuna riskite faili suurusega kasutajale liiga teha ja muuta see RecyclerView-klassiks, kus on ~ 13.000 rida .

5. Korutiinid

Kui teie teek kasutab võrku pääsemiseks või mõne muu pikaajalise töö tegemiseks mitut lõime, kaaluge peatamise funktsioonide API pakkumist. Kotlin 1.3-st alates ei ole juhuuuringud enam eksperimentaalsed, mis on suurepärane võimalus hakata neid tootmises kasutama, kui olete varem kahelnud. Juhtnöörid võivad mõnel juhul olla heaks alternatiiviks RxJava jälgitavale ja muudele asünkroonkõnede käsitlemise viisidele. Mida te juba varem võisite näha, on API täis meetodeid tulemuste tagasikutsumisega või Rx hype ajal, mis on mähitud ühekordseks või komplekteeritavaks:

Kuid praegu oleme Kotlini ajastul, nii et selle võiks kavandada ka juurte kasutamise soodustamiseks:

Hoolimata asjaolust, et juustutooted toimivad paremini kui vanad head Java-lõimed, on need kergemad, kuid aitavad neil koodi loetavust märkimisväärselt suurendada:

6. Lepingud

Koos stabiilsete juhenditega tutvustab Kotlin 1.3 arendajatele ka kompilaatoriga suhtlemise viise. Leping on uus funktsioon, mis võimaldab meil raamatukogu arendajatena jagada kompilaatoriga meie teadmisi, täpsustades nn efekte. Toome selle lähima analoogia Java-st, et oleks lihtsam aru saada, mis see on. Tõenäoliselt on enamik teist näinud või isegi kasutanud Guajavast pärit eeltingimuste klassi paljude väidete ja selle kohandamisega raamatukogudes nagu Dagger, kes ei soovi kogu raamatukogu kokku tõmmata:

Kui läbitud viiteobjekt on null, siis loob meetod erandi ja pärast seda meetodit asetatud järelejäänud koodi ei jõuta, seega võime julgelt eeldada, et viide seal puudub. Siit tulebki probleem - kuigi meil on need teadmised, ei aita see koostajal sama oletust täita. Siin tulevad kohale märkused @ Nullable ja @ NotNull, kuna need eksisteerivad ainult selleks, et aidata koostajal tingimusi mõista. See on see, mis tegelikult on - see on vihje kompilaatorile, mis aitab tal keerukamat koodianalüüsi teha. Olemasolev efekt, mida olete Kotlinis juba näinud, on teatud tüüpi nutikas casting plokis pärast selle tüübi kontrollimist:

Kotlini kompilaator on juba nutikas ja pole kahtlust, et see kasvab ka tulevikus, kuid lepingute kasutuselevõtuga andsid Kotlini arendajad meile raamatukogu arendajatena õiguse seda täiustada, kirjutades oma nutikaid rakendusi ja luues efekte, mis aitavad meie kasutajatel kirjuta puhtam kood. Kirjutame nüüd Kotlinis CheckNotNul meetodi, kasutades selleks lepingute abil oma võimeid:

Samuti on erinevaid efekte, kuid see pole lepingute täismõõdus sissejuhatus ja ma loodan, et see andis teile lihtsalt idee, kuidas sellest kasu saada. Lisaks sellele on Githubis asuvas stdlibi hoidlas hulgaliselt kasulikke lepingunäiteid, mida tasub kontrollida.

Suure jõuga kaasneb suur vastutus ja lepingud pole erand. Mida iganes te oma lepingus väidate, käsitleb selle koostaja Püha Piiblit. Tehnilisemalt öeldes ei sea ega kompilaator kahtluse alla ega kinnita kõike, mida seal kirjutate, nii et peate oma koodi hoolikalt ise kontrollima ja veenduma, et te ei tekita mingeid vastuolusid.

Nagu @ExperimentalContractsi märkusest võisite märgata, on lepingud endiselt katseetapis, nii et aja jooksul võib muutuda mitte ainult API, vaid ka mõned küpsused, mis muutuvad selle küpsemaks muutumisega.

7. Java koostalitlusvõime

Kotlini raamatukogu kirjutamise ajal on oluline ka kuulajaskonna laiemaks hoidmine, pakkudes sujuvat integreerimiskogemust Java arendajatele. See on väga oluline, kuna endiselt on palju projekte, mis kinnistuvad Java-le ja ei taha erinevatel põhjustel olemasolevat koodi ümber kirjutada. Kuna me tahame, et Kotlini kogukond kasvaks kiiremini, on parem lubada neil projektidel seda teha järk-järgult, samm-sammult. Muidugi pole see müür selle külje kohal nii päikseline, kuid on ka asju, mida saate raamatukogu pidajana selle vastu teha.

Esimene asi on see, et Kotlini laiendusfunktsioonid Java-s kompileeritakse inetuks staatilisteks meetoditeks, kus meetodi esimene argument on vastuvõtja tüüp:

Ehkki teil pole siin tegelikult palju kontrolli, saate genereeritud klassi nime vähemalt muuta, lisades paketi taseme funktsioone sisaldava lähtefaili algusesse järgmise rea:

Teine näide, kuidas genereeritud koodi pisut mõjutada, on seotud kaasobjekti meetodite kasutamisega:

Saate Kotlinit sundida genereerima staatilisi klasse kaasobjektis määratletud funktsioonide asemel, kasutades @JvmStatic annotatsiooni:

Võrreldes Kotliniga, ei saa Java-s kahte sarnase nimega, kuid erinevaid geneerilisi tüüpe funktsioone tüübi kustutamise tõttu koos määratleda, nii et see võib olla Java-kasutajate jaoks stopper. Loodetavasti saate seda vältida, muutes meetodi allkirja teise märkusega:

Ja viimane, kuid mitte vähem tähtis on võimalus määratleda Java-kasutajate funktsioonides kontrollitud erandid, ehkki need pole Kotlinis otse saadaval. See võib olla mugav, kuna Java ja Kotlini erandite deklareerimise paradigma on erinev:

Enamik siin olevatest asjadest on valikulised, kuid need võivad kindlasti olla teie Java kasutajate kogu teie raamatukogu jaoks kudode allikaks.

Alumine joon

Kotlin on suurepärane keel, mis liigub pidevalt edasi ja raamatukogu kasutamise sujuvamaks muutmiseks on raamatukogu jaoks palju teha. Kõigist, mida te ülaltoodud ideedest rakendate, proovige kõigepealt olla kasutaja ja mõelge, milline see teile oleks ja kuidas te seda kasutaksite. Kurat on üksikasjades ja loodetavasti tulevad need pisikesed asjad teie kasutajatele kasuks ja muudavad nende kogemuse paremaks. Terviseks!