7 vinkkiä Kotlin-kirjaston loistamiseksi

Esipuhe

Kun aloitamme ohjelmoinnin uudella kielellä, pysymme aluksi usein paradigmojen ja tapojen kanssa, jotka ovat kehittyneet ohjelmoidessamme jo tunnetulla kielellä. Vaikka se saattaa vaikuttaa alulta hyvältä, ihmisille, jotka ohjelmoivat kielellä, jota yrität hallita jonkin aikaa, tämä epätasaisuus on melko ilmeinen.

Kun olin juuri siirtynyt Java: sta Kotliniin noin 2 vuotta sitten, tein pohjimmiltaan ”Java-ohjelmointia, mutta Kotlinissa”. Vaikka Kotlin oli minulle kuin raikasta ilmaa, käytin Android-insinöörinä kaikkia noita, rakeita laajennustoimintoja ja tietoluokkia, eikä se ollut aina johdonmukaista. Muunnoin olemassa olevan Java-koodin Kotliniksi ja tarkastelemalla sitä jonkin ajan kuluttua autin pitämään mielessäni muutamia ideoita, kun suunnittelin sovellusliittymiä erilaisille uudelleenkäytettäville komponenteille tai kirjastoille Kotlinissa.

Täällä, BUX, työskentelemme kahdella sovelluksella, joilla on pari jaettua kirjastoa. Vaikka Stocks-sovellus (jota ei vielä julkaistu) kirjoitettiin Kotlinissa alusta alkaen, ensimmäinen CFD-sovellus kirjoitettiin Java-ohjelmassa ja muutettiin sitten jonkin ajan kuluttua Kotliniksi. Tällä hetkellä CFD-sovellus on 78,7% Kotlin, mikä tarkoittaa, että työskentelemme edelleen sen suhteen, ja siksi on tärkeää kiinnittää huomiota kirjasto-sovellusliittymiin, joita ylläpitää kaksi joukkuetta, jotka käyttävät sekä Javaa että Kotlinia samanaikaisesti.

Joten jos sinulla on jo olemassa Kotlin- tai Java-kirjasto, jonka haluat Kotlinifioida, tai suunnittelet sovellusliittymää Kotlinlin avulla tyhjästä, ota kanssani ideoita siitä, mitä voit tehdä kirjastoosi käyttäjien elämän helpottamiseksi.

1. Laajennustoiminnot

Suurimman osan ajasta, kun joudut laajentamaan olemassa olevaa luokkaa uudella toiminnallisuudella, käytät joko jonkinlaista koostumusta tai johdatat uuden luokan (mikä laajamittaisella käytöllä voi tehdä luokkahierarkianne yhtä herkkä kuin IKEA: n lasikupit). Riippumatta siitä, mikä on mieluisin, Kotlinilla on oma vastaus tähän, nimeltään laajennustoiminnot. Lyhyesti sanottuna, se antaa sinun lisätä uuden funktion olemassa olevaan luokkaan melko siistillä syntaksilla. Esimerkiksi Androidissa voit määritellä uuden menetelmän View-luokalle seuraavalla tavalla:

Kun tämä pidetään mielessä, monet kirjastot, jotka tarjoavat lisätoimintoja olemassa oleville luokille (esim. View, Context jne.) Koristeiden, staattisten tehdasmenetelmien tai jonkin muun käytön sijasta, voivat hyötyä siitä, että niiden toiminnot tarjotaan laajennustoimintoina saumattomasti, ikään kuin tämä toiminnallisuus olisi olemassa alkuperäisissä luokissa alusta alkaen.

2. Oletusarvon arvot

Kotlin suunniteltiin alun perin olemaan tiivis, siisti ja siisti Java-versio ja osoittautuu, että se tekee tämän erittäin hyvin oletusfunktioargumenttiarvoilla. Sovellusliittymän tarjoaja pystyy määrittämään oletusarvot argumentteille, jotka voidaan jättää pois. Olisin todella yllättynyt, jos et ole nähnyt samanlaista koodia työskennellessäsi SQLiten kanssa Androidissa:

Vaikka tässä menetelmässä on enemmän puutteita kuin lopussa olevissa rumaissa nolloissa, en ole täällä tuomitsemassa, vaan sanoisin pikemminkin, että nämä ajat ovat poissa, ja kyseenalaistaisin vakavasti tällä tavalla Kotliniin kirjoitetun koodin. Tällaisia ​​esimerkkejä on monia, mutta onneksi voimme tehdä paremmin nyt ja jos toimitat ulkoisen sovellusliittymän, jolla on tietyt viritysparametrit, Builderin sijaan tai sen lisäksi, että harkitset oletusargumenttiarvojen käyttöä. Tällä on ainakin kaksi etua: ensinnäkin, et pakota käyttäjää määrittelemään valinnaisia ​​parametreja tai mitä tahansa, mitä voit ennakoida etukäteen, ja toiseksi, että käyttäjällä on oletuskokoonpano, joka toimii vain ulkopuolella. -laatikko:

