streamalism.org

1. Introduksjon

Kotlin-programmeringsspråket er bygget på Java Virtual Machine (JVM). Som sådan må den følge alle reglene som JVM pålegger - inkludert synlighetsendringer.

Imidlertid er det noen subtile nyanser i hvordan språket implementerer disse modifikatorene med hensyn til kompilatoren og måten koden vår er strukturert på. Denne artikkelen vil vise noen av likhetene og forskjellene mellom Java og Kotlin i denne forbindelse.

2. Siktmodifikatorer

Synlighetsmodifikatorer brukes til å bestemme hvilke andre elementer i koden som har tilgang til elementet som endres. De gjelder for noen forskjellige elementer i koden, på forskjellige nivåer av omfang. Måten disse reglene brukes på kan variere litt mellom disse forskjellige bruksområdene, noe som kan være forvirrende i begynnelsen.

2.1. Offentlig synlighet

Den mest åpenbare modifikatoren er offentlig. Dette er muligens det mest brukte på hele språket, og betyr at det ikke er noen ytterligere begrensninger for hvem som kan se elementet blir endret.

I motsetning til Java er det nesten aldri behov for å erklære noe som offentlig i Kotlin - det er standard modifikator som brukes hvis vi ikke erklærer en annen. Annet enn dette fungerer det det samme i Kotlin som det gjør i Java.

Hvis vi bruker offentlig modifikator til et toppnivåelement - en ytre klasse eller en funksjon eller variabel deklarert direkte i en pakke - så kan enhver annen kode få tilgang til den. Hvis vi bruker offentlig modifiser til et nestet element - en indre klasse, eller en funksjon eller variabel i en klasse - så kan enhver kode som har tilgang til beholderen også få tilgang til dette elementet.

For eksempel:

klasse Offentlig {val i = 1 morsom doSomething () {}} 

Klasse Offentlig er tilgjengelig fra hvor som helst i hele kodebasen, “Val jeg ”og” moro gjør noe()" er tilgjengelig fra alt som har tilgang Offentlig.

2.2. Privat synlighet

Den andre modifisereren som brukes mesteparten av tiden er privat. Dette har nesten den motsatte betydningen av offentlig - det betyr at ingen har tilgang til det.

I virkeligheten, i Kotlin betyr det at bare kode deklarert innenfor samme omfang kan få tilgang til den. Dette er subtilt forskjellig fra Java bare fordi Kotlin gir mulighet for flere toppnivåerklæringer i samme fil - a privat element på øverste nivå kan nås av alt annet i samme fil. Annet enn at reglene er de samme. For eksempel:

For eksempel:

privat klasse Privat {privat verdi i = 1 privat verdi doSomething () {}}

Klasse Privat er bare tilgjengelig fra samme kildefil, “Val jeg ”og” moro gjør noe()" er bare tilgjengelig fra innsiden av klassen Privat.

2.3. Beskyttet synlighet

De srotert modifier i Kotlin betyr at den kun er tilgjengelig kun av deklarerende klassen og underklassene. Dette er det samme som folk flest forventer at Java skal fungere, men subtilt forskjellig fra hvordan Java fungerer.

I Java er beskyttet modifier gir også tilgang til elementet fra alt annet i samme pakke. For eksempel gitt følgende klassefil:

klasse A {beskyttet val i = 1}

Følgende fil vil fungere bra i Kotlin:

klasse B: A () {fun getValue (): Int {return i}}

Følgende fil fungerer i Java, men fungerer ikke i Kotlin:

klasse C {fun getValue (): Int {val a = A () returner a.i}}

Og følgende fungerer ikke i verken Java eller Kotlin:

klasse D {fun getValue (): Int {val a = A () returner a.i}}

I tillegg i Kotlin beskyttet blir standard synlighet når vi overstyrer en beskyttet element fra en superklasse. Dette kan eksplisitt endres til offentlig hvis ønskelig og er det viktigste tidspunktet, må vi erklære noe som offentlig.

2.4. Pakke-privat / standard synlighet

I Java er det en tilgangsmodifikator kjent som "pakke-privat" (også referert til som "standard"). Dette brukes når ingen modifikatorer er plassert på elementet. Dette betyr at en hvilken som helst kode i samme pakke kan få tilgang til den, men hvilken som helst kode i en annen pakke kan ikke, inkludert underklasser.

Kotlin har foreløpig ikke støtte for denne modifisereren i det hele tatt, selv om dette kan endre seg i fremtiden. Begrunnelsen for dette er at den ikke gir noen beskyttelse - noen kan definere kode i samme pakke og få tilgang til elementene våre, selv fra en annen jar-fil.

2.5. Intern synlighet

Kotlin legger til en ny modifikator til alternativene som Java for øyeblikket ikke støtter - innvendig. Denne modifisereren betyr at en hvilken som helst kode som er erklært i den samme modulen som ellers ikke er begrenset, kan få tilgang til dette elementet. (En modul er egentlig en Jar-fil.)

Dette er mulig i Java ved å bruke ting som OSGi, men det er ikke innfødt i språket for øyeblikket. Java 9 vil bringe noen konsepter som gjør det mer oppnåelig ved å kunne eksportere offentlige identifikatorer selektivt.

Dette gir en stor fordel for å skrive APIer og implementeringer. Vi kan skrive API-grensesnittene våre som offentlig, vår viktigste implementering som offentlig klasser og all støttekoden som det avhenger av som innvendig. Å gjøre dette betyr at ekstern kode blir tvunget til å gå gjennom API og ikke kan få tilgang til internt. For eksempel:

pakke com.baeldung.modifiers intern klasse Intern {} klasse Offentlig {intern verdi i = 1 intern moro doSomething () {}}

Klasse Innvendig er bare tilgjengelig fra innsiden av samme modul. “Val i” og “Fun doSomething ()” er også bare tilgjengelig fra innsiden av den samme modulen, selv om klassen de er i kan nås hvor som helst.

3. Oppsummering

I artikkelen så vi på synlighetsendringer i Kotlin.

Mesteparten av tiden fungerer reglene for synlighetsendring i Kotlin det samme som vi forventer fra Java. Imidlertid er det en stor forskjell - som er introduksjonen av innvendig omfang - som er veldig nyttig for større prosjekter.