terminology - mismo - ide vs framework
Framework vs. Toolkit vs. Library (12)
Esta pregunta ya tiene una respuesta aquí:
¿Cuál es la diferencia entre un marco, un kit de herramientas y una biblioteca?
Introducción
Existen varios términos relacionados con las colecciones de código relacionado, que tienen tanto las implicaciones históricas (anteriores a 1994/5 para esta respuesta) como las actuales, y el lector debe conocerlas, especialmente al leer textos clásicos sobre computación / programación. De la época histórica.
Biblioteca
Tanto históricamente, como en la actualidad, una biblioteca es una colección de código relacionada con una tarea específica, o un conjunto de tareas estrechamente relacionadas que operan aproximadamente en el mismo nivel de abstracción. Por lo 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.
Caja de herramientas
Históricamente, un kit 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 GUI en la era actual. Un kit de herramientas funcionará con mayor frecuencia en una capa más alta de abstracción que una biblioteca, y con frecuencia consumirá y usará las bibliotecas en sí. A diferencia de las bibliotecas, el código del kit de herramientas se usará a menudo para ejecutar la tarea del código del cliente, como construir una ventana, cambiar el tamaño de una ventana, etc. Los niveles más bajos de abstracción dentro de un kit de herramientas son fijos, o pueden ser operados por el cliente Código de manera proscrita. (El estilo Think Window, que puede ser fijo, o que puede ser modificado de antemano por el código del cliente).
Marco de referencia
Históricamente, un marco era un conjunto de bibliotecas y módulos interrelacionados que se separaban en las categorías "General" o "Específica". Los marcos generales estaban destinados a ofrecer una plataforma completa e integrada para crear aplicaciones al ofrecer una 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 inyección de dependencia, ver más abajo) han sido reemplazados casi universalmente por ofertas de lenguaje empaquetado con plantillas polimórficas (parametrizadas) en idiomas OO, como el STL para C ++, o en bibliotecas empaquetadas para idiomas que no son OO (cabeceras de Solaris C garantizadas ). Los marcos generales operaban en diferentes niveles de abstracción, pero de bajo nivel universal, y al igual que las bibliotecas, se basaban en el código del cliente para realizar sus tareas específicas con su ayuda.
Los marcos específicos se desarrollaron históricamente para tareas individuales (pero a menudo extensas), como los sistemas de "Comando y Control" para sistemas industriales y las primeras pilas de redes, y se operaron a un alto nivel de abstracción y se utilizaron kits de herramientas similares para llevar a cabo la ejecución de las tareas de códigos de clientes.
Actualmente, la definición de un marco se ha centrado más y se ha adoptado el principio de "Inversión de control" como se menciona en otros lugares como un principio rector, por lo que el marco lleva a cabo el flujo del programa y la ejecución. Sin embargo, los marcos aún están orientados hacia un producto específico; una aplicación para un sistema operativo específico por ejemplo (MFC para MS Windows por ejemplo), o para un trabajo de propósito más general (Spring Framework por ejemplo).
SDK: "Kit de desarrollo de software"
Un SDK es una colección de herramientas para ayudar al programador a crear e implementar código / contenido que está específicamente diseñado para ejecutarse en una plataforma muy particular o de una manera muy particular. Un SDK puede consistir simplemente en un conjunto de bibliotecas que deben usarse de una manera específica solo por el código del cliente y que se pueden compilar de manera normal, hasta un conjunto de herramientas binarias que crean o adaptan activos binarios para producirlo (los SDK ) salida.
Motor
Un motor (en términos de colección de códigos) es un binario que ejecutará contenido a medida o procesará datos de entrada de alguna manera. Los motores de juegos y gráficos son quizás los usuarios más avanzados de este término, y se usan casi universalmente con un SDK para apuntar al motor en sí, como el UDK (Unreal Development Kit), pero también existen otros motores, como los motores de búsqueda y RDBMS. .
Un motor a menudo, pero no siempre, permitirá que solo algunos de sus componentes internos sean accesibles para sus clientes. La mayoría de las veces para apuntar a una arquitectura diferente, cambiar la presentación de la salida del motor o para propósitos de ajuste. Los motores de código abierto están, por definición, abiertos a los clientes para que cambien y modifiquen según sea necesario, y algunos motores de propiedad están completamente arreglados. Sin embargo, los motores más utilizados en el mundo son, sin duda, motores Javascript. Integrado en todos los navegadores en todas partes, hay una gran cantidad de motores de JavaScript que toman javascript como entrada, lo procesan y luego se procesan.
API: "Interfaz de programación de aplicaciones"
El último término que estoy respondiendo es un error personal mío: la API se usó históricamente para describir la interfaz externa de una aplicación o entorno que, a su vez, era capaz de ejecutarse de forma independiente, o al menos de realizar sus tareas sin la intervención del cliente. después de la ejecución inicial. Las aplicaciones como las Bases de datos, los Procesadores de textos y los sistemas de Windows expondrían un conjunto fijo de ganchos u objetos internos a la interfaz externa que un cliente podría luego llamar / modificar / usar, etc. para llevar a cabo las capacidades que la aplicación original podría llevar a cabo. Las API variaron entre cuánta funcionalidad estaba disponible a través de la API, y también, cuánta de la aplicación central 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 ejecute cada instancia del código del cliente, o tal vez solo una de sus bibliotecas vinculadas; mientras que un sistema de ventanas en ejecución creará objetos internos que se administrarán por sí mismos y devuelva los identificadores al código de cliente que se utilizará 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 contratada 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 que se proporciona mediante una de las colecciones de códigos anteriores, como una biblioteca, un kit de herramientas o un marco. Para observar un área específica, los 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 específico / conjunto de protocolos 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 un avance en la comprensión científica de los principios y paradigmas de computación subyacentes, y también hasta la aparición de patrones particulares de software. En particular, los sistemas GUI y Windowing de principios de la década de los noventa ayudaron a definir muchos de estos términos, pero debido a la hibridación efectiva del sistema operativo Kernel y Windowing para sistemas operativos de consumo masivo (quizás Linux), y la adopción masiva de la inyección de dependencia / inversión de control como un mecanismo para consumir bibliotecas y marcos, estos términos han tenido que cambiar sus respectivos significados.
PS (un año después)
Después de pensar detenidamente sobre este tema durante más de un año, rechazo el principio de la IoC como la diferencia definitoria entre un marco y una biblioteca. Hay un gran número de autores populares que dicen que lo es, 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 integrados o de microcontroladores revela una plétora completa que NO utiliza IoC y ahora creo que el lenguaje .Net y CLR es un descendiente aceptable del marco "general". Decir que IoC es la característica definitoria es simplemente demasiado rígido para que acepte, me temo, y rechaza de antemano cualquier cosa que se presente como un marco que coincida con la representación histórica como se mencionó anteriormente.
Para obtener detalles de los marcos no IoC, vea, como se mencionó anteriormente, muchos marcos integrados y micro, así como cualquier marco histórico en un lenguaje que no proporciona devolución de llamada a través del lenguaje (OK. Las devoluciones de llamada se pueden piratear para cualquier dispositivo con un moderno sistema de registro, pero no por el programador promedio), y obviamente, el marco .net.
En relación con la respuesta correcta de Mittag:
Un ejemplo simple. Digamos que implementas la interfaz ISerializable (.Net) en una de tus clases. Usted hace uso de las cualidades del marco de .Net entonces, en lugar de las cualidades de la biblioteca. Rellenas los "puntos blancos" (como dice mittag) y tienes el esqueleto completado. Debe saber de antemano cómo el marco va a "reaccionar" con su código. En realidad .net es un marco, y aquí es donde no estoy de acuerdo con la opinión de Mittag.
La respuesta completa y completa a su pregunta se da de manera muy clara en el Capítulo 19 (el capítulo dedicado a este tema) de este libro , que es un libro muy bueno por cierto (en absoluto "solo para Smalltalk").
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 se pueden usar.
La biblioteca frente a la pregunta de la estructura que marca la diferencia por la forma de usarlos. Leí en algún lugar la respuesta perfecta hace mucho tiempo. El marco llama a su código, pero por otro lado su código llama a la biblioteca.
La respuesta proporcionada por Menzani y Barrass es probablemente la más completa. Sin embargo, la explicación podría explicarse más claramente. La mayoría de la gente no entiende el hecho de que todos estos conceptos están anidados. Así que déjame ponerlo para ti.
Al escribir el código:
- eventualmente descubres secciones de código que estás repitiendo en tu programa, así que refactorizas esas en Funciones / Métodos .
- finalmente, después de haber escrito algunos programas, te encuentras copiando funciones que ya has hecho en nuevos programas. Para ahorrar tiempo, puedes agrupar esas funciones en las bibliotecas .
- finalmente, se encontrará creando el mismo tipo de interfaces de usuario cada vez que haga uso de ciertas bibliotecas. Así que refactoriza su trabajo y crea un kit de herramientas que le permite crear sus interfaces de usuario más fácilmente a partir de llamadas a métodos genéricos.
- finalmente, has escrito tantas aplicaciones que utilizan los mismos kits de herramientas y bibliotecas que creas un Framework que tiene una versión genérica de este código de plantilla ya provisto, por lo que todo lo que necesitas 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.
La diferencia más importante, y de hecho, la diferencia definitoria entre una biblioteca y un marco es la Inversión de 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 el Principio de Hollywood: no nos llames, te 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 puedes llamar.
No sé si el término kit de herramientas está realmente bien definido. Solo 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 solo un grupo de bibliotecas independientes? Integración: si solo tiene un montón de bibliotecas independientes, no hay garantía de que funcionen bien juntas, mientras que las bibliotecas en un kit de herramientas han sido diseñadas para funcionar bien juntas, simplemente no tiene que usar todas .
Pero esa es realmente mi interpretación del término. A diferencia de la biblioteca y el marco, que están bien definidos, no creo que exista una definición ampliamente aceptada 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 de 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 a las que puedes llamar , en estos días generalmente organizadas en clases. Cada llamada hace algún trabajo y devuelve el control al cliente.
Un marco incorpora un diseño abstracto, con más comportamiento incorporado. Para usarlo, necesita 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.
Otros han señalado que .net puede ser tanto un marco como una biblioteca y un conjunto de herramientas según la parte que utilice, pero quizás un ejemplo sirva de ayuda. Entity Framework para tratar con bases de datos es una parte de .net que utiliza el patrón de inversión de control. Le dejas saber a tus modelos que averigua qué hacer con ellos. Como programador, requiere que usted entienda "la mente del marco", o más realista la mente del diseñador y lo que van a hacer con sus entradas. datareader 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 hacerlo. Pero tendría mucho más control sobre cómo se almacenaron esos datos, cuándo, transacciones, etc.
Una biblioteca es simplemente una colección de métodos / funciones envueltos en un paquete que se pueden importar a un proyecto de código y reutilizar.
Un marco es una biblioteca robusta 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 sobre. Se puede argumentar que no hay una gran diferencia entre un marco y una biblioteca, pero cuando la gente dice "marco", generalmente implica un conjunto de bibliotecas más grande y robusto que jugará una parte integral de una aplicación.
Pienso en un kit de herramientas de la misma manera que pienso en un SDK. Viene con documentación, ejemplos, bibliotecas, envoltorios, etc. Una vez más, puede decir que esto es lo mismo que un marco y que probablemente tenga razón al hacerlo.
Casi todos pueden ser usados indistintamente.
muy, muy similar, un marco suele estar 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 quizás sea la más subjetiva, pero creo que se trata de la mejor respuesta que podría dar.
Biblioteca
Creo que es unánime que una biblioteca tenga un código ya codificado que se puede usar para no tener que codificarlo nuevamente. El código debe estar organizado de manera que le permita buscar la funcionalidad que desea y utilizarlo desde su propio código.
La mayoría de los lenguajes de programación vienen con bibliotecas estándar, especialmente algunos códigos que implementan algún tipo de colección. Esto siempre es por la conveniencia de que usted no tiene que codificar estas cosas usted mismo. De manera similar, la mayoría de los lenguajes de programación tienen una estructura que le permite buscar la funcionalidad de las bibliotecas, con elementos como enlaces dinámicos, espacios de nombres, etc.
Por lo tanto, el código que se encuentra a menudo necesario para ser reutilizado es un gran código para colocar dentro de una biblioteca.
Caja de herramientas
Un conjunto de herramientas utilizadas para un propósito particular. Esto es unánime. La pregunta es, qué se considera una herramienta y qué no lo es. Yo diría que no hay una definición fija, depende del contexto de lo que se llama a sí mismo un conjunto de herramientas. Ejemplo de herramientas podrían ser bibliotecas, widgets, scripts, programas, editores, documentación, servidores, depuradores, etc.
Otra cosa a tener en cuenta es el "propósito particular". Esto siempre es cierto, pero el alcance del propósito puede cambiar fácilmente en función de quién hizo el kit de herramientas. Por lo tanto, puede ser fácilmente el conjunto de herramientas de un programador, o puede ser un conjunto de herramientas de análisis de cadenas. Uno es tan amplio, podría tener una herramienta que toque todo lo relacionado con la programación, mientras que el otro es más preciso.
Los SDK son generalmente 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 por completo, o te ayuda a hacerlo. Y un kit 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 un tanto general para cualquier cosa que pueda enmarcar su código. Lo que significaría: cualquier estructura que subyace o admita 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 la palabra marco se usa en el mismo sentido que el kit de herramientas o incluso la biblioteca. .Net Framework es principalmente un conjunto de herramientas, ya que está compuesto por la FCL, que es una biblioteca, y el CLR, que es una máquina virtual. Por lo tanto, 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. También tiene sentido pensar de esta manera, ya que encuadra tu código, pero un marco debería ser más compatible y mantener las cosas juntas, luego hacer cualquier tipo de trabajo, así que mi opinión es que esta no es la forma en que debes usar el palabra.
Y creo que la industria está tratando de pasar a tener un marco que signifique un programa ya escrito con piezas faltantes que debe proporcionar o personalizar. Lo que creo que es algo bueno, ya que el kit de herramientas y la biblioteca son términos muy precisos para otros usos de "framework".
Marco: instalado en su máquina y que le permite interactuar con él. sin el marco no puede enviar comandos de programación a su máquina
Biblioteca: tiene como objetivo resolver un problema determinado (o varios problemas relacionados con la misma categoría)
Kit de herramientas: una colección de muchas piezas de código que pueden resolver múltiples problemas en múltiples problemas (como una caja de herramientas)