Llamamos biblioteca a Alamofire y framework a SwiftUI. Pero ¿no son ambos “usar código creado por otra persona”? ¿Cuál es la diferencia?
Es habitual oír que “un framework es más grande”, pero el tamaño no es lo esencial. Hay frameworks pequeños y bibliotecas enormes.
Quién llama a quién.
Este único criterio conecta de forma natural con el importante concepto de inversión de control (IoC). También aparece al estudiar la inyección de dependencias, así que entenderlo bien aquí resulta útil.
Este es el resumen clave.
- Biblioteca: conjunto de herramientas que mi código llama cuando las necesita. El control está en mis manos
- Framework: estructura que controla el flujo y llama a mi código. El control está en el framework
- Esta dirección de llamada invertida se denomina inversión de control
- Principio de Hollywood: “No nos llames; nosotros te llamaremos”
Biblioteca: la herramienta que yo llamo
Una biblioteca es un conjunto de código que implementa por adelantado una funcionalidad concreta. Mi código decide por completo cuándo y en qué orden utilizarla.
// Mi código controla el flujo
let json = try JSONDecoder().decode(User.self, from: data)
let hash = SHA256.hash(data: input)Yo diseño el inicio, el final y el flujo general del programa, y voy utilizando las herramientas que necesito. Es como sacar un destornillador de una caja de herramientas. El destornillador no decide el orden del trabajo.
Alamofire y Kingfisher pertenecen a esta categoría. Yo decido cuándo enviar solicitudes de red y cuándo cargar imágenes.
Framework: la estructura que me llama
Un framework es una estructura que ya define la arquitectura general y el flujo de ejecución de la aplicación. Yo completo con código los lugares que deja preparados.
En una app de iOS se ve claramente. UIKit y SwiftUI controlan el punto de entrada, el bucle de eventos y el ciclo de vida de las pantallas. Lo que escribo, como viewDidLoad, body y onAppear, es código que el framework llama en momentos determinados.
struct ProfileView: View {
var body: some View { // Yo no lo llamo.
Text("Hello") // SwiftUILo llama cuando hace falta
}
}Nunca llamo a body manualmente. SwiftUI decide cuándo y cuántas veces se llama. El control del flujo ha cambiado de manos.
La inversión de control y el principio de Hollywood
Esta relación invertida tiene un nombre: inversión de control (IoC).
En un programa procedural habitual, mi código controla el flujo y llama al código externo. En un programa basado en frameworks, el framework controla el flujo y mi código recibe llamadas en los puntos que he registrado. El control ha pasado en la dirección contraria; de ahí lo de “inversión”.
La forma ingeniosa de expresar esto es el principio de Hollywood.
“No nos llames; nosotros te llamaremos.” — No llames; nosotros nos pondremos en contacto contigo.
Un actor que hace una audición no llama repetidamente a la productora. Si consigue el papel, la productora se pone en contacto con él. Esa es exactamente la relación entre un framework y mi código.
El patrón delegado sigue el mismo principio. Al implementar UITableViewDataSource, ¿llamo yo a cellForRowAt? No. La vista de tabla me llama cuando lo necesita. La sintaxis del mundo de los frameworks está presente por todo el código.
Entonces, ¿qué cambia en la práctica?
La forma de aprender es distinta. Con una biblioteca, basta con buscar “qué funcionalidades ofrece”; con un framework, primero hay que aprender “cuándo me llama” (el ciclo de vida y las convenciones de llamada). Por eso estudiar UIKit empieza por el ciclo de vida.
El coste de sustitución es distinto. Una biblioteca se puede cambiar modificando los puntos de llamada, pero, como todo el código se apoya en la estructura del framework, sustituirlo equivale prácticamente a reescribirlo. Por eso pasar de UIKit a SwiftUI no consiste en cambiar unas pocas funciones.
La estrategia de pruebas es distinta. Es difícil ejecutar de forma independiente el código que llama el framework. Por eso se repite el consejo de separar la lógica en una capa independiente del framework (Swift puro).
En una frase para una entrevista
“Una biblioteca es una herramienta que llama mi código, mientras que un framework es una estructura que controla el flujo y llama a mi código. Esta diferencia en la dirección del control se denomina inversión de control.”
Las preguntas de seguimiento suelen ser “da un ejemplo de IoC” (métodos del ciclo de vida, delegados) y después “¿por qué es útil?” (estandariza el flujo y permite al desarrollador centrarse en la lógica de negocio).
Resumen
- El criterio de distinción es la dirección de llamada, no el tamaño
- Biblioteca: herramienta que mi código llama cuando la necesita. El control está en mis manos
- Framework: estructura que controla el flujo y llama a mi código en momentos definidos. El control está en el framework
- Este control invertido es la inversión de control (IoC), también llamada principio de Hollywood
- viewDidLoad, body y los métodos delegados son código al que se llama
- Diferencias prácticas: primero se aprende el ciclo de vida del framework, sustituirlo es difícil y separar la lógica es clave para las pruebas