Tareas como abstracciones de acciones repetibles

El contrato operativo de una tarea

Para que una acción pueda tratarse como tarea, conviene hacer explícito su contrato operativo:

• El nombre permite identificar o invocar el trabajo.
• La intención explica por qué existe la tarea.
• Las entradas indican qué datos, argumentos o archivos necesita.
• Las precondiciones declaran qué debe ser cierto antes de ejecutar.
• Los efectos o resultados describen qué produce, modifica o concluye.
• La salida observable permite revisar qué ocurrió durante la ejecución.
• El criterio de éxito o falla permite interpretar si la tarea terminó correctamente.

Esta separación es útil porque permite razonar sobre una tarea incluso antes de decidir si vivirá en un script, en una herramienta de línea de comandos o en un sistema de construcción.

Un script con varias tareas pequeñas

Para hacer concreta esta idea, usaremos un script real llamado library-tasks.main.kts. El objetivo no es mostrar una característica especial de Kotlin para definir tareas, sino representar explícitamente varias acciones repetibles dentro de un mismo artefacto ejecutable.

Desde la línea de comandos, el script recibe el nombre de la tarea como primer argumento. Por ejemplo:

kotlin library-tasks.main.kts count-files .
kotlin library-tasks.main.kts summarize .

kotlin library-tasks.main.kts count-files .
kotlin library-tasks.main.kts summarize .

Cada comando expresa una intención distinta. count-files cuenta archivos en una carpeta, mientras summarize muestra un resumen breve del proyecto revisado. Más adelante, en el ejercicio, agregaremos una tercera tarea: list, encargada de mostrar las tareas disponibles.

La diferencia importante es que ya no pensamos el script como una sola operación concreta. Ahora el script actúa como un pequeño punto de entrada que despacha tareas nombradas. Cada tarea puede tener su propio propósito, entradas, precondiciones, salida observable y criterio de éxito o falla.

El punto central no es que Kotlin tenga una sintaxis especial para tareas. El punto es que podemos representar tareas explícitamente incluso antes de usar una herramienta especializada como un sistema de construcción.

Representar una tarea con una interfaz

Para que el script pueda tratar todas las tareas de la misma forma, necesitamos una abstracción común. En este caso, esa abstracción puede ser una interfaz sencilla: cada tarea tiene un nombre y una operación run() run() que ejecuta su trabajo.

interface Task {
    val name: String
    val description: String

    fun run(context: TaskContext): TaskResult
}

class TaskContext(
    val projectRoot: Path,
)

interface TaskResult {
    val message: String
    val exitCode: Int
}

class SuccessfulTaskResult(
    override val message: String,
) : TaskResult {
    override val exitCode: Int = 0
}

class FailedTaskResult(
    override val message: String,
) : TaskResult {
    override val exitCode: Int = 1
}

interface Task {
    val name: String
    val description: String

    fun run(context: TaskContext): TaskResult
}

class TaskContext(
    val projectRoot: Path,
)

interface TaskResult {
    val message: String
    val exitCode: Int
}

class SuccessfulTaskResult(
    override val message: String,
) : TaskResult {
    override val exitCode: Int = 0
}

class FailedTaskResult(
    override val message: String,
) : TaskResult {
    override val exitCode: Int = 1
}

Por ejemplo, una tarea concreta puede implementar esa interfaz sin cambiar el resto del script:

class CountFilesTask : Task {
    override val name: String = "count-files"
    override val description: String = "Counts files in the selected project folder."

    override fun run(context: TaskContext): TaskResult {
        val fileCount = context.projectRoot
            .toFile()
            .walkTopDown()
            .count { it.isFile }

        return SuccessfulTaskResult("Found $fileCount files.")
    }
}

class CountFilesTask : Task {
    override val name: String = "count-files"
    override val description: String = "Counts files in the selected project folder."

    override fun run(context: TaskContext): TaskResult {
        val fileCount = context.projectRoot
            .toFile()
            .walkTopDown()
            .count { it.isFile }

        return SuccessfulTaskResult("Found $fileCount files.")
    }
}

Lo importante no es que esta implementación sea sofisticada, sino que la tarea ya tiene una forma reconocible: nombre, descripción, contexto de ejecución, resultado observable y código de salida. Esa forma común permite agregar nuevas tareas sin rediseñar el script completo.

Despachar una tarea por su nombre

Una vez que las tareas comparten la misma interfaz, el script puede registrarlas en una colección común. En vez de escribir un flujo distinto para cada comando, podemos asociar cada nombre con la tarea que debe ejecutarse.

