Bibliotecas de software

Abstract

Esta lección introduce el concepto de biblioteca de software como pieza central en el desarrollo moderno: colecciones de funciones, clases y componentes que encapsulan soluciones reutilizables. Exploramos qué significa tratarlas como APIs, por qué son fundamentales para acelerar el desarrollo y asegurar calidad, y cómo se diferencian —y relacionan— con frameworks, servicios, paquetes y módulos.

También revisamos las principales categorías de bibliotecas (estáticas, dinámicas, de código fuente, de clases, de tiempo de ejecución y estándar del lenguaje), junto con ejemplos populares en distintos ecosistemas (Kotlin, Java, Python, C++, .NET). Estos elementos sientan las bases para nuestro siguiente paso: diseñar y publicar bibliotecas en Kotlin aplicando principios de buen diseño de APIs.

¿Qué es una biblioteca de software?

Una biblioteca de software es un conjunto organizado de funciones, clases y componentes diseñados para resolver problemas específicos y reutilizarse en diferentes proyectos. A diferencia de una aplicación completa, una biblioteca no se ejecuta por sí sola: se integra en otros programas para ampliar sus capacidades.

En esencia, una biblioteca encapsula soluciones reutilizables a tareas comunes —como manejar archivos, conectarse a redes o procesar datos— de manera que no tengamos que reinventarlas cada vez.

Interfaz de programación de aplicaciones (Application Programming Interface, API)

Una API es el contrato que define qué puede hacer un componente (nombres, parámetros, tipos, errores, semántica), sin exponer cómo lo hace. Es la superficie pública con la que otras partes del sistema interactúan.

API ≠ biblioteca

Una biblioteca es una implementación reutilizable; expone una API. Pero una API también puede ser un servicio web, un sistema operativo, o las primitivas de un framework. Toda biblioteca tiene API, pero no toda API es una biblioteca.

Considerar una biblioteca como una API nos permite razonar sobre su diseño desde la perspectiva de cómo será utilizada. En otras palabras, los principios de diseño de buenas APIs —claridad, consistencia, facilidad de uso, extensibilidad— también deben permear el diseño de bibliotecas. Estos principios se explorarán en una lección futura, y nos darán criterios concretos para evaluar y mejorar nuestras propias bibliotecas.

¿Por qué necesitamos bibliotecas de software?

Las bibliotecas existen para no reinventar la rueda. Permiten reutilizar soluciones probadas y enfocarnos en el dominio del problema, no en la infraestructura repetitiva.

  • Velocidad: aceleran el desarrollo al reutilizar componentes listos.
  • Calidad y seguridad: concentran correcciones, pruebas y auditorías en un solo lugar.
  • Consistencia: estandarizan prácticas (APIs, formatos, estilos).
  • Interoperabilidad: conectan sistemas (protocolos, formatos, drivers).
  • Mantenibilidad: actualizaciones y mejoras se propagan sin duplicar esfuerzos.
  • Gestión de riesgos: delegan complejidad técnica en paquetes mantenidos por especialistas.

Regla práctica

Si un problema es común y la solución está bien entendida y mantenida, usa una biblioteca. Invierte desarrollo propio solo cuando la solución impacta tu ventaja competitiva o necesidades únicas.

Open-source

En el ecosistema abierto, las bibliotecas son el tejido base de la innovación: miles de proyectos que evolucionan en comunidad.

  • Colaboración: correcciones y mejoras desde una base de contribuyentes diversa.
  • Transparencia: código auditable ( security by transparency ).
  • Ritmo de innovación: adopción rápida de estándares y mejores prácticas.
  • Licencias: elige licencias compatibles (MIT, Apache-2.0, MPL, GPL) según tu caso.

Software propietario

Aun en contextos cerrados, las bibliotecas son clave para reducir costos, acelerar entregas y proteger la calidad.

  • Modularidad interna: equipos independientes que se comunican mediante contratos (APIs) estables.
  • Cumplimiento y riesgos: control de versiones, auditorías y trazabilidad.
  • Retorno de la inversión (Return on Investment, ROI): evita duplicación de esfuerzo y deuda técnica

    Costos acumulados por mantener código propio ineficiente o mal diseñado.

    por soluciones ad-hoc.

