Introduction
Il existe plusieurs termes relatifs aux collections de codes connexes, qui ont des implications à la fois historiques (avant 1994/5 aux fins de cette réponse) et actuelles, et le lecteur doit être conscient des deux, en particulier lorsqu'il lit des textes classiques sur l'informatique/la programmation de l'ère historique.
Bibliothèque
Historiquement et actuellement, une bibliothèque est une collection de code relative à une tâche spécifique, ou à un ensemble de tâches étroitement liées qui fonctionnent à peu près au même niveau d'abstraction. Elle n'a généralement pas d'objectif ou d'intention propre et est destinée à être utilisée par le code client (consommée) et intégrée à celui-ci pour l'aider à exécuter ses tâches.
Boîte à outils
Historiquement, une boîte à outils est une bibliothèque plus ciblée, avec un objectif défini et spécifique. Actuellement, ce terme est tombé en désuétude, et est utilisé presque exclusivement (à la connaissance de cet auteur) pour les widgets graphiques et les composants d'interface utilisateur graphique à l'époque actuelle. Une boîte à outils fonctionne le plus souvent à un niveau d'abstraction supérieur à celui d'une bibliothèque, et consomme et utilise souvent elle-même des bibliothèques. Contrairement aux bibliothèques, le code de la boîte à outils sera souvent utilisé pour exécuter la tâche du code client, comme la construction d'une fenêtre, le redimensionnement d'une fenêtre, etc. Les niveaux d'abstraction inférieurs au sein d'une boîte à outils sont soit fixes, soit peuvent eux-mêmes être exploités par le code client d'une manière proscrite. (Pensez au style de la fenêtre, qui peut soit être fixé, soit être modifié à l'avance par le code client).
Cadre de travail
Historiquement, un cadre était une suite de bibliothèques et de modules liés entre eux et séparés en catégories "générales" ou "spécifiques". Les frameworks généraux étaient destinés à offrir une plate-forme complète et intégrée pour la création d'applications en proposant des fonctionnalités générales, telles que la gestion de la mémoire multiplateforme, les abstractions multithreading, les structures dynamiques (et les structures génériques en général). Les cadres généraux historiques (sans injection de dépendances, voir ci-dessous) ont presque universellement été remplacés par des offres de langages packagés polymorphes (paramétrés) dans les langages OO, tels que la STL pour C++, ou dans des bibliothèques packagées pour les langages non-OO (en-têtes C garantis de Solaris). Les cadres généraux fonctionnaient à différents niveaux d'abstraction, mais universellement à bas niveau, et comme les bibliothèques, ils reposaient sur le code client qui effectuait ses tâches spécifiques avec leur aide.
Les cadres "spécifiques" ont été historiquement développés pour des tâches uniques (mais souvent tentaculaires), comme les systèmes de "commande et de contrôle" pour les systèmes industriels, et les premières piles de réseaux, et ont fonctionné à un haut niveau d'abstraction et comme des boîtes à outils ont été utilisées pour effectuer l'exécution des tâches des codes clients.
Actuellement, la définition d'un framework est devenue plus ciblée et a adopté le principe d'"inversion de contrôle", comme mentionné ailleurs, comme principe directeur, de sorte que le flux de programme, ainsi que l'exécution, est effectué par le framework. Les frameworks restent cependant ciblés soit vers un résultat spécifique ; une application pour un OS spécifique par exemple (MFC pour MS Windows par exemple), soit pour un travail plus général (framework Spring par exemple).
SDK : "Kit de développement logiciel"
Un kit de développement logiciel (SDK) est un ensemble d'outils destinés à aider le programmeur à créer et à déployer du code/contenu qui est très spécifiquement destiné à fonctionner sur une plate-forme très particulière ou d'une manière très particulière. Un SDK peut consister simplement en un ensemble de bibliothèques qui doivent être utilisées d'une manière spécifique uniquement par le code client et qui peuvent être compilées normalement, jusqu'à un ensemble d'outils binaires qui créent ou adaptent des actifs binaires pour produire son résultat (celui du SDK).
Moteur
Un moteur (en termes de collection de codes) est un binaire qui exécute un contenu sur mesure ou traite des données d'entrée d'une manière ou d'une autre. Les moteurs de jeux et de graphiques sont peut-être les plus répandus, et sont presque universellement utilisés avec un SDK pour cibler le moteur lui-même, comme l'UDK (Unreal Development Kit), mais d'autres moteurs existent également, comme les moteurs de recherche et les moteurs de SGBDR.
Un moteur permettra souvent, mais pas toujours, que seuls quelques éléments internes soient accessibles à ses clients. Le plus souvent, il s'agit de cibler une architecture différente, de modifier la présentation de la sortie du moteur ou d'effectuer des réglages. Les moteurs Open Source sont par définition ouverts aux clients qui peuvent les changer et les modifier selon leurs besoins, et certains moteurs propriétaires sont complètement figés. Cependant, les moteurs les plus utilisés dans le monde sont presque certainement les moteurs JavaScript. Intégrés dans tous les navigateurs du monde, il existe toute une série de moteurs JavaScript qui prennent JavaScript en entrée, le traitent, puis le restituent.
API : "Interface de programmation d'applications".
Le dernier terme auquel je réponds est un de mes problèmes personnels : API, était historiquement utilisé pour décrire l'interface externe d'une application ou d'un environnement qui, lui-même, était capable de fonctionner de manière autonome, ou du moins d'effectuer ses tâches sans aucune intervention nécessaire du client après l'exécution initiale. Les applications telles que les bases de données, les traitements de texte et les systèmes Windows exposaient à l'interface externe un ensemble fixe de crochets ou d'objets internes qu'un client pouvait ensuite appeler/modifier/utiliser, etc. pour réaliser des tâches que l'application originale pouvait réaliser. Les API variaient en fonction de la quantité de fonctionnalités disponibles par le biais de l'API, mais aussi de la quantité de l'application de base (ré)utilisée par le code client. (Par exemple, une API de traitement de texte peut exiger que l'application complète soit chargée en arrière-plan lors de l'exécution de chaque instance du code client, ou peut-être seulement l'une de ses bibliothèques liées ; alors qu'un système de fenêtrage en cours d'exécution créerait des objets internes qu'il gérerait lui-même et renverrait des poignées au code client pour qu'il les utilise à la place.
Actuellement, le terme API a une portée beaucoup plus large, et est souvent utilisé pour décrire presque tous les autres termes de cette réponse. En effet, la définition la plus courante appliquée à ce terme est qu'une API offre une interface externe contractuelle à un autre logiciel (code client vers l'API). En pratique, cela signifie qu'une API dépend du langage et qu'elle possède une mise en œuvre concrète fournie par l'une des collections de code mentionnées ci-dessus, comme une bibliothèque, une boîte à outils ou un cadre. Pour examiner un domaine spécifique, les protocoles, par exemple, une API est différente d'un protocole, qui est un terme plus générique représentant un ensemble de règles. Toutefois, une mise en œuvre individuelle d'un protocole ou d'une suite de protocoles spécifique qui expose une interface externe à d'autres logiciels serait le plus souvent appelée une API.
Remarque
Comme indiqué ci-dessus, les définitions historiques et actuelles des termes ci-dessus ont évolué, ce qui peut être considéré comme une conséquence des progrès de la compréhension scientifique des principes et paradigmes informatiques sous-jacents, ainsi que de l'émergence de modèles particuliers de logiciels. En particulier, les systèmes d'interface graphique et de fenêtrage du début des années 90 ont contribué à définir un grand nombre de ces termes, mais depuis l'hybridation effective du noyau du système d'exploitation et du système de fenêtrage pour les systèmes d'exploitation grand public (à l'exception peut-être de Linux), et l'adoption massive de l'injection de dépendances et de l'inversion de contrôle comme mécanisme de consommation des bibliothèques et des cadres, ces termes ont dû changer leurs significations respectives.
P.S. (Un an plus tard)
Après avoir mûrement réfléchi à ce sujet pendant plus d'un an, je rejette le principe IoC comme étant la différence déterminante entre un framework et une bibliothèque. Il y a un grand nombre d'auteurs populaires qui disent que c'est le cas, mais il y a un nombre presque égal de personnes qui disent que ce n'est pas le cas. Il y a tout simplement trop de "frameworks" qui n'utilisent pas IoC pour que l'on puisse dire que c'est le principe déterminant. Une recherche sur les frameworks d'applications embarquées ou de micro-contrôleurs révèle une pléthore de frameworks qui n'utilisent pas IoC et je pense maintenant que le langage .NET et le CLR sont un descendant acceptable du framework "général". Dire que IoC est la caractéristique déterminante est tout simplement trop rigide pour que je l'accepte, j'en ai peur, et rejette d'emblée tout ce qui se présente comme un cadre correspondant à la représentation historique mentionnée ci-dessus.
Pour plus de détails sur les frameworks non-IoC, voir, comme mentionné ci-dessus, de nombreux frameworks embarqués et micro, ainsi que tout framework historique dans un langage qui ne fournit pas de callback à travers le langage (OK. Les callbacks peuvent être piratés pour n'importe quel dispositif avec un système de registre moderne, mais pas par le programmeur moyen), et évidemment, le framework .NET.
20 votes
Impayable. @martijn-pieters marque cette question comme un doublon et ferme le doublon comme "trop large". Je ne suis pas arrivé sur cette page sans raison, les questions ont de la valeur. Je vais upvoter les deux par principe.
0 votes
Je l'ai fait ici, aussi. Oui, ce n'est que de la sémantique, mais les conversations sont plus faciles lorsque nous avons un bon vocabulaire cohérent.