Модификатори на видимостта в Kotlin

1. Въведение

Езикът за програмиране Kotlin е изграден върху Java Virtual Machine (JVM). Като такъв той трябва да следва всички правила, които JVM налага - включително модификатори на видимостта.

Има обаче някои фини нюанси в това как езикът прилага тези модификатори по отношение на компилатора и начина, по който е структуриран нашият код. Тази статия ще покаже някои прилики и разлики между Java и Kotlin в това отношение.

2. Модификатори на видимостта

Модификаторите на видимост се използват за определяне на това кои други елементи на кода имат достъп до модифицирания елемент. Те се прилагат за някои различни елементи в кода, на различни нива на обхват. Начинът, по който се прилагат тези правила, може да се различава леко при различните употреби, което в началото може да обърка.

2.1. Публична видимост

Най-очевидният модификатор е публичен . Това е може би най-често използваното в целия език и означава, че няма допълнителни ограничения за това кой може да види модифицирания елемент.

За разлика от Java, в Kotlin почти никога няма нужда да обявяваме нещо като обществено - това е модификаторът по подразбиране, който се използва, ако не декларираме друг. Освен това, той работи по същия начин в Kotlin, както и в Java.

Ако приложим публичния модификатор към елемент от най-високо ниво - външен клас или функция или променлива, декларирани директно вътре в пакет - тогава всеки друг код може да получи достъп до него. Ако приложим публичния модификатор към вложен елемент - вътрешен клас или функция или променлива в клас - тогава всеки код, който има достъп до контейнера, също може да получи достъп до този елемент.

Например:

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

Class Public е достъпен от всяко място в цялата кодова база, „val i“ и „fun doSomething ()“ са достъпни от всичко, което има достъп до Public.

2.2. Частна видимост

Другият модификатор, който се използва през повечето време, е частен . Това има почти точно обратното значение на публичното - това означава, че никой няма достъп до него.

В действителност в Kotlin това означава, че само код, деклариран в същия обхват, може да има достъп до него . Това е съвсем различно от Java, просто защото Kotlin позволява множество декларации от най-високо ниво в един и същ файл - частен елемент от най-високо ниво може да бъде достъпен от всичко останало в същия файл. Освен това правилата са едни и същи. Например:

Например:

private class Private { private val i = 1 private val doSomething() { } }

Класът Private е достъпен само от един и същ изходен файл, „val i“ и „fun doSomething ()“ са достъпни само от клас Private .

2.3. Защитена видимост

На стр rotected модификатор в Kotlin означава, че е строго достъпен само от обявяване класа и подкласа . Това е същото, както повечето хора очакват Java да работи, но съвсем различно от това как работи Java.

В Java защитеният модификатор също позволява достъп до елемента от всичко друго в същия пакет. Например, като се има предвид следния файл на класа:

class A { protected val i = 1 }

Следният файл ще работи добре в Kotlin:

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

Следният файл ще работи в Java, но няма да работи в Kotlin:

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

И следното няма да работи нито в Java, нито в Kotlin:

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

Освен това в Kotlin protected става видимостта по подразбиране, когато заместваме защитен елемент от суперклас . Това може да бъде изрично променено на обществено, ако желаете и е основният момент, в който ще трябва да обявим нещо като публично изрично.

2.4. Пакетно-частна / видимост по подразбиране

В Java има модификатор на достъп, известен като „пакетно-частен“ (наричан още „по подразбиране“). Това се използва, когато върху елемента не е поставен модификатор. Това означава, че всеки код в същия пакет може да има достъп до него, но всеки код в различен пакет не може, включително подкласове.

Понастоящем Kotlin изобщо няма поддръжка за този модификатор , въпреки че това може да се промени в бъдеще. Причината за това е, че тя не предлага никаква защита - всеки би могъл да дефинира код в същия пакет и да има достъп до нашите елементи, дори от различен Jar файл.

2.5. Вътрешна видимост

Kotlin добавя нов модификатор към опциите, които Java в момента не поддържа - вътрешен . Този модификатор означава, че всеки код, деклариран в същия модул, който по друг начин не е ограничен, може да има достъп до този елемент . (Модулът е по същество Jar файл.)

Това е възможно в Java, използвайки неща като OSGi, но понастоящем не е роден на езика. Java 9 ще внесе някои концепции, които го правят по-постижим, като могат да изнасят избирателно публични идентификатори.

Това добавя огромна полза за писане на API и внедряване. Можем да напишем нашите API интерфейси като публични , основната ни реализация като публични класове и целия код за поддръжка, от който зависи, като вътрешен . Това означава, че външният код е принуден да премине през API и не може да получи достъп до вътрешни елементи. Например:

package com.baeldung.modifiers internal class Internal { } class Public { internal val i = 1 internal fun doSomething() { } }

Class Internal е достъпен само от същия модул. “Val i” и “fun doSomething ()” също са достъпни само от същия модул, въпреки че класът, в който се намират, може да бъде достъпен отвсякъде.

3. Обобщение

В статията разгледахме модификаторите на видимост в Kotlin.

През повечето време правилата за модификация на видимостта в Kotlin работят по същия начин, както очакваме от Java. Съществува обаче голяма разлика - която е въвеждането на вътрешния обхват - която е много полезна за по-големи проекти.