Política interna recomendada

Catálogo corporativo de bibliotecas aprobadas, registro de dependencias, ventanas de actualización, y guía de versionado.

¿Cuándo construir y cuándo adoptar?

  • Adopta si existe una biblioteca madura que cubre tu necesidad con soporte activo y licencia compatible.
  • Construye si tu caso es diferenciador, regulado, o requiere garantías que el ecosistema no ofrece (rendimiento, compliance, contratos).
  • Construye también si ninguna alternativa existente ofrece una licencia que se ajuste a los requisitos de tu proyecto (ej. uso comercial, distribución, copyleft).

¿Cómo se relacionan las bibliotecas con otros conceptos?

Una biblioteca es código reutilizable que expone una API y se integra en otras piezas de software. A partir de ahí, se conectan varios conceptos cercanos:

  • Framework: como una biblioteca, pero con inversión de control. En lugar de que tú llames a la biblioteca, el framework decide el flujo principal y llama a tu código en los lugares correctos. Ejemplo: un framework web define cómo se atienden las peticiones y solo te pide que rellenes las partes específicas (qué hacer en cada ruta).
  • Servicio: funcionalidad expuesta por red (p. ej., HTTP/REST, gRPC). Se consume desde aplicaciones o bibliotecas clientes. Ejemplo: pedirle a un servicio de mapas que devuelva coordenadas de una dirección. Un Microservicio es un servicio pequeño y autónomo, que se despliega aparte y colabora con otros (por ejemplo, un servicio que solo maneja autenticación de usuarios).
  • Paquete: unidad de distribución que puede contener bibliotecas, herramientas o recursos. Ejemplo: descargar un paquete de utilidades de fechas para no tener que programarlas desde cero.
  • Módulo: unidad de organización o compilación dentro de un proyecto. Ejemplo: dividir un sistema en un módulo lib con la lógica de negocio y otro módulo app que la utiliza (volveremos a esto).

Mapa mental rápido

  • Biblioteca vs. Framework: tú llamas a la biblioteca; el framework te llama a ti.
  • Biblioteca vs. Servicio: la biblioteca es composición en proceso; el servicio es comunicación por red.
  • Paquete: cómo distribuyes; módulo: cómo organizas/compilas.

Elección práctica

  • Usa bibliotecas si quieres control local, pruebas unitarias simples y dependencia estática.
  • Usa servicios si necesitas escalado independiente, límites claros de despliegue o compartir funcionalidad entre múltiples apps.
  • Usa frameworks si aceptas su ciclo de vida e inversión de control a cambio de productividad y convenciones.

Categorías de bibliotecas de software

A lo largo de la historia se han definido distintas categorías de bibliotecas, según cómo se comparten, se vinculan o se consumen. No es necesario estudiarlas todas en detalle, pero conviene conocer las más relevantes para entender el ecosistema actual.

  • Estáticas: se incluyen en el programa en tiempo de compilación. Una vez compilado, el ejecutable no depende de archivos externos. Ejemplo: compilar un binario en C que ya lleva dentro todas las funciones de su librería matemática.
  • Dinámicas / Compartidas: se cargan en tiempo de ejecución. Varios programas pueden compartir la misma copia en memoria, reduciendo tamaño y facilitando actualizaciones. Ejemplo: las DLL en Windows o los .so en Linux.
  • De código fuente: distribuyen directamente el código (no compilado). Es el caso más común en ecosistemas modernos como Kotlin, donde las dependencias se publican como paquetes y se compilan en tu proyecto.
  • De clases: colecciones de tipos y funciones organizadas en jerarquías (p. ej., JARs en Java). Son la base de lo que diseñaremos en este curso: bibliotecas orientadas a funciones y tipos en Kotlin.
  • De tiempo de ejecución: exponen utilidades del entorno donde se ejecuta el programa (p. ej., manejo de memoria, hilos, E/S). Normalmente vienen con el compilador o la plataforma.
  • Estándar del lenguaje: la colección oficial de funciones, clases y estructuras que acompaña a cada lenguaje.

Ejemplos de bibliotecas populares

