Zichtbaarheidsmodificatoren in Kotlin

1. Inleiding

De programmeertaal Kotlin is gebouwd op de Java Virtual Machine (JVM). Als zodanig moet het alle regels volgen die de JVM oplegt, inclusief zichtbaarheidsmodificatoren.

Er zijn echter enkele subtiele nuances in hoe de taal deze modificatoren implementeert met betrekking tot de compiler en de manier waarop onze code is gestructureerd. Dit artikel zal in dit opzicht enkele overeenkomsten en verschillen tussen Java en Kotlin laten zien.

2. Visibility Modifiers

Visibiliteitsmodificatoren worden gebruikt om te bepalen welke andere elementen van de code toegang hebben tot het element dat wordt gewijzigd. Ze zijn van toepassing op een aantal verschillende elementen in de code, op verschillende niveaus. De manier waarop deze regels worden toegepast, kan enigszins variëren tussen deze verschillende toepassingen, wat in het begin verwarrend kan zijn.

2.1. Publieke zichtbaarheid

De meest voor de hand liggende modifier is openbaar. Dit is mogelijk het meest gebruikte element in de hele taal en betekent dat er geen aanvullende beperkingen zijn voor wie het element kan zien dat wordt gewijzigd.

In tegenstelling tot Java is het in Kotlin bijna nooit nodig om iets als openbaar aan te geven - het is de standaard modifier die wordt gebruikt als we geen andere declareren. Verder werkt het in Kotlin hetzelfde als in Java.

Als we het openbaar modifier naar een element op het hoogste niveau - een buitenste klasse of een functie of variabele die direct in een pakket wordt gedeclareerd - dan kan elke andere code er toegang toe krijgen. Als we het openbaar modifier voor een genest element - een innerlijke klasse, of een functie of variabele binnen een klasse - dan heeft elke code die toegang heeft tot de container ook toegang tot dit element.

Bijvoorbeeld:

class Public {val i = 1 leuke doSomething () {}} 

Klasse Openbaar is overal in de hele codebase toegankelijk, “Val i 'en' fun doe iets()" zijn toegankelijk vanaf alles dat toegang heeft Openbaar.

2.2. Privézichtbaarheid

De andere modifier die het grootste deel van de tijd wordt gebruikt, is privaat. Dit heeft bijna precies de tegenovergestelde betekenis van openbaar - het betekent dat niemand er toegang toe heeft.

In werkelijkheid, in Kotlin betekent dit dat alleen code die binnen hetzelfde bereik is gedeclareerd, er toegang toe heeft. Dit verschilt subtiel van Java, simpelweg omdat Kotlin meerdere declaraties op het hoogste niveau in hetzelfde bestand toestaat - een privaat element op het hoogste niveau is toegankelijk voor al het andere in hetzelfde bestand. Verder zijn de regels hetzelfde. Bijvoorbeeld:

Bijvoorbeeld:

privéles Privé {privéval i = 1 privéval doSomething () {}}

Klasse Privaat is alleen toegankelijk vanuit hetzelfde bronbestand, “Val i 'en' fun doe iets()" zijn alleen toegankelijk vanuit de klas Privaat.

2.3. Beschermde zichtbaarheid

De protected modifier in Kotlin betekent dat het alleen strikt toegankelijk is voor de declarerende klasse en subklassen. Dit is hetzelfde zoals de meeste mensen verwachten dat Java werkt, maar op een subtiele manier anders dan hoe Java werkt.

In Java is het beschermd modifier geeft ook toegang tot het element vanuit iets anders in hetzelfde pakket. Gegeven bijvoorbeeld het volgende klassenbestand:

klasse A {beschermde waarde i = 1}

Het volgende bestand zou prima werken in Kotlin:

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

Het volgende bestand zou in Java werken, maar niet in Kotlin:

class C {fun getValue (): Int {val a = A () return a.i}}

En het volgende zou niet werken in Java of Kotlin:

class D {fun getValue (): Int {val a = A () return a.i}}

Bovendien, in Kotlin beschermd wordt de standaardzichtbaarheid wanneer we overschrijven een beschermd element uit een superklasse. Dit kan expliciet worden gewijzigd in openbaar indien gewenst en het is de belangrijkste tijd die we nodig hebben om iets expliciet als openbaar te verklaren.

2.4. Pakket-privé / standaard zichtbaarheid

In Java is er een toegangsmodificator die bekend staat als "pakket-privé" (ook wel "standaard" genoemd). Dit wordt gebruikt als er geen modifier op het element is geplaatst. Dit betekent dat elke code in hetzelfde pakket er toegang toe heeft, maar elke code in een ander pakket niet, inclusief subklassen.

Kotlin heeft momenteel helemaal geen ondersteuning voor deze modifier, hoewel dit in de toekomst kan veranderen. De reden hiervoor is dat het geen bescherming biedt - iedereen kan code in hetzelfde pakket definiëren en toegang krijgen tot onze elementen, zelfs vanuit een ander jar-bestand.

2.5. Interne zichtbaarheid

Kotlin voegt een nieuwe modifier toe aan de opties die Java momenteel niet ondersteunt - intern. Deze modifier betekent dat elke code die in dezelfde module is gedeclareerd en die niet anderszins beperkt is, toegang heeft tot dit element. (Een module is in wezen een Jar-bestand.)

Dit is mogelijk in Java met behulp van zaken als OSGi, maar het is momenteel niet inheems in de taal. Java 9 zal enkele concepten brengen die het beter haalbaar maken door de mogelijkheid om openbare identificatiegegevens selectief te exporteren.

Dit voegt een enorm voordeel toe voor het schrijven van API's en implementaties. We kunnen onze API-interfaces schrijven als openbaar, onze belangrijkste implementatie als openbaar klassen en alle ondersteuningscode waarvan het afhankelijk is als intern. Dit betekent dat externe code gedwongen wordt om door de API te gaan en geen toegang kan krijgen tot internals. Bijvoorbeeld:

pakket com.baeldung.modifiers interne klasse Interne {} klasse Openbaar {interne waarde i = 1 intern plezier doSomething () {}}

Klasse Intern is alleen toegankelijk vanuit dezelfde module. "Val ik" en "Fun doSomething ()" zijn ook alleen toegankelijk vanuit dezelfde module, ook al is de klasse waarin ze zich bevinden overal toegankelijk.

3. Samenvatting

In het artikel hebben we de zichtbaarheidsmodificatoren in Kotlin bekeken.

Meestal werken de zichtbaarheidsmodificatieregels in Kotlin hetzelfde als we van Java zouden verwachten. Er is echter een groot verschil: de introductie van de intern scope - wat erg handig is voor grotere projecten.


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