Estoy aprendiendo Kotlin ahora mismo. Por contexto, soy un desarrollador de Java por más de 10 años.
Me topé con el concepto de propiedades de respaldo . Según tengo entendido, el problema a resolver es este: tengo una propiedad en una clase. Quiero que esta propiedad sea mutable y visible solo en la clase contenedora, por lo que la declaro como private var . La propiedad solo debe modificarse en la clase contenedora, pero debe poder leerse fuera de la clase. Entonces, los documentos de Kotlin proponen algo como esto:
private var _word = "test" val word: String get() = _wordEsto funciona y cumple con los requisitos anteriores, pero parece un poco extraño para un desarrollador de Java. En Java, solo necesitamos 1 campo (no existen las propiedades en Java):
private String word = "test"; public String getWord() { return word; }AFAIK, mismo resultado.
Hoy aprendí que en Kotlin, simplemente puedo hacer que un setter sea privado. Entonces, ¿qué pasa con este código Kotlin:
var word = "test" private setTodos los requisitos cumplidos, código mucho más conciso.
¿Me estoy perdiendo algo? ¿Por qué necesito una propiedad de respaldo?
Tienes razón, no hay razón para hacer esto:
private var _word = "test" val word: String get() = _wordPorque solo puedes hacer esto:
var word = "test" private setAl igual que en Java con un campo privado y un método getter, puede elegir más tarde cambiar la lógica getter sin romper el código externo. En Java, puede elegir hacer algo más complicado que usar un solo campo de respaldo privado. Tal vez calcule algo que involucre múltiples campos de respaldo, etc. En Kotlin, puede regresar más tarde y cambiarlo para usar otras propiedades de respaldo más adelante si se vuelve más complicado, y cambiar solo la implementación del getter.
La razón más común que he visto para usar una propiedad de respaldo es para que pueda devolver un tipo menos específico en su propiedad pública:
private val _myList: MutableList<String> = mutableListOf() val myList: List<String> get() = _myListEste código ayuda a evitar que las clases externas alteren la lista devuelta.
Los diseñadores de Kotlin han mencionado en presentaciones que planean agregar una nueva sintaxis en el futuro que eliminará la necesidad de una propiedad de respaldo en este caso de uso. Algo como esto:
// Not valid syntax yet in Kotlin 1.6 private val myList: MutableList<String> = mutableListOf() public get: List<String>Otra razón para tener una propiedad de respaldo es simplemente cuando no hay una correspondencia uno a uno entre lo que está devolviendo y cómo se almacena o genera. Por ejemplo:
private val myRandom = Random(1234) val aNumber: Int get() = myRandom.nextInt(100)Otro uso para las propiedades de respaldo es permitirle almacenar un valor null internamente, pero exponer un tipo no nulo y proporcionar algún valor alternativo (que es posible que no desee almacenar, si nulo tiene un significado específico).
Aquí está el ejemplo de los documentos :
private var _table: Map<String, Int>? = null public val table: Map<String, Int> get() { if (_table == null) { _table = HashMap() // Type parameters are inferred } return _table ?: throw AssertionError("Set to null by another thread") } Lo que está sucediendo aquí es el típico accesor de estilo singleton getInstance() , donde si el objeto aún no está instanciado, lo creas y lo almacenas antes de devolverlo. A diferencia de un delegado lazy , internamente es una var , lo que significa que se puede reemplazar con un nuevo Map o null en este ejemplo (con algún código de controlador que anticipa un posible problema de concurrencia)
Sin embargo, la persona que llama no ve nada de esto: en apariencia, es solo un valor simple que val un Map no nulo, al que se accede como cualquier otra propiedad, sin necesidad de manejar un valor nulo potencial. Toda esa anulabilidad se abstrae, es un detalle interno.
Tendría que hacer lo mismo en Java (digamos si quisiera usar la anotación @NonNull en su captador), creando una variable interna y modificando su estado. Es solo que en Kotlin, obtiene un campo de respaldo básico "gratis" (si es que necesita uno) y solo si eso no se adapta adecuadamente a sus necesidades, debe comenzar a crear y hurgar en las propiedades usted mismo.