В чем разница между protected в Java и protected в Kotlin?

Разница между protected в Java и Kotlin

Основное отличие заключается в расширении области видимости модификатора protected в Kotlin по сравнению с Java. Это изменение было сознательно внесено разработчиками Kotlin для устранения одного из ключевых ограничений Java.

Protected в Java

В Java protected члены класса видны в:

1. Текущем классе
2. Всех классах того же пакета (package-private доступ)
3. Наследниках класса, даже если они находятся в других пакетах

// Java пример
package com.example.base;

public class Parent {
    protected String protectedField = "protected";
    
    protected void protectedMethod() {
        System.out.println("Protected method");
    }
}

// Другой пакет
package com.example.other;

import com.example.base.Parent;

public class Child extends Parent {
    void accessExample() {
        // Доступ разрешен - наследник
        System.out.println(protectedField);
        protectedMethod();
    }
}

public class Unrelated {
    void tryAccess() {
        Parent parent = new Parent();
        // ОШИБКА КОМПИЛЯЦИИ: недоступно в другом пакете
        // parent.protectedField;
        // parent.protectedMethod();
    }
}

Protected в Kotlin

В Kotlin protected члены класса видны ТОЛЬКО в:

1. Текущем классе
2. Наследниках класса (включая наследников в других файлах и пакетах)

Важное отличие: в Kotlin protected члены НЕ видны другим классам того же пакета.

// Kotlin пример
package com.example.base

open class Parent {
    protected val protectedField: String = "protected"
    
    protected fun protectedMethod() {
        println("Protected method")
    }
}

// Другой файл в том же пакете
package com.example.base

class Sibling {
    fun tryAccess() {
        val parent = Parent()
        // ОШИБКА КОМПИЛЯЦИИ: недоступно в том же пакете
        // parent.protectedField
        // parent.protectedMethod()
    }
}

// Другой пакет
package com.example.other

import com.example.base.Parent

class Child : Parent() {
    fun accessExample() {
        // Доступ разрешен - наследник
        println(protectedField)
        protectedMethod()
    }
}

Ключевые различия

Почему Kotlin изменил семантику?

Разработчики Kotlin сознательно сузили область видимости protected по нескольким причинам:

1. Устранение неявной связанности через пакеты В Java использование protected создает неявную связь между классами одного пакета, что может привести к нарушению инкапсуляции.

2. Более четкая модель наследования protected в Kotlin логически связан только с наследованием, что делает его семантику более предсказуемой.

3. Согласованность с другими модификаторами Kotlin имеет более последовательную систему модификаторов:

   • private - только внутри класса/файла
   • protected - только для наследников
   • internal - внутри модуля (аналог package-private + больше)
   • public - везде

Практические последствия

При миграции с Java на Kotlin:

// Java-код, который нужно адаптировать
// В Java это работало:
// package com.example;
// public class A {
//     protected void method() {}
// }
// class B { // В том же пакете
//     void use() {
//         new A().method(); // Разрешено в Java
//     }
// }

// В Kotlin нужно либо:
// 1. Сделать метод internal
open class A {
    internal fun method() {} // Видно в модуле
}

// 2. Или изменить архитектуру
open class A {
    protected fun method() {}
}

class B : A() { // Теперь нужно наследование
    fun use() {
        method() // Теперь доступно
    }
}

Internal как альтернатива

Для случаев, когда нужна видимость в пределах модуля (аналог package-private в Java, но лучше), Kotlin предлагает модификатор internal:

internal class InternalClass {
    internal val internalProperty: String = "internal"
}

// Доступно в любом файле того же модуля
// Но недоступно в другом модуле

Выводы

• Kotlin protected строже - только для наследников, без доступа в пакете
• Java protected шире - включает package-private доступ
• При портировании кода нужно заменять Java protected на Kotlin internal если нужен доступ в пределах модуля/пакета
• Архитектурно подход Kotlin способствует более чистому дизайну, где доступ через наследование четко отделен от доступа через расположение в пакете

Это изменение отражает общую тенденцию Kotlin к более эксплицитным и безопасным конструкциям, уменьшая неявные связи между компонентами системы.