Bibliotecas vs. Frameworks – ¿Cuál es la diferencia?

La página de Wikipedia para una biblioteca de código la define como:

«En informática, una biblioteca es una colección de recursos no volátiles utilizados por los programas de ordenador, a menudo para el desarrollo de software. Pueden incluir datos de configuración, documentación, datos de ayuda, plantillas de mensajes, código preescrito y subrutinas, clases, valores o especificaciones de tipo.»

Comparado con la definición de un marco de trabajo:

«En la programación de ordenadores, un marco de trabajo de software es una abstracción en la que el software que proporciona una funcionalidad genérica puede ser cambiado selectivamente por código adicional escrito por el usuario, proporcionando así un software específico para la aplicación.

Proporciona una forma estándar de construir y desplegar aplicaciones y es un entorno de software universal y reutilizable que proporciona una funcionalidad particular como parte de una plataforma de software más amplia para facilitar el desarrollo de aplicaciones, productos y soluciones de software.»

Hay mucho que desgranar ahí, pero si has trabajado con ambos, probablemente ya puedas ver que, generalmente, una librería de código se utiliza para resolver un problema específico o añadir una característica concreta a tu programa.

Un framework, por otro lado, te proporciona algo mucho más genérico y reutilizable. Si sigues leyendo la entrada de la Wikipedia, te darás cuenta de que hay tres cosas que separan un framework de una librería.

Inversión de control

Las bibliotecas se conectan a tu código, Tu código se conecta a un framework.

La primera gran diferencia entre un framework y una librería es quién tiene el control del proceso de desarrollo.

Con una librería de código, un desarrollador generalmente recurre a la librería cuando lo considera oportuno. Un framework generalmente requiere que el desarrollador esté totalmente inmerso en su flujo de trabajo.

Como resultado, a menudo se siente como si el framework estuviera en control del proceso de desarrollo en lugar del desarrollador. ¡Esto es inversión de control! Esto se simplifica comúnmente como alguna variación de lo siguiente:

  • Biblioteca: Llámanos para hacer el trabajo.
  • Framework: Tú no nos llamas, nosotros te llamamos a ti.
  • Es por esta inversión de control que los frameworks son mucho más opinables y también por lo que son capaces de hacer tanto por los desarrolladores.

    Opinables para los que se preguntan significa que los frameworks están tomando un montón de decisiones con respecto a cómo se escribe el código, la ubicación de los archivos, y posiblemente incluso el nombre de dichos archivos.

    Making these assumptions allows for the usage of the paradigm of convention over configuration which allows developers to skip the process of app configuration in exchange for following certain conventions (such as putting certain files in certain folders, etc.).

    Ruby on Rails is a popular framework for developing web applications.

    Look at a framework like Ruby on Rails. It is often considered highly opinionated. Cuando creas un nuevo proyecto con Ruby on Rails, generará numerosas carpetas y archivos con un montón de código preescrito.

    La mayor parte del trabajo del desarrollador se hará probablemente en la carpeta de la aplicación (esta es la ubicación de las subcarpetas de modelos, vistas y controladores) pero hay un montón de otro código en ese proyecto Rails que está diseñado para hacer funcionar tu aplicación.

    Además, Ruby on Rails tiene un flujo de trabajo específico que espera que sigas. Cuando creas un modelo User en Rails, asume que está ligado a un UsersController.

    Rails quiere que esos archivos se llamen de una forma determinada (user.rb para el modelo y users_controller.rb para el controlador) y los quiere en sus respectivas carpetas.

    Desviarse del flujo de trabajo de Rails te dejará frustrado por cómo y por qué tu código no funciona. Work with it and everything just seems to magically work.

    A large part of that magic (some do refer to it as Rails magic) is just all of that pre-written code working in the background. You fill in the models, views, controllers, and draw some routes, and Rails will take care of linking everything up correctly.

    ChartJS lets you make some really beautiful charts.

    Compare this to Chart.js which is a JavaScript library for creating really beautiful charts.

    Tú eliges cuándo y dónde llamar a Chart.js y si bien es cierto que se te pide que rellenes campos al hacer un nuevo gráfico (querrás especificar el tipo de gráfico, las etiquetas, los colores, etc.) no controla tu flujo de trabajo.

    Chart.js sólo se preocupa de la información necesaria para dibujar un gráfico; no podría importarle menos el resto de tu código.

    Extensibilidad

    Un concepto importante en la programación orientada a objetos es el principio abierto-cerrado. El principio abierto-cerrado establece que el comportamiento del código debe estar abierto a ser alterado/extendido sin que tenga que ser cambiado directamente.

    Un ejemplo sencillo de esto es la herencia en las clases que permite a una subclase añadir funcionalidad y características necesarias para ella sin tener que cambiar directamente el código en la clase padre.

    La extensibilidad permite a un desarrollador añadir nuevas características a un framework o adaptar el comportamiento de las características existentes para satisfacer sus necesidades sin modificar el código fuente.

    Los buenos frameworks se construyen con la extensibilidad en mente. Proporcionan la funcionalidad genérica necesaria para desarrollar una aplicación genérica pero se dejan abiertos a adiciones y cambios específicos necesarios para una aplicación concreta.

    Si un framework no fuera extensible, estaría bastante limitado en su funcionalidad y esto lo haría mucho menos atractivo para aprender.

    Siguiendo con los ejemplos anteriores, hay varias extensiones para el framework Ruby on Rails para añadir características adicionales como la autenticación de usuarios.

    Si Rails careciera de estas extensiones, dificultaría mucho lo que se podría hacer usándolo. Para ser justos, Chart.js también tiene muchos plugins y extensiones. Estos permiten cosas como dibujar tipos adicionales de gráficos.

    La diferencia aquí es mucho menos visible, sin embargo, debido a que los frameworks proporcionan una funcionalidad general, deben ser construidos con extensibilidad en mente para que las características específicas de la aplicación puedan ser implementadas.

    Una biblioteca no necesariamente tiene que ser construida con extensibilidad en mente, su propósito principal es llevar a cabo una tarea específica.

    Código no modificable

    Este concepto es, afortunadamente, mucho más fácil y simple de explicar. La respuesta corta y simple es que los frameworks generarán un montón de código y, en su mayor parte, no se toca ese código.

    Volviendo a Rails como se ha explicado antes, generalmente, un desarrollador pasa la mayor parte de su tiempo trabajando en la carpeta de la aplicación. El desarrollador generalmente no cambiará o borrará el código pre-escrito.

Deja un comentario