Clases abstractas y métodos abstractos en Kotlin

Contenido del curso

Fundamentos de Kotlin

Contro de Flujo y Funciones

Programación Orientada a Objetos en Kotlin

Características Avanzadas de Kotlin

Patrones Avanzados de Kotlin

Construyendo tu Aplicación Kotlin

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:01

Clases abstractas y métodos abstractos en Kotlin

Curso de Kotlin

Clase 27 de 35

Clase 27 / 35

Recursos

Las abstract classes y las interfaces son dos conceptos clave en la programación orientada a objetos que permiten estructurar código de manera eficiente. En este contenido profundizamos en entender qué son estas abstract classes, en qué se diferencian de las interfaces y en qué situaciones es recomendable utilizar cada una para lograr un código más limpio y escalable.

¿Qué es una abstract class y cómo funciona?

Una abstract class es una clase especial en programación que define métodos y variables para que otras clases, mediante la herencia, implementen sus funcionalidades. A diferencia de las clases comunes, estas no pueden instanciarse directamente, ya que contienen métodos abstractos y variables abstractas que deben ser obligatoriamente definidos por las subclases que heredan de ellas.

La declaración se realiza con la palabra reservada abstract.
Garantiza que cualquier clase que la extienda debe implementar sus métodos abstractos definidos en la clase base.

¿Cómo declarar una abstract class?

Para declarar una abstract class, sigue el modelo siguiente:

abstract class BaseEmailRepository {
    abstract fun save(email: String)
}

Cuando otra clase extiende esta clase abstracta, debe implementar el método.

¿En qué se diferencian abstract classes e interfaces?

La principal diferencia radica en cómo establecen relaciones entre las clases que las implementan:

Las abstract classes usan herencia, creando relaciones directas entre una clase padre y sus subclases. Esto implica una jerarquía y dependencia.
Las interfaces usan composición y no generan esta jerarquía. Permiten crear pequeñas funcionalidades encapsuladas y mantener clases más independientes.

Al decidir entre ellas, considera:

Usar abstract class si todas las variables o métodos se utilizarán frecuentemente en subclases.
Usar interfaces para pequeños contratos flexibles que no necesariamente requerirán todas sus variables o métodos en todas las implementaciones.

¿Qué implica el uso de herencia versus composición?

La herencia puede llevar a una acumulación de métodos y variables innecesarias en algunas clases hijas, mientras que la composición mediante interfaces permite un diseño modular y más liviano.

De este modo, interfaces ayudan a mantener un código ordenado y limpio, facilitando futuras modificaciones o ampliaciones.

Ejemplo práctico con abstract class

Aquí tienes un ejemplo práctico que ilustra cómo usar abstract class:

abstract class BaseEmailNotifier {
    abstract fun notify(email: String)
}

class ConsoleNotifier : BaseEmailNotifier() {
    override fun notify(email: String) {
        println("Email recibido: $email")
    }
}

fun main() {
    val notifier = ConsoleNotifier()
    notifier.notify("ejemplo@correo.com")
}

Recuerda, implementas la función notify obligatoriamente en la subclase cuando usas abstract class, algo similar a la implementación requerida por una interfaz, pero mediante herencia.

¿Cuándo elegir abstract class sobre interfaces?

Elige abstract class si:

Necesitas mantener y extender una lógica común de manera sencilla a través de múltiples implementaciones relacionadas por jerarquía.

Opta por interfaces cuando:

Prefieres flexibilidad y modularidad, evitando relaciones jerárquicas rígidas entre las clases que implementan funcionalidades similares.

Lucia Aldana Castillo

Hace un año

Diferencias entre interface y abstract class

EmailRepository y NotifyEmailRepository:

👉 No almacena datos ni estado.

👉 Define un contrato puro, sin lógica.

👉 Cualquier clase (en memoria, SQLite, remota) puede implementarla de forma diferente.

class InMemoryEmailRepositoryImpl : EmailRepository

👉 Implementa la interface, proporcionando una implementación concreta en memoria.

👉 La lógica es 100% propia.

abstract class NotifyEmailRepositoryImpl(...) : NotifyEmailRepository

Es una abstract class con lógica común:

Guarda el emailRepository como dependencia.
Implementa notifyById(id) (método común).
Obliga a subclases a definir notify(email) → comportamiento específico.

💡 Esta clase es un template: resuelve lo repetido y fuerza a que cada implementación defina su variante.

NotifySentEmailRepositoryImpl y NotifyReceivedEmailRepositoryImpl

Son clases concretas, que hereda la lógica común de NotifyEmailRepositoryImpl Solo definen qué imprimir cuando se notifica un envío.

👉 Siguen el patrón: reutilizar lógica de búsqueda y solo definir cómo se notifica.


import java.util.UUID

data class Emails(
    val id: UUID,
    val asunto: String,
    val mensaje: String
)

// Interface
interface EmailRepository {
    val sizeEmails: Int
    fun save(email: Emails)
    fun findById(id: UUID): Emails?
    fun findAll(): List<Emails>
    fun deleteById(id: UUID)
}

class InMemoryEmailRepositoryImpl : EmailRepository {