Tässä yhteydessä on hyvä mainita myös se, että jos asetat argumentit oletusarvoihin loppuun, käyttäjän ei tarvitse määrittää nimiä pakollisille parametreille.

3. Esineet

Oletko koskaan joutunut ottamaan Singleton-mallin käyttöön Javassa itse? Sinulla todennäköisesti oli ja jos on, sinun pitäisi tietää, kuinka hankala se voi olla joskus:

On olemassa erilaisia ​​toteutuksia, jokaisella on omat edut ja haitat. Kotlin käsittelee kaikki nämä 50 Singleton-kuvion toteutuksen sävyä yhdellä rakenteella, jota kutsutaan objektien ilmoitukseksi. Katso, ei "kaksinkertaisen tarkastuksen lukitusta":

Hienoa siinä, syntaksin lisäksi, on se, että esineilmoituksen alustus on sekä säievarma että alustettu laiskasti, kun sitä käytetään ensimmäistä kertaa:

Tällaisille kirjastoille, kuten Fabric, Glide, Picasso tai muille, jotka käyttävät yhtä yksittäistä esinettä yleisen kirjasto-sovellusliittymän pääsisäänmenopisteenä, se on luonnollinen tapa siirtyä nyt, eikä vanhan Java-tavan käyttämiseen ole syytä. tehdä samoja asioita.

4. Lähde-tiedostot

Samoin Kotlin ajattelee monia syntaktisia haasteita, joita kohtaamme päivittäin. Se ajattelee myös tapaa, jolla järjestämme luomamme koodi. Kotlin-lähdetiedostot toimivat kotona monille ilmoituksille, jotka ovat semanttisesti lähellä toisiaan. Näyttää siltä, ​​että ne ovat täydellinen paikka määritellä joitain samaan luokkaan liittyviä laajennustoimintoja. Katso tämä yksinkertaistettu katkelma Kotlinin lähdekoodista, jossa kaikki tekstin käsittelemiseen käytetyt laajennustoiminnot sijaitsevat samassa tiedostossa “Strings.kt”:

Toinen sopiva esimerkki sen käytöstä on määritellä yhteyspöytäkirja sovellusliittymäsi kanssa yhdessä tietoluokkien ja rajapintojen kanssa yhdessä lähdetiedostossa. Sen avulla käyttäjä ei voi kadottaa keskittymääsi vaihtamalla eri tiedostoja toistensa seuraten:

Älä kuitenkaan mene liian pitkälle sen kanssa, koska voit hukuttaa käyttäjän tiedoston kokoa ja muuttaa siitä RecyclerView-luokan, jossa on ~ 13.000 riviä .

5. Ohut

Jos kirjasto käyttää useita säikeitä verkkoon pääsyyn tai muun pitkäaikaisen työn suorittamiseen, harkitse API: n tarjoamista keskeytystoiminnoilla. Kotlin 1.3: stä alkaen korutiinit eivät ole enää kokeellisia, mikä on loistava tilaisuus aloittaa niiden käyttäminen tuotannossa, jos olet aiemmin ollut epävarma. Potilaat voivat joissain tapauksissa olla hyvä vaihtoehto RxJavan havainnoitavalle ja muille tavoille asynkronisten puheluiden käsittelemiseksi. Mitä olet jo nähnyt aiemmin, on sovellusliittymä, joka on täynnä menetelmiä, joissa on tuloksen takaisinsoittoja, tai Rx hype -hetkellä, joka on kääritty yhdellä tai täydellisellä:

Mutta olemme nyt Kotlinin aikakaudella, joten se voitaisiin suunnitella myös ihmisen käytön hyväksi:

Huolimatta siitä, että korutiinit toimivat paremmin kuin vanhat hyvät Java-ketjut, ovat kevyempiä, ne edistävät merkittävästi koodin luettavuutta:

6. Sopimukset

Vakaan vakiomuodon lisäksi Kotlin 1.3 tarjoaa kehittäjille tavan olla vuorovaikutuksessa kääntäjän kanssa. Sopimus on uusi ominaisuus, jonka avulla me kirjaston kehittäjinä voimme jakaa kääntäjän kanssa tietämyksemme määrittelemällä ns. Vaikutukset. Tuodaan lähin analogia Javasta, jotta sen ymmärtäminen olisi helpompaa. Suurin osa teistä on todennäköisesti nähnyt tai jopa käyttänyt Guadan ennakkoluokk luokkaa, jossa on paljon väitteitä ja sen mukauttamista kirjastoissa, kuten Dagger, jotka eivät halua hakea kokonaista kirjastoa kokonaan:

Jos ohitettu viiteobjekti on nolla, menetelmä heittää poikkeuksen ja jäljelle jäävä koodi, joka asetetaan tämän menetelmän jälkeen, ei saavuteta, joten voimme turvallisesti olettaa, että viite ei ole nolla siellä. Tässä on ongelma - vaikka meillä on tämä tieto, se ei auta kääntäjää tekemään samaa olettamusta. Täältä kohtaavat @ Nullable- ja @ NotNull -merkinnät, koska ne ovat olemassa vain auttaakseen kääntäjää ymmärtämään ehtoja. Tämä on mitä vaikutus todella on - se on vihje kääntäjälle, joka auttaa sitä suorittamaan kehittyneemmän koodianalyysin. Olemassa oleva efekti, jonka olet jo nähnyt Kotlinissa, on tietyn tyyppinen smart-casting lohkossa sen tyypin tarkistamisen jälkeen:

