Respuesta.

Historia de la pregunta:

Los modificadores de visibilidad (visibility modifiers) son una característica clave de Kotlin, heredada y mejorada en comparación con Java. Permiten restringir el acceso a clases, funciones y propiedades, apoyando las mejores prácticas de encapsulación y modularidad.

Problema:

El uso incorrecto de la visibilidad puede llevar a violaciones de las capas de arquitectura, fugas de implementación al exterior o, por el contrario, hacer que clases y métodos sean inaccesibles donde se necesitan. Los errores en esto a menudo se descubren demasiado tarde.

Solución:

En Kotlin hay cuatro modificadores de visibilidad:

public — accesible en todas partes (por defecto)
internal — accesible solo dentro de un módulo
protected — accesible dentro de la clase y sus subclases
private — accesible solo dentro del archivo, clase u objeto

Ejemplo de código:

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

class Derived : Base() {
    fun test() {
        baseAndDerived() // accesible
        // onlyBase() — error
    }
}

Características clave:

internal es específico de Kotlin, no está presente en Java
Los modificadores para elementos de nivel superior funcionan de manera especial: private restringe la visibilidad al archivo
En las interfaces, todos los métodos y propiedades son public por defecto

Preguntas trampa.

¿Cómo funciona el modificador internal al publicar una biblioteca?

internal oculta los elementos dentro de un módulo, pero si se compila la biblioteca en un jar/aar, los elementos internos son visibles a través de reflexión.

¿Cuál es la diferencia entre private para una propiedad de clase y una función de nivel superior?

private en una propiedad de clase limita la visibilidad solo a la clase, mientras que para niveles superiores — solo al archivo donde se declara el elemento.

¿Se puede aplicar protected a una función de nivel superior?

No, protected solo es permitido para miembros de clase o interfaz. No se puede usar protected para elementos de nivel superior — habrá un error de compilación.

Errores típicos y antipatrón

Clases y funciones excesivamente abiertas (public sin necesidad)
Uso de internal donde el módulo une componentes independientes
Intento de usar protected para funciones o propiedades de nivel superior

Ejemplo de la vida real

Caso negativo

Una gran biblioteca declaró casi todas sus API como public, incluyendo utilidades y helpers — como resultado, los usuarios comenzaron a depender de los detalles de implementación.

Ventajas:

Facilidad de uso para todos

Desventajas:

Dificultades con la compatibilidad hacia atrás y el refactoring

Caso positivo

Solo se declararon como public las clases necesarias, las demás son internal o private, y los niveles de visibilidad están claramente separados.