Ответ.

История вопроса:

Модификаторы видимости (visibility modifiers) — ключевая особенность Kotlin, унаследованная и усовершенствованная по сравнению с Java. Они позволяют ограничивать доступ к классам, функциям и свойствам, поддерживая лучшие практики инкапсуляции и модульности.

Проблема:

Некорректное использование видимости может привести к нарушению слоев архитектуры, утечке реализации наружу, или наоборот — сделать классы и методы недоступными там, где они нужны. Ошибки в этом часто обнаруживаются слишком поздно.

Решение:

В Kotlin есть четыре модификатора видимости:

public — доступно везде (по умолчанию)
internal — доступно только внутри одного модуля
protected — доступно внутри класса и его подклассов
private — доступно только внутри файла, класса или объекта

Пример кода:

open class Base {
    private fun onlyBase() {}
    protected fun baseAndDerived() {}
    internal fun insideModule() {}
    public fun anyone() {}
}

class Derived : Base() {
    fun test() {
        baseAndDerived() // доступно
        // onlyBase() — ошибка
    }
}

Ключевые особенности:

internal специфичен для Kotlin, отсутствует в Java
Модификаторы для top-level элементов работают по-особому: private ограничивает видимость файлом
На интерфейсах все методы и свойства по умолчанию public

Вопросы с подвохом.

Как работает модификатор internal при публикации библиотеки?

internal скрывает элементы внутри одного модуля, но если скомпилировать библиотеку в jar/aar, internal-элементы видны через reflection.

Чем отличается private для свойства класса и top-level функции?

private на свойстве класса ограничивает видимость только классом, а для top-level — только файлом, где объявлен элемент.

Можно ли применить protected к top-level функции?

Нет, protected допустим только для членов класса или интерфейса. Для top-level protected использовать нельзя — будет ошибка компиляции.

Типовые ошибки и анти-паттерны

Чрезмерно открытые классы и функции (public без необходимости)
Использование internal там, где модуль объединяет независимые компоненты
Попытка использовать protected для top-level функций или свойств

Пример из жизни

Негативный кейс

Крупная библиотека объявила почти все API public, включая утилиты и хелперы — в результате пользователи стали зависеть от деталей реализации.

Плюсы:

Простота использования для всех

Минусы:

Трудности с обратной совместимостью и рефакторингом

Позитивный кейс

Объявлены только необходимые классы public, остальные internal или private, четко разделены уровни видимости.