Framework vs. Toolkit vs. Library

¿Cuál es la diferencia entre un Framework, un Toolkit y una Library?

La diferencia más importante, y de hecho la diferencia que define entre una biblioteca y un marco es Inversion of Control .

¿Qué significa esto? Bueno, significa que cuando llamas a una biblioteca, tienes el control. Pero con un marco, el control se invierte: el marco te llama. (Esto se llama Principio de Hollywood: no nos llame, lo llamaremos). Esta es prácticamente la definición de un marco. Si no tiene Inversión de control, no es un marco. (¡Te estoy mirando, .NET!)

Básicamente, todo el flujo de control ya está en el marco, y solo hay un montón de puntos blancos predefinidos que puede completar con su código.

Una biblioteca, por otro lado, es una colección de funcionalidades a las que puede llamar.

No sé si el término conjunto de herramientas está realmente bien definido. Simplemente la palabra “kit” parece sugerir algún tipo de modularidad, es decir, un conjunto de bibliotecas independientes entre las que puede elegir. Entonces, ¿qué hace que un conjunto de herramientas sea diferente de un conjunto de bibliotecas independientes? Integración: si solo tiene un grupo de bibliotecas independientes, no hay garantía de que funcionen bien juntas, mientras que las bibliotecas de un conjunto de herramientas se diseñaron para funcionar bien juntas; simplemente no tiene que usarlas todas .

Pero esa es solo mi interpretación del término. A diferencia de la biblioteca y el marco, que están bien definidos, no creo que haya una definición ampliamente aceptada de conjunto de herramientas .

Martin Fowler analiza la diferencia entre una biblioteca y un marco en su artículo sobre Inversión de control :

La inversión del control es una parte clave de lo que hace que un marco sea diferente a una biblioteca. Una biblioteca es esencialmente un conjunto de funciones que usted puede llamar , en estos días generalmente organizadas en clases. Cada llamada hace algo de trabajo y devuelve el control al cliente.

Un marco incorpora algún diseño abstracto, con más comportamiento incorporado. Para usarlo, debe insertar su comportamiento en varios lugares del marco, ya sea mediante subclases o conectando sus propias clases. El código del marco luego llama a su código en estos puntos .

Para resumir: su código llama a una biblioteca, pero un marco llama a su código.

Introducción

Hay varios términos relacionados con las colecciones de código relacionado, que tienen tanto implicaciones históricas (anteriores a 1994/5 a los fines de esta respuesta) como actuales, y el lector debe conocer ambas, particularmente al leer textos clásicos sobre computación / progtwigción de la era histórica.

Biblioteca

Históricamente, y actualmente, una biblioteca es una colección de código relacionado con una tarea específica, o un conjunto de tareas estrechamente relacionadas que operan en aproximadamente el mismo nivel de abstracción. En general, carece de cualquier propósito o intención propia, y está destinado a ser utilizado (consumido) e integrado con el código del cliente para ayudar al código del cliente a ejecutar sus tareas.

Kit de herramientas

Históricamente, un juego de herramientas es una biblioteca más enfocada, con un propósito definido y específico. Actualmente, este término ha caído en desuso, y se usa casi exclusivamente (según el conocimiento de este autor) para widgets gráficos y componentes de GUI en la era actual. Un juego de herramientas generalmente funcionará en una capa más alta de abstracción que una biblioteca, y con frecuencia consumirá y usará las bibliotecas. A diferencia de las bibliotecas, el código del kit de herramientas a menudo se utilizará para ejecutar la tarea del código del cliente, como crear una ventana, cambiar el tamaño de una ventana, etc. Los niveles más bajos de abstracción dentro de un juego de herramientas son fijos o pueden ser operados por el cliente codificar de una manera proscrita (Piensa en el estilo de ventana, que puede ser reparado o que el código del cliente puede modificar de antemano).

Marco de referencia

Históricamente, un marco era un conjunto de bibliotecas y módulos interrelacionados que se separaban en categorías ‘General’ o ‘Específica’. Los marcos generales estaban destinados a ofrecer una plataforma completa e integrada para la construcción de aplicaciones, ofreciendo funcionalidad general, como la gestión de memoria multiplataforma, abstracciones de subprocesos múltiples, estructuras dinámicas (y estructuras genéricas en general). Los marcos generales históricos (sin dependency injection, ver a continuación) han sido reemplazados casi universalmente por ofertas de lenguaje empaquetado con plantillas polimórficas (parametrizadas) en lenguajes OO, como el STL para C ++, o en librerías empaquetadas para lenguajes no OO (cabeceras Solaris C garantizadas ) Los marcos generales operaban en diferentes niveles de abstracción, pero de nivel universalmente bajo, y al igual que las bibliotecas, confiaban en el código del cliente para llevar a cabo sus tareas específicas con su ayuda.