Cada ecosistema de programación tiene su propio conjunto de bibliotecas populares. Algunas vienen incluidas como parte de la biblioteca estándar del lenguaje, mientras que otras son desarrolladas por la comunidad para resolver problemas específicos. Conocerlas ayuda a entender cómo se diseñan, se distribuyen y se consumen.

  • Bibliotecas estándar: cada lenguaje suele traer una colección oficial de funciones y clases. Ejemplos: Kotlin Standard Library en Kotlin, Java Core Libraries en Java, Python Standard Library en Python, C++ Standard Library en C++.
  • Manejo de datos y colecciones: bibliotecas que amplían la capacidad de trabajar con estructuras de datos. Ejemplos: Guava en Java, Pandas en Python, Arrow en Kotlin.
  • Red y comunicación: facilitan conectarse a internet, hacer peticiones HTTP o trabajar con protocolos. Ejemplos: OkHttp en la JVM

    Java Virtual Machine: plataforma de ejecución para lenguajes como Java, Kotlin o Scala.

    Una biblioteca "para la JVM" puede usarse en cualquiera de ellos.

     , Requests en Python, Axios en JavaScript.
  • Seguridad y criptografía: ofrecen primitivas para cifrado, autenticación y verificación de datos. Ejemplos: BouncyCastle en la JVM

    Java Virtual Machine: plataforma de ejecución para lenguajes como Java, Kotlin o Scala.

    Una biblioteca "para la JVM" puede usarse en cualquiera de ellos.

     y .NET

    .NET: plataforma de ejecución y framework que soporta lenguajes como C#, F#, y Visual Basic.

    Una biblioteca "para .NET" puede usarse en cualquiera de estos lenguajes, siempre que se ejecute sobre el mismo runtime.

    , cryptography en Python, OpenSSL en C/C++.
  • Procesamiento científico y matemático: útiles para cálculos avanzados, análisis de datos o machine learning. Ejemplos: NumPy en Python, scikit-learn en Python, EJML en la JVM

    Java Virtual Machine: plataforma de ejecución para lenguajes como Java, Kotlin o Scala.

    Una biblioteca "para la JVM" puede usarse en cualquiera de ellos.

     .

Conclusiones

En esta lección entendimos que una biblioteca es, ante todo, una API hecha para ser reutilizada. Esa mirada nos permite evaluar su diseño por cómo se usa (claridad, consistencia, estabilidad y extensibilidad) más que por cómo está implementada. Vimos también por qué las bibliotecas aceleran el desarrollo y elevan la calidad —tanto en open-source como en contextos propietarios— y cómo se relacionan con frameworks, servicios, paquetes y módulos. Finalmente, revisamos categorías históricas y actuales (estáticas, dinámicas/compartidas, de código fuente, de clases, runtime y estándar del lenguaje) para ubicar nuestro trabajo dentro del ecosistema.

A partir de aquí, el foco del curso será diseñar bibliotecas de funciones y jerarquías de tipos en Kotlin, organizarlas en paquetes y módulos y publicarlas con Gradle, aplicando principios de buen diseño de APIs que veremos en detalle en la siguiente lección.

Puntos clave

  • Biblioteca = API + implementación: diseñamos para quien la usa, no para quien la escribe.
  • Relación con otros conceptos: framework (invierte control), servicio (por red), paquete (distribuye), módulo (organiza/compila).
  • Categorías relevantes: estáticas, dinámicas/compartidas, de código fuente, de clases, runtime y estándar.
  • Razón práctica: reutilizar lo común para enfocarnos en el dominio y reducir riesgo y deuda técnica.
  • Ecosistema: open-source acelera innovación; en propietario, estandariza y controla riesgos.

¿Qué nos llevamos?

Las bibliotecas son más que colecciones de código: son contratos de uso que moldean cómo pensamos y construimos software. Al verlas como APIs, entendemos que su valor está en la claridad y facilidad con que otros puedan adoptarlas. Diseñar bibliotecas es, en realidad, diseñar puntos de encuentro entre quienes escriben y quienes usan el código. Esta perspectiva será la brújula que guiará el resto del curso.

¿Con ganas de más?