    val repositoryName: String = "InMemoryEmailRepositoryImpl"

    private val emails = mutableListOf<Emails>()

    override val sizeEmails: Int
        get() = emails.size

    override fun save(email: Emails) {
        emails.add(email)
    }

    override fun findById(id: UUID): Emails? {
        return emails.find { it.id == id }
    }

    override fun findAll(): List<Emails> {
        return emails
    }

    override fun deleteById(id: UUID) {
        emails.removeIf { it.id == id }
    }
}

// abstract
interface NotifyEmailRepository {
    fun notifyById(id: UUID)
}

abstract class NotifyEmailRepositoryImpl(
    private val emailRepository: EmailRepository
): NotifyEmailRepository {
    /*
    Se usa **final override** para evitar que subclases vuelvan a sobrescribir
    ese método (notifyById). Así asegurás que la lógica de búsqueda no se modifique.
     */
    final override fun notifyById(id: UUID) {
        emailRepository.findById(id)?.let {
            notify(it)
        }
    }

    /*
    protected: solo las subclases pueden usarla.
    abstract: obliga a cada subclase a implementar cómo notificar.
    Así, cada subclase solo define el println, pero no toca la lógica de búsqueda.
     */
    protected abstract fun notify(email: Emails)
}

class NotifySentEmailRepositoryImpl(
    repository: EmailRepository
): NotifyEmailRepositoryImpl(repository) {
    override fun notify(email: Emails) {
        println("Email enviado: ${email.asunto}")
    }
}

class NotifyReceivedEmailRepositoryImpl(
    repository: EmailRepository
): NotifyEmailRepositoryImpl(repository) {
    override fun notify(email: Emails) {
        println("Tienes un nuevo email: ${email.asunto}")
    }
}

fun main() {
    val emailRepository: EmailRepository = InMemoryEmailRepositoryImpl()
    val notifySentEmailRepository: NotifyEmailRepository = NotifySentEmailRepositoryImpl(emailRepository)
    val notifyReceivedEmailRepository: NotifyEmailRepository = NotifyReceivedEmailRepositoryImpl(emailRepository)

    println(emailRepository.sizeEmails)

    emailRepository.save(
        Emails(
            id = UUID.randomUUID(),
            asunto = "Hola",
            mensaje = "Que tal"
        )
    )
    notifySentEmailRepository.notifyById(emailRepository.findAll()[0].id)
    notifyReceivedEmailRepository.notifyById(emailRepository.findAll()[0].id)

    emailRepository.save(
        Emails(
            id = UUID.randomUUID(),
            asunto = "Hola 2",
            mensaje = "Que tal 2"
        )
    )

    notifySentEmailRepository.notifyById(emailRepository.findAll()[1].id)
    notifyReceivedEmailRepository.notifyById(emailRepository.findAll()[1].id)

    println(emailRepository.sizeEmails)
    println(emailRepository.findAll())
    println(emailRepository.findById(emailRepository.findAll()[0].id))
    emailRepository.deleteById(emailRepository.findAll()[0].id)
    println(emailRepository.findAll())
}

Fundamentos de Kotlin

Kotlin desde cero para apps y backend

Instalación y configuración de IntelliJ IDEA para Kotlin

Primer programa Kotlin con IntelliJ

Variables y tipos de datos en Kotlin

Operadores aritméticos y módulo en Kotlin

Operadores lógicos and, or y not en Kotlin

Nulabilidad y llamados seguros en Kotlin

Lectura de datos del usuario con readLine

Contro de Flujo y Funciones

Creación de funciones en Kotlin para organizar código

Condicionales en Kotlin: if/else

Sentencia when de Kotlin vs if/else

Arrays y listas mutables en Kotlin: creación y manipulación

Listas inmutables y mutables en Kotlin

Ciclos for, while y do-while en Kotlin

Programación Orientada a Objetos en Kotlin

Clases y objetos en Kotlin con ejemplos

Getters y setters en Kotlin

Dataclases en Kotlin: ventajas sobre clases normales

Enums en Kotlin: Constantes organizadas para casos específicos

Manejo de excepciones con Try Catch Finally en Kotlin

Características Avanzadas de Kotlin

Extension functions en Kotlin para ampliar clases existentes

Lambdas y callbacks en Kotlin

map, filter y find en colecciones Kotlin

Scope functions let, apply y run en Kotlin

with y also en Kotlin para qué sirven

Modificadores de visibilidad y encapsulamiento en Kotlin

Interfaces y polimorfismo en Kotlin

Patrones Avanzados de Kotlin

Clases abstractas y métodos abstractos en Kotlin

Sealed classes em Kotlin para estados

Sealed interfaces para modelar acciones en Kotlin

Generics en Kotlin: tipos genéricos para código reutilizable

Construyendo tu Aplicación Kotlin

Modelos y repositorios del simulador de correos

Lógica de negocio en un email simulator con Kotlin

Completando el Inbox Service en Kotlin

Menú de consola para Inbox en Kotlin

Pruebas funcionales de un sistema de correo en Kotlin

Clases abstractas y métodos abstractos en Kotlin