Los marcos “específicos” se desarrollaron históricamente para tareas únicas (pero a menudo extensas), como sistemas de “Comando y Control” para sistemas industriales, y stacks de redes tempranas, y funcionaban con un alto nivel de abstracción y se usaban kits de herramientas similares para llevar a cabo la ejecución de las tareas de los códigos del cliente.

En la actualidad, la definición de un marco se ha enfocado más y ha adoptado el principio de “Inversión de control” como se menciona en otro lugar como principio rector, por lo que el flujo de progtwigs y la ejecución se llevan a cabo por el marco. Sin embargo, los marcos todavía se dirigen hacia un resultado específico; una aplicación para un SO específico, por ejemplo (MFC para MS Windows, por ejemplo), o para un trabajo más general (por ejemplo, Spring framework).

SDK: “Kit de desarrollo de software”

Un SDK es una colección de herramientas para ayudar al progtwigdor a crear e implementar código / contenido que se dirige específicamente a ejecutar en una plataforma muy particular o de una manera muy particular. Un SDK puede consistir simplemente en un conjunto de bibliotecas que deben ser utilizadas de forma específica solo por el código del cliente y que pueden comstackrse normalmente, hasta un conjunto de herramientas binarias que crean o adaptan activos binarios para producir su (SDK’s ) salida.

Motor

Un motor (en términos de recostackción de códigos) es un binario que ejecutará contenido personalizado o procesará datos de entrada de alguna manera. Los motores de juegos y gráficos son quizás los usuarios más destacados de este término, y se usan casi universalmente con un SDK para apuntar al motor, como el UDK (Unreal Development Kit), pero también existen otros motores, como los motores de búsqueda y RDBMS. .

Con frecuencia, aunque no siempre, un motor permite que solo algunos de sus internos sean accesibles para sus clientes. La mayoría de las veces se dirige a una architecture diferente, cambia la presentación de la salida del motor o con fines de ajuste. Los motores de código abierto son, por definición, abiertos a los clientes para cambiarlos y modificarlos según sea necesario, y algunos motores de propiedad se fijan por completo. Sin embargo, los motores más utilizados en el mundo son, casi con seguridad, los motores Javascript. Integrado en cada navegador en todas partes, hay una gran cantidad de motores JavaScript que tomarán javascript como entrada, lo procesarán y luego lo mostrarán.

API: “Interfaz de progtwigción de aplicaciones”

