Synlighedsmodifikatorer i Kotlin

1. Introduktion

Kotlin-programmeringssproget er bygget på Java Virtual Machine (JVM). Som sådan skal den følge alle de regler, som JVM pålægger - inklusive synlighedsændringer.

Der er dog nogle subtile nuancer i, hvordan sproget implementerer disse modifikatorer med hensyn til compileren og den måde, vores kode er struktureret på. Denne artikel viser nogle af lighederne og forskellene mellem Java og Kotlin i denne henseende.

2. Synlighedsmodifikatorer

Synlighedsmodifikatorer bruges til at bestemme, hvilke andre kodeelementer der har adgang til det element, der ændres. De gælder for nogle forskellige elementer i koden på forskellige niveauer. Den måde, hvorpå disse regler anvendes, kan variere lidt mellem disse forskellige anvendelser, hvilket i starten kan være forvirrende.

2.1. Offentlig synlighed

Den mest oplagte modifikator er offentlig. Dette er muligvis det hyppigst anvendte på hele sproget og betyder, at der ikke er yderligere begrænsninger for, hvem der kan se, at elementet bliver ændret.

I modsætning til Java er der næsten ingen grund til at erklære noget som offentligt i Kotlin - det er standardmodifikatoren, der bruges, hvis vi ikke erklærer en anden. Bortset fra dette fungerer det det samme i Kotlin som det gør i Java.

Hvis vi anvender offentlig modifikator til et element på øverste niveau - en ydre klasse eller en funktion eller variabel, der erklæres direkte inde i en pakke - så kan enhver anden kode få adgang til den. Hvis vi anvender offentlig modifikator til et indlejret element - en indre klasse eller en funktion eller variabel inde i en klasse - så kan enhver kode, der har adgang til containeren, også få adgang til dette element.

For eksempel:

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

Klasse Offentlig er tilgængelig overalt i hele kodebasen, “Val jeg ”og” sjovt gør noget()" er tilgængelige fra alt, hvad der kan få adgang til Offentlig.

2.2. Privat synlighed

Den anden modifikator, der bruges størstedelen af ​​tiden er privat. Dette har næsten den nøjagtige modsatte betydning af offentlig - det betyder, at ingen har adgang til det.

I virkeligheden, i Kotlin betyder det, at kun kode, der er erklæret inden for samme omfang, har adgang til den. Dette adskiller sig subtilt fra Java, simpelthen fordi Kotlin giver mulighed for flere erklæringer på øverste niveau i den samme fil - a privat element på øverste niveau kan tilgås af alt andet i den samme fil. Bortset fra at reglerne er de samme. For eksempel:

For eksempel:

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

Klasse Privat er kun tilgængelig inden for den samme kildefil, “Val jeg ”og” sjovt gør noget()" er kun tilgængelige indefra i klassen Privat.

2.3. Beskyttet synlighed

Det sroteret modifikator i Kotlin betyder, at det kun er strengt tilgængeligt af deklarerende klasse og underklasser. Dette er det samme som de fleste mennesker forventer, at Java fungerer, men subtilt anderledes end hvordan Java fungerer.

I Java er beskyttet modifikator giver også adgang til elementet fra alt andet i den samme pakke. For eksempel givet følgende klassefil:

klasse A {beskyttet val i = 1}

Følgende fil fungerer fint 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 ville hverken fungere i Java eller Kotlin:

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

Derudover i Kotlin beskyttet bliver standardsynligheden, når vi overstyrer en beskyttet element fra en superklasse. Dette kan udtrykkeligt ændres til offentlig hvis det ønskes, og det er det vigtigste tidspunkt, er vi nødt til at erklære noget eksplicit.

2.4. Pakke-privat / standardsynlighed

I Java er der en adgangsmodifikator kendt som "pakke-privat" (også kaldet "standard"). Dette bruges, når der ikke placeres nogen modifikator på elementet. Dette betyder, at enhver kode i samme pakke kan få adgang til den, men enhver kode i en anden pakke kan ikke, inklusive underklasser.

Kotlin har slet ikke nogen understøttelse af denne modifikator, selvom dette kan ændre sig i fremtiden. Begrundelsen for dette er, at den ikke giver nogen beskyttelse - nogen kunne definere kode i den samme pakke og få adgang til vores elementer, selv fra en anden jar-fil.

2.5. Intern synlighed

Kotlin tilføjer en ny modifikator til de muligheder, som Java ikke understøtter i øjeblikket - indre. Denne modifikator betyder, at enhver kode, der er erklæret i det samme modul, som ikke ellers er begrænset, kan få adgang til dette element. (Et modul er i det væsentlige en Jar-fil.)

Dette er muligt i Java ved hjælp af ting som OSGi, men det er ikke indfødt i sproget i øjeblikket. Java 9 vil bringe nogle koncepter, der gør det mere opnåeligt ved at være i stand til at eksportere offentlige identifikatorer selektivt.

Dette tilføjer en enorm fordel ved at skrive API'er og implementeringer. Vi kan skrive vores API-grænseflader som offentlig, vores vigtigste implementering som offentlig klasser og hele supportkoden, som det afhænger af som indre. At gøre dette betyder, at ekstern kode er tvunget til at gå gennem API'en og ikke kan få adgang til internt. For eksempel:

pakke com.baeldung.modifiers intern klasse Intern {} klasse Offentlig {intern værdi i = 1 intern sjov doSomething () {}}

Klasse Indre er kun tilgængelig fra det samme modul. “Val i” og “Sjov doSomething ()” er også kun tilgængelige indefra det samme modul, selvom den klasse, de er inde i, kan fås fra hvor som helst.

3. Resume

I artiklen har vi kigget på synlighedsmodifikatorer i Kotlin.

Det meste af tiden fungerer reglerne for synlighedsændringer i Kotlin det samme som vi forventede fra Java. Der er dog en stor forskel - som er introduktionen af indre omfang - hvilket er meget nyttigt for større projekter.


$config[zx-auto] not found$config[zx-overlay] not found