Restricción de jerarquías de clases en Kotlin

Kotlin es un lenguaje de programación de propósito general tipificado estáticamente desarrollado por JetBrains, que ha creado IDE de clase mundial como IntelliJ IDEA, PhpStorm, Appcode, etc. Fue presentado por primera vez por JetBrains en 2011 y es un nuevo lenguaje para JVM. Kotlin es un lenguaje orientado a objetos y un «lenguaje mejor» que Java, pero aún así es totalmente interoperable con el código Java. En este artículo, aprenderemos cómo restringir las jerarquías de clases en Kotlin. Antes de continuar, debe conocer algunos conceptos básicos de programación orientada a objetos y estar familiarizado con las clases y las propiedades de las clases, como las herencias.

Entonces, cuando estamos seguros de que un valor o una clase puede tener solo un conjunto limitado de tipos o un número de subclases, es cuando tratamos de restringir la jerarquía de clases. Sí, esto puede sonar como una clase de enumeración pero, en realidad, es mucho más que eso. La constante de enumeración existe solo como una sola instancia, mientras que una subclase de una clase sellada puede tener varias instancias que pueden contener un estado. Veamos un ejemplo en los pasos mencionados.

Implementación paso a paso

Paso 1. Crearemos una clase sellada llamada ToastOperation . Bajo el mismo archivo fuente, definiremos una subclase ShowMessageToast :

class ShowMessageToast(val message:String):ToastOperation()

Paso 2. Además, definiremos un objeto ShowErrorToast :

object ShowErrorToast:ToastOperation()

Paso 3 Como habrá notado, hemos definido un objeto en lugar de una declaración de clase completa, porque el objeto howErrorToast no tiene ningún estado. Además, al hacerlo, lo hemos eliminado del bloque when, ya que solo hay una instancia. Ahora, podemos usarlo en una declaración when, de la siguiente manera:

fun doToastOperation (toastOperation: ToastOperation) {
  when (toastOperation) {
    is ShowMessageToast
         ->Toast.makeText(this, toastOperation.message, Toast.LENGTH_LONG).show()
    ShowErrorToast->Toast . makeText (this, "Error...Grr!",Toast.LENGTH_LONG).show()
  }
}

Paso 4 El beneficio clave es que no necesitamos implementar el bloque else, que actuó como el bloque predeterminado cuando las otras declaraciones no encajaban. Según la documentación, una clase sellada puede tener subclases, pero todas ellas deben declararse en el mismo archivo que la propia clase sellada. Sin embargo, las subclases de subclases no necesitan definirse en el mismo archivo. Es abstracto por sí mismo, y no puede crear instancias de objetos a partir de él. Aquí está nuestra estructura de clases selladas :

sealed class ToastOperation {

}
object ShowErrorToast:ToastOperation()
class ShowMessageToast (val message:String):ToastOperation()

Como puede ver, hemos mantenido todas las subclases en el mismo archivo fuente en el que hemos definido la clase sellada . En el ejemplo anterior, estábamos seguros de que solo podemos tener dos tipos de brindis: un brindis de error y un brindis con un mensaje personalizado. Así que creamos una clase sellada ToastOperation y creamos dos subclases de ToastOperation . Tenga en cuenta que si no estamos seguros de los tipos de subclases, no usaremos una clase sellada , en ese caso, una clase de enumeración podría ser más adecuada.

Si está utilizando versiones de Kotlin anteriores a la 1.1, deberá implementar las subclases dentro de la clase sellada, de forma muy parecida a esto:

sealed class ToastOperation {
    object ShowErrorToast:ToastOperation()
    class ShowMessageToast(val message:String):ToastOperation()
}

Nota : también puede usar la forma anterior en la nueva versión de Kotlin.