Kotlin-kääntäjä on jo älykäs ja ei ole epäilystäkään siitä, että se paranee jatkossakin, mutta sopimuksien käyttöönoton myötä Kotlin-kehittäjät antoivat meille kirjaston kehittäjinä voiman parantaa sitä kirjoittamalla omia älykkäitä laskujaan ja luomalla tehosteita, jotka auttavat käyttäjiämme kirjoita puhtaampi koodi. Kirjoita nyt checkNotNul-menetelmä Kotliniin käyttämällä sopimuksia osoittaakseen heidän kykynsä:

Myös vaikutuksia on erilaisia, mutta tämä ei ole täysimittainen johdanto sopimuksiin, ja toivon, että se antoi vain kuvan siitä, miten voit hyötyä siitä. Lisäksi Githubin stdlib-arkistossa on paljon hyödyllisiä sopimusesimerkkejä, jotka ovat tarkistamisen arvoisia.

Suurella voimalla tulee suuri vastuu, ja sopimukset eivät ole poikkeus. Mitä tahansa ilmoitat sopimuksessasi, kirjoittaja käsittelee Pyhänä Raamatuna. Teknisemmin kääntäjä ei kyseenalaista tai validoi kaikkea sinne kirjoittamaasi, joten sinun on tarkistettava huolellisesti koodi itse ja varmistettava, että et aiheuta epäjohdonmukaisuuksia.

Kuten olet ehkä huomannut @ExperimentalContracts -merkinnästä, sopimukset ovat edelleen kokeellisessa vaiheessa, joten sovellusliittymä ei voi muuttua ajan myötä, mutta myös joitain uusia ominaisuuksia voi johtaa siitä, kun se kypsyy.

7. Java-yhteentoimivuus

Kotlinliin kirjaston kirjoittamisen kannalta on myös tärkeää pitää yleisö laajemmin tarjoamalla sujuva integrointikokemus Java-käyttäjille. Se on erittäin tärkeä, koska edelleen on paljon projekteja, jotka kiinnittyvät Java-ohjelmiin ja jotka eivät halua kirjoittaa olemassa olevaa koodia useista syistä. Koska haluamme, että Kotlin-yhteisö kasvaa nopeammin, on parempi antaa näiden projektien tehdä se asteittain, askel askeleelta. Tietenkin, se ei ole niin aurinkoinen tällä Wall-puolella, mutta on joitain asioita, jotka voit kirjaston ylläpitäjänä tehdä sen suhteen.

Ensimmäinen asia on, että Java-Kotlin-laajennustoiminnot kootaan rumaiksi staattisiksi menetelmiksi, joissa menetelmän ensimmäinen argumentti on vastaanottotyyppi:

Vaikka sinulla ei todellakaan ole täällä paljon hallintaa, voit ainakin muuttaa generoidun luokan nimen lisäämällä seuraava rivi lähdetiedoston alkuun, joka sisältää yllä olevat paketitason toiminnot:

Toinen esimerkki siitä, miten generoituun koodiin voidaan vaikuttaa hieman, liittyy seura-esinemenetelmien käyttöön:

Voit pakottaa Kotlinin tuottamaan staattisia luokkia seuraamassa objektissa määritettyjen toimintojen sijasta @JvmStatic-merkinnällä:

Verrattuna Kotliniin Java-järjestelmässä kahta toimintoa, joilla on samanlaiset nimet, mutta erilaisia ​​geneerisiä tyyppejä ei voida määritellä yhdessä tyypin poiston takia, joten se voi olla Java-käyttäjille tarkoitettu esitys. Toivottavasti voit välttää sen muuttamalla menetelmän allekirjoitusta toisella merkinnällä:

Viimeisenä, mutta ei vähäisimpänä, on kyky määritellä tarkistettuja poikkeuksia Java-käyttäjien toiminnoissa, vaikka niitä ei ole suoraan saatavana Kotlinissa. Tämä voi olla hyödyllistä, koska Java- ja Kotlin-poikkeusten ilmoittamismalli on erilainen:

Suurin osa täällä olevista asioista on valinnaisia, mutta ne saattavat olla Java-käyttäjien varmasti lähtevä kirjastoosi.

Alarivi

Kotlin on hieno kieli, joka liikkuu jatkuvasti eteenpäin, ja voit tehdä kirjastosta paljon asioita, jotta sen käyttö sujuisi. Yritä olla kaikkien käyttäjien joukossa yllä olevista ideoista, ennen kaikkea olla käyttäjä ja miettiä, minkä haluaisit sen olevan ja miten sitä käyttäisit. Paholainen on yksityiskohdissa, ja toivottavasti nämä pienet asiat, joista olet asettaneet, hyödyttävät käyttäjiä ja parantavat heidän kokemustaan. Kippis!