streamalism.org

1. Introduktion

Administrerede sprog, såsom dem, der er målrettet mod JVM, håndterer automatisk den mest almindelige ressource: hukommelse.

Vi har dog brug for alle slags ressourcer, ikke kun hukommelse: filer, netværksforbindelser, streams, windows osv. Og ligesom hukommelse, skal disse frigives, når de ikke længere er nødvendige.

I denne artikel skal vi se på, hvordan ressourcer kan styres automatisk i Kotlin, og hvordan det adskiller sig fra Java's prøve-med-ressourcekonstruktion.

Hvis du vil springe over teorien, skal du springe direkte til eksemplet.

2. Automatisk ressourcestyring

Vi kan skelne mellem tre forskellige faser, når vi arbejder med ressourcer i Java (pseudokode):

resource = erhverveResource () prøv {useResource (ressource)} endelig {releaseResource (ressource)} 

Hvis sprog eller bibliotek er ansvarlig for frigivelse af ressourcen ( langt om længe del), så kalder vi det Automatisk ressourcestyring. En sådan funktion frigør os fra at skulle huske at frigøre en ressource.

Da ressourcehåndtering normalt er bundet til et blokomfang, frigives de altid i den rigtige rækkefølge, hvis vi beskæftiger os med mere end én ressource på samme tid.

I Java implementerer objekter, der indeholder en ressource og er kvalificerede til automatisk ressourcestyring, en bestemt grænseflade: Kan lukkes for I / O-relaterede ressourcer og Kan lukkes automatisk.

Også Java 7 eftermonterede det allerede eksisterende Kan lukkes interface, der skal udvides Kan lukkes automatisk.

Derfor har Kotlin det samme koncept med ressourceholdere: det vil sige objekter, der implementerer enten Kan lukkes eller Kan lukkes automatisk.

3. Den brug Funktion i Kotlin

For automatisk at administrere ressourcer har nogle sprog en dedikeret konstruktion: Java 7 introducerede f.eks. Prøve-ressourcer, mens C # har ved brug af nøgleord.

Nogle gange tilbyder de os et mønster, som RAII i C ++. I nogle andre tilfælde giver de os en biblioteksmetode.

Kotlin falder ind under sidstnævnte kategori.

Efter design er det har ikke en sprogkonstruktion, der ligner prøv med ressourcer i Java.

I stedet kan vi finde en udvidelsesmetode kaldet brug i dets standardbibliotek.

Vi ser nærmere på det senere. For nu er vi bare nødt til at vide, at ethvert objekt til ressourceindehaveren har brug metode, som vi kan påberåbe os.

3.1. Sådan bruges det

Et simpelt eksempel:

valwriter = FileWriter ("test.txt") writer.use {writer.write ("noget")}

Vi kan påberåbe os brug funktion på ethvert objekt, der implementeres Kan lukkes automatisk eller Kan lukkes, ligesom med prøve-ressourcer i Java.

Metoden tager et lambda-udtryk, udfører det og bortskaffer ressourcen (ved at kalde tæt() på det) når udførelse forlader blokken, enten normalt eller med en undtagelse.

Så i dette tilfælde efter brug, det forfatter kan ikke længere bruges, fordi Kotlin automatisk har lukket det.

3.2. En kortere form

I eksemplet ovenfor brugte vi for klarhedens skyld en variabel kaldet forfatterog dermed skabe en lukning.

Imidlertid, brug accepterer et lambda-udtryk med en enkelt parameter – objektet, der indeholder ressourcen:

FileWriter ("test.txt"). Brug {w -> w.write ("noget")}

Inde i blokken kan vi også bruge den implicitte variabel det:

FileWriter ("test.txt"). Brug {it.write ("noget")}

Så som vi kan se, behøver vi ikke give objektet et eksplicit navn. Det er dog normalt en god ide at være klar i stedet for at skrive for kortfattet kode.

3.3. Definitionen af brug()

Lad os se på definitionen af brug funktion i Kotlin, som den findes i dets standardbibliotek:

offentlig inline sjov T. brug (blok: (T) -> R): R.

Vi kan se, i del, det brug er defineret som en udvidelsesfunktion på Java'er Kan lukkes interface.

Mere om udvidelsesmetoder kan findes i vores indledende artikel.

Selvfølgelig er det brug funktion er dokumenteret som en del af Kotlins standardbibliotek.

3.4. Kan lukkes vs. Kan lukkes automatisk

Hvis vi følger eksemplet fra forrige afsnit nærmere, kan vi se, at brug funktionssignatur er kun defineret på Kan lukkes interface. Dette skyldes, at Kotlins standardbibliotek er målrettet mod Java 6.

I Java-versioner før 7, Kan lukkes automatisk eksisterede ikke, og selvfølgelig Kan lukkes forlængede det ikke.

I praksis klasser, der implementeres Kan lukkes automatisk men ikke Kan lukkes er sjældne. Alligevel kan vi støde på en af ​​dem.

I så fald skal vi kun tilføje en afhængighed af Kotlins udvidelser til Java 7, 8 eller den version, vi målretter mod:

 org.jetbrains.kotlin kotlin-stdlib-jdk8 

Den seneste version af afhængigheden kan findes på Maven Central.

Det giver os en anden brug udvidelsesfunktion defineret på Kan lukkes automatisk grænseflade:

offentlig inline sjov T. brug (blok: (T) -> R): R.

4. Konklusion

I denne vejledning har vi set, hvordan en simpel udvidelsesfunktion i Kotlins standardbibliotek er alt, hvad vi har brug for til automatisk at administrere alle slags ressourcer, som JVM kender.

Implementeringen af ​​alle disse eksempler og kodestykker findes i GitHub-projektet.