// Otras tareas concretas pueden implementarse de la misma forma.
class SummarizeProjectTask : Task {
    override val name: String = "summarize"
    override val description: String = "Shows a brief summary of the selected project folder."

    override fun run(context: TaskContext): TaskResult {
        val projectRoot = context.projectRoot.toAbsolutePath().normalize()
        val fileCount = projectRoot
            .toFile()
            .walkTopDown()
            .count { it.isFile }

        return SuccessfulTaskResult("Project: $projectRoot${System.lineSeparator()}Files: $fileCount")
    }
}


// El despachador registra las tareas disponibles por nombre.
val tasks: Map<String, Task> = listOf(
    CountFilesTask(),
    SummarizeProjectTask(),
).associateBy { task -> task.name }

val taskName = args.firstOrNull()
val selectedTask = tasks[taskName]

val result = if (selectedTask == null) {
    FailedTaskResult("Unknown task: $taskName")
} else {
    val projectRoot = Path.of(args.getOrElse(1) { "." })
    val context = TaskContext(projectRoot)

    selectedTask.run(context)
}

println(result.message)
exitProcess(result.exitCode)

// Otras tareas concretas pueden implementarse de la misma forma.
class SummarizeProjectTask : Task {
    override val name: String = "summarize"
    override val description: String = "Shows a brief summary of the selected project folder."

    override fun run(context: TaskContext): TaskResult {
        val projectRoot = context.projectRoot.toAbsolutePath().normalize()
        val fileCount = projectRoot
            .toFile()
            .walkTopDown()
            .count { it.isFile }

        return SuccessfulTaskResult("Project: $projectRoot${System.lineSeparator()}Files: $fileCount")
    }
}


// El despachador registra las tareas disponibles por nombre.
val tasks: Map<String, Task> = listOf(
    CountFilesTask(),
    SummarizeProjectTask(),
).associateBy { task -> task.name }

val taskName = args.firstOrNull()
val selectedTask = tasks[taskName]

val result = if (selectedTask == null) {
    FailedTaskResult("Unknown task: $taskName")
} else {
    val projectRoot = Path.of(args.getOrElse(1) { "." })
    val context = TaskContext(projectRoot)

    selectedTask.run(context)
}

println(result.message)
exitProcess(result.exitCode)

El despachador cumple una responsabilidad pequeña: conectar los argumentos de la línea de comandos con una tarea concreta. Para hacerlo, lee el nombre solicitado, busca la tarea correspondiente, construye un contexto de ejecución, ejecuta la tarea y transforma el resultado en salida observable y código de salida.

Esta separación evita que el script mezcle dos decisiones distintas: qué tarea ejecutar y cómo se ejecuta cada tarea. El despachador solo decide la primera; la segunda queda encapsulada dentro de cada implementación de Task Task .

• El nombre escrito en la línea de comandos identifica la tarea solicitada.
• La tabla tasks tasks permite buscar una implementación sin escribir casos especiales para cada comando.
• El TaskContext TaskContext agrupa los datos compartidos que la tarea necesita para ejecutarse.
• El TaskResult TaskResult concentra el mensaje final y el código de salida.

Un detalle importante es que los nombres de las tareas deberían ser únicos. Si dos tareas usan el mismo name name , la tabla generada con associateBy() associateBy() no puede representar ambas de forma distinguible. En un script pequeño basta con revisar esto manualmente; en una herramienta más completa, convendría validarlo explícitamente.

Lo importante es que agregar una nueva tarea no exige reescribir el flujo principal. Basta con crear otra clase que implemente Task Task y registrarla en la lista de tareas disponibles. Esa es la misma idea que luego crecerá en un sistema de construcción: muchas tareas nombradas, cada una con su propio contrato operativo, pero coordinadas por una herramienta común.

Conclusiones

Una tarea permite darle nombre y estructura a una acción repetible. En vez de pensar un script como una secuencia única de instrucciones, podemos dividirlo en unidades con propósito propio, entradas conocidas, salida observable y un criterio claro para decidir si la ejecución fue exitosa.

En el ejemplo de esta lección, esa idea se representó con una interfaz Task Task , implementaciones concretas como CountFilesTask CountFilesTask y SummarizeProjectTask SummarizeProjectTask , y un despachador que registra las tareas por nombre. Este diseño mantiene separado el flujo principal del script de la lógica específica de cada tarea.

Esta separación es pequeña, pero prepara una idea central para el siguiente paso conceptual: cuando las tareas empiezan a crecer, relacionarse entre sí y repetirse dentro de un flujo de desarrollo, conviene usar un sistema de construcción para coordinarlas.