Principios SOLID en Kotlin: teoría y práctica para código limpio

Introducción: ¿Por qué es importante SOLID en Kotlin?

SOLID es un acrónimo de cinco principios fundamentales de la programación orientada a objetos, formulados por Robert Martin. En el contexto de Kotlin, un lenguaje multiplataforma moderno, estos principios adquieren una importancia especial. Kotlin combina tanto la POO como las capacidades funcionales, lo que permite escribir código más flexible y mantenible. Cumplir con los principios SOLID ayuda a los desarrolladores a crear sistemas que son fáciles de escalar, probar y mantener.

En este artículo, analizaremos cada uno de los cinco principios con ejemplos concretos en Kotlin, desde la teoría hasta la implementación práctica. Aprenderá cómo evitar antipatrones típicos y hacer que su código sea más limpio.

1. Single Responsibility Principle (SRP) — Principio de responsabilidad única

Teoría: Cada clase debe tener una sola razón para cambiar. En otras palabras, la clase debe ser responsable de una sola funcionalidad o tarea.

Práctica en Kotlin: A menudo, los desarrolladores violan el SRP al colocar en una misma clase la lógica de procesamiento de datos, la validación y el trabajo con servicios externos.

Ejemplo de violación:

class UserManager {    fun saveUser(user: User) {        // Guardar en la base de datos        println("User saved to DB")    }

    fun sendEmail(user: User, message: String) {        // Enviar email        println("Email sent to ${user.email}")    }

    fun validateUser(user: User): Boolean {        // Validación de datos        return user.name.isNotEmpty()    }}

Aquí, UserManager es responsable de guardar, enviar email y validar. Si la lógica de envío de email cambia, habrá que modificar esta clase, lo que podría romper el guardado de datos.

Versión corregida con SRP:

class UserRepository {    fun save(user: User) {        println("User saved to DB")    }}

class EmailService {    fun send(user: User, message: String) {        println("Email sent to ${user.email}")    }}

class UserValidator {    fun validate(user: User): Boolean {        return user.name.isNotEmpty()    }}

Ahora cada clase tiene una única responsabilidad, lo que simplifica las pruebas y la modificación del código.

2. Open/Closed Principle (OCP) — Principio de abierto/cerrado

Teoría: Las entidades de software (clases, módulos, funciones) deben estar abiertas para la extensión, pero cerradas para la modificación. Esto significa que debe poder agregar nuevo comportamiento sin cambiar el código existente.

Práctica en Kotlin: Utilice abstracciones (interfaces o clases abstractas) y polimorfismo. En Kotlin, las sealed class y las expresiones when son ideales para esto.

Ejemplo de violación:

class AreaCalculator {    fun calculate(shape: Any): Double {        return when (shape) {            is Circle -> Math.PI * shape.radius * shape.radius            is Square -> shape.side * shape.side            else -> throw IllegalArgumentException("Unknown shape")        }    }}

Para agregar una nueva figura (por ejemplo, Triangle), habría que modificar el método calculate.

Versión corregida con OCP:

interface Shape {    fun area(): Double}

class Circle(private val radius: Double) : Shape {    override fun area() = Math.PI * radius * radius}

class Square(private val side: Double) : Shape {    override fun area() = side * side}

class Triangle(private val base: Double, private val height: Double) : Shape {    override fun area() = 0.5 * base * height}

class AreaCalculator {    fun calculate(shape: Shape) = shape.area()}

Ahora, para agregar una nueva figura, basta con crear una nueva clase que implemente la interf