El último término que respondo es un error personal mío: API, se utilizó históricamente para describir la interfaz externa de una aplicación o entorno que, en sí misma, era capaz de funcionar de forma independiente, o al menos de realizar sus tareas sin la intervención necesaria del cliente. después de la ejecución inicial. Aplicaciones tales como bases de datos, procesadores de textos y sistemas de Windows expondrían un conjunto fijo de ganchos u objetos internos a la interfaz externa que un cliente podría llamar / modificar / usar, etc. para llevar a cabo las capacidades que la aplicación original podría llevar a cabo. Las API variaron entre la cantidad de funcionalidad disponible a través de la API y, también, la cantidad de la aplicación principal que fue (re) utilizada por el código del cliente. (Por ejemplo, una API de procesamiento de textos puede requerir que la aplicación completa se cargue en segundo plano cuando se ejecuta cada instancia del código del cliente, o quizás solo una de sus bibliotecas vinculadas, mientras que un sistema de ventanas en ejecución crearía objetos internos para ser administrados por él mismo y devuelve los identificadores al código del cliente para ser utilizado en su lugar.

Actualmente, el término API tiene un rango mucho más amplio, y se usa a menudo para describir casi cualquier otro término dentro de esta respuesta. De hecho, la definición más común aplicada a este término es que una API ofrece una interfaz externa contraída a otra pieza de software (código de cliente a la API). En la práctica, esto significa que una API depende del idioma y tiene una implementación concreta proporcionada por una de las colecciones de códigos anteriores, como una biblioteca, un conjunto de herramientas o un marco. Para ver un área específica, protocolos, por ejemplo, una API es diferente a un protocolo que es un término más genérico que representa un conjunto de reglas, sin embargo, una implementación individual de un protocolo / conjunto de protocolos específico que expone una interfaz externa a otro software lo más a menudo se llamaría una API.

Observación

Como se señaló anteriormente, las definiciones históricas y actuales de los términos anteriores han cambiado, y esto se puede ver como merced a los avances en la comprensión científica de los principios y paradigmas informáticos subyacentes, y también a la aparición de patrones particulares de software. En particular, la GUI y los sistemas de ventanas de principios de los noventa ayudaron a definir muchos de estos términos, pero desde la hibridación efectiva del kernel OS y el sistema de ventanas para sistemas operativos cunsumer masivos (quizás Bar Linux), y la adopción masiva de dependency injection / inversión del control como un mecanismo para consumir bibliotecas y marcos, estos términos han tenido que cambiar sus respectivos significados.


PD (Un año después)

Después de pensar cuidadosamente sobre este tema durante más de un año, rechazo el principio IoC como la diferencia que define entre un marco y una biblioteca. Hay un gran número de autores populares que dicen que sí, pero hay un número casi igual de personas que dicen que no lo es. Simplemente hay demasiados ‘Frameworks’ por ahí que NO usan IoC para decir que es el principio definitorio. Una búsqueda de marcos de control integrados o micro revela una gran plétora que NO utiliza IoC y ahora creo que el lenguaje .Net y CLR es un descendiente aceptable del marco “general”. Decir que la IoC es la característica definitoria es simplemente demasiado rígida para aceptarla, me da miedo, y rechaza cualquier cosa que se presente como un marco que concuerde con la representación histórica mencionada anteriormente.

Para detalles de frameworks que no son IoC, vea, como se mencionó anteriormente, muchos frameworks incrustados y micro, así como también cualquier framework histórico en un lenguaje que no provea callback a través del lenguaje (OK. Las devoluciones de llamadas pueden ser pirateadas para cualquier dispositivo con un sistema de registro, pero no por el progtwigdor promedio), y obviamente, el framework .net.

La respuesta proporcionada por Menzani y Barrass es probablemente la más completa. Sin embargo, la explicación podría establecerse más claramente. La mayoría de las personas omite el hecho de que estos son conceptos nesteds. Así que déjame explicarlo por ti.

Al escribir el código:

  • finalmente descubrirá secciones de código que está repitiendo en su progtwig, por lo que las refactorizará en Funciones / Métodos .
  • finalmente, después de haber escrito algunos progtwigs, se encuentra copiando funciones que ya ha realizado en nuevos progtwigs. Para ahorrarse tiempo, reúne esas funciones en Bibliotecas .
  • con el tiempo, te encuentras creando el mismo tipo de interfaces de usuario cada vez que haces uso de ciertas bibliotecas. Así que refactoriza su trabajo y crea un Toolkit que le permite crear sus UI más fácilmente a partir de llamadas a métodos generics.
  • eventualmente, ha escrito tantas aplicaciones que usan los mismos kits de herramientas y bibliotecas que crea un Framework que tiene una versión genérica de este código repetitivo ya provisto, así que todo lo que necesita hacer es diseñar el aspecto de la interfaz de usuario y manejar los eventos que resultado de la interacción del usuario.

En términos generales, esto explica completamente las diferencias entre los términos.

Diagtwig

Si eres un aprendiz más visual, aquí hay un diagtwig que lo hace más claro:

(Créditos: http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks )

Una biblioteca es simplemente una colección de métodos / funciones envueltos en un paquete que puede importarse en un proyecto de código y reutilizarse.

Un marco es una biblioteca sólida o una colección de bibliotecas que proporciona una “base” para su código. Un marco sigue el patrón de Inversión de control. Por ejemplo, .NET Framework es una gran colección de bibliotecas cohesivas en las que construye su aplicación además de. Puede argumentar que no hay una gran diferencia entre un marco y una biblioteca, pero cuando la gente dice “marco”, normalmente implica un conjunto de bibliotecas más grande y más sólido que formará parte integral de una aplicación.

Pienso en un juego de herramientas de la misma manera que pienso en un SDK. Viene con documentación, ejemplos, bibliotecas, envoltorios, etc. Nuevamente, puede decir que esto es lo mismo que un marco y que probablemente sea correcto hacerlo.

Casi todos se pueden usar indistintamente.

muy, muy similar, un marco suele ser un poco más desarrollado y completo que una biblioteca, y un conjunto de herramientas puede ser simplemente una colección de bibliotecas y marcos similares.

una muy buena pregunta que puede ser incluso la más leve de naturaleza subjetiva, pero creo que es la mejor respuesta que podría dar.

Biblioteca

Creo que es unánime que una biblioteca tenga código codificado que pueda usar para no tener que volver a codificarlo. El código debe estar organizado de una manera que le permita buscar la funcionalidad que desea y usarla desde su propio código.

La mayoría de los lenguajes de progtwigción incluyen bibliotecas estándar, especialmente algunos códigos que implementan algún tipo de colección. Esto siempre es por conveniencia de que usted no tiene que codificar estas cosas usted mismo. De manera similar, la mayoría de los lenguajes de progtwigción tienen construcciones que le permiten buscar funcionalidades desde bibliotecas, con cosas como enlaces dynamics, espacios de nombres, etc.

Así que el código que a menudo se necesita volver a utilizar es un gran código para colocar dentro de una biblioteca.

Kit de herramientas

Un conjunto de herramientas usadas para un propósito particular. Esto es unánime La pregunta es, qué se considera una herramienta y qué no. Yo diría que no hay una definición fija, depende del contexto de lo que se llama un conjunto de herramientas. Ejemplo de herramientas podrían ser bibliotecas, widgets, scripts, progtwigs, editores, documentación, servidores, depuradores, etc.

Otra cosa a tener en cuenta es el “propósito particular”. Esto siempre es cierto, pero el scope del propósito puede cambiar fácilmente en función de quién creó el kit de herramientas. Por lo tanto, puede ser fácilmente un juego de herramientas de progtwigdor, o puede ser un juego de herramientas de análisis sintáctico de cadenas. Uno es tan amplio que podría tener una herramienta tocando todo lo relacionado con la progtwigción, mientras que el otro es más preciso.

Los SDK generalmente son kits de herramientas, ya que intentan agrupar un conjunto de herramientas (a menudo de tipo múltiple) en un solo paquete.

Creo que el hilo común es que una herramienta hace algo por ti, ya sea completamente, o te ayuda a hacerlo. Y un conjunto de herramientas es simplemente un conjunto de herramientas que todas realizan o ayudan a realizar un conjunto particular de actividades.

Marco de referencia

Los marcos no están tan definidos por unanimidad. Parece ser un término general para cualquier cosa que pueda enmarcar tu código. Lo que significaría: cualquier estructura que subyace o respalde su código.

Esto implica que construyes tu código contra un marco, mientras que construyes una biblioteca contra tu código.

Pero, parece que a veces el Word Framework se usa en el mismo sentido que toolkit o incluso library. .Net Framework es principalmente un juego de herramientas, porque está compuesto por la FCL, que es una biblioteca, y la CLR, que es una máquina virtual. Entonces lo consideraría un conjunto de herramientas para el desarrollo de C # en Windows. Mono es un conjunto de herramientas para el desarrollo de C # en Linux. Sin embargo, lo llamaron un marco. Tiene sentido pensarlo de esta manera también, ya que este tipo de marco de su código, pero un marco debe ser más compatible y mantener las cosas juntas, luego hacer cualquier tipo de trabajo, por lo que mi opinión es que esta no es la forma en que debe usar el palabra.

Y creo que la industria está tratando de pasar a tener framework significando un progtwig ya escrito con piezas faltantes que debe proporcionar o personalizar. Lo cual creo que es algo bueno, ya que el kit de herramientas y la biblioteca son excelentes términos precisos para otros usos del “marco”.

Es un poco subjetivo, creo. El kit de herramientas es el más fácil. Es solo un montón de métodos, clases que pueden ser usadas.
La biblioteca frente a la pregunta marco, hago la diferencia por el camino para usarlos. Leí en alguna parte la respuesta perfecta hace mucho tiempo. El marco llama a su código, pero por otro lado su código llama a la biblioteca.

Marco: instalado en su máquina y que le permite interactuar con él. sin el marco no puede enviar comandos de progtwigción a su máquina

Biblioteca: tiene como objective resolver un determinado problema (o varios problemas relacionados con la misma categoría)

Toolkit: una colección de muchos códigos que pueden resolver múltiples problemas en múltiples problemas (como una caja de herramientas)

En relación con la respuesta correcta de Mittag:

un simple ejemplo. Digamos que implementa la interfaz ISerializable (.Net) en una de sus clases. Ustedes usan las cualidades de framework de .Net entonces, en lugar de las cualidades de la biblioteca. Rellenas los “puntos blancos” (como decía mittag) y tienes el esqueleto completo. Debe saber de antemano cómo el marco va a “reactjsr” con su código. En realidad .net ES un marco, y aquí es donde estoy en desacuerdo con la opinión de Mittag.

La respuesta completa y completa a su pregunta se brinda con mucha lucidez en el Capítulo 19 (el capítulo completo dedicado a este tema) de este libro , que por cierto es un libro muy bueno (no del todo “solo para Smalltalk”).

Otros han notado que .net puede ser tanto un marco como una biblioteca y un conjunto de herramientas, dependiendo de la parte que use, pero quizás un ejemplo lo ayude. Entity Framework para tratar con bases de datos es una parte de .net que usa el patrón de inversión de control. Déjelo saber sus modelos que se da cuenta de qué hacer con ellos. Como progtwigdor, requiere que comprenda “la mente del marco” o, más realistamente, la mente del diseñador y lo que harán con sus aportaciones. el lector de datos y las llamadas relacionadas, por otro lado, son simplemente una herramienta para obtener o poner datos en y desde la tabla / vista y ponerlos a su disposición. Nunca entendería cómo tomar una relación padre-hijo y traducirla de objeto a relacional, usaría múltiples herramientas para hacer eso. Pero tendría mucho más control sobre cómo se almacenaron esos datos, cuándo, transacciones, etc.