Cadre vs Toolkit vs Bibliothèque
Quelle est la différence entre un framework, une boîte à outils et une bibliothèque?
La différence la plus importante, et en fait la différence définissant entre une bibliothèque et un framework, est Inversion of Control .
Qu'est-ce que ça veut dire? Cela signifie que lorsque vous appelez une bibliothèque, , vous êtes en contrôle. Mais avec un framework, le contrôle est inversé: le framework vous appelle. (Ceci s'appelle le principe d'Hollywood: ne nous appelez pas, nous vous appellerons.) C'est à peu près la définition d'un framework. S'il ne dispose pas d'Inversion of Control, ce n'est pas un framework. (Je te regarde, .NET!)
En gros, tout le flux de contrôle est déjà dans la structure et il n’ya que quelques points blancs prédéfinis que vous pouvez remplir avec votre code.
Une bibliothèque, par contre, est un ensemble de fonctionnalités que vous pouvez appeler .
Je ne sais pas si le terme boîte à outils est vraiment bien défini. Le mot "kit" semble suggérer une certaine modularité, c’est-à-dire un ensemble de bibliothèques indépendantes parmi lesquelles vous pourrez choisir. Qu'est-ce qui différencie une boîte à outils d'un groupe de bibliothèques indépendantes? Intégration: si vous avez juste un groupe de bibliothèques indépendantes, rien ne garantit qu’elles fonctionneront bien ensemble, alors que les bibliothèques d’une boîte à outils ont été conçues pour bien fonctionner ensemble - vous n’êtes pas obligé d’utiliser tous d'entre eux.
Mais ce n'est vraiment que mon interprétation du terme. Contrairement à library et framework, qui sont bien définis, je ne pense pas que soit une définition largement acceptée de toolkit .
Martin Fowler discute de la différence entre une bibliothèque et un framework dans son article sur Inversion of Control :
L'inversion de contrôle est un élément clé de Qu'est-ce qui rend un cadre différent d'un bibliothèque. Une bibliothèque est essentiellement un ensemble de fonctions que vous pouvez appeler, ces journées sont généralement organisées en Des classes. Chaque appel fait du travail et renvoie le contrôle au client.
Un cadre incarne un résumé design, avec plus de comportement intégré dans . Pour l'utiliser, vous devez insérer votre comportement dans divers endroits en le cadre soit par sous-classement ou en branchant vos propres cours. Le Le code de framework appelle ensuite votre code à ces points.
Pour résumer: votre code appelle une bibliothèque mais un framework appelle votre code.
Introduction
Il existe divers termes relatifs aux collections de codes associés, qui ont à la fois des implications historiques (antérieures à 1994/5) et actuelles, et le lecteur doit en prendre connaissance, en particulier lors de la lecture de textes classiques sur l'informatique/la programmation. de l'ère historique.
Bibliothèque
A la fois 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. En général, il manque d'objet ou d'intention et est destiné à être utilisé par (consommé) et intégré au code client pour aider le code client à 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 graphique à l'époque actuelle. La boîte à outils fonctionnera le plus souvent avec une couche d’abstraction supérieure à celle d’une bibliothèque, et consommera et utilisera souvent les bibliothèques elle-même. Contrairement aux bibliothèques, le code de la boîte à outils est souvent utilisé pour exécuter la tâche du code client, telle que la construction d'une fenêtre, le redimensionnement d'une fenêtre, etc. Les niveaux inférieurs d'abstraction dans une boîte à outils sont soit fixes, soit peuvent être utilisés par le client. code de manière proscrite. (Style Think Window, qui peut être corrigé ou qui peut être modifié à l’avance par le code client.)
Cadre
Historiquement, un framework était une suite de bibliothèques et de modules interdépendants, séparés en catégories «générale» ou «spécifique». Les cadres généraux visaient à offrir une plate-forme complète et intégrée pour la construction d’applications en offrant des fonctionnalités générales, telles que la gestion de la mémoire multiplate-forme, les abstractions multi-threading, les structures dynamiques (et les structures génériques en général). Les cadres généraux historiques (sans injection de dépendance, voir ci-dessous) ont été presque universellement remplacés par des offres de langage empaquetées polymorphes basées sur un modèle (paramétrées) dans des langages OO, telles que STL pour C++, ou dans des bibliothèques empaquetées pour des langages non OO ( en-têtes Solaris C garantis). Les frameworks généraux opéraient à différentes couches d'abstraction, mais à un niveau universellement bas, et comme les bibliothèques, le logiciel client effectuait ses tâches avec son aide.
Des cadres spécifiques ont été développés historiquement pour des tâches simples (mais souvent tentaculaires), tels que des systèmes de "commande et de contrôle" pour systèmes industriels, et des piles de réseaux précoces, et fonctionnaient à un niveau d'abstraction élevé. Des outils similaires ont été utilisés pour l'exécution. des tâches de codes clients.
Actuellement, la définition d'un cadre est devenue plus focalisée et prise en compte sur le principe "d'inversion de contrôle" mentionné précédemment comme principe directeur, de sorte que le déroulement du programme, ainsi que l'exécution, est effectué par le cadre. Cependant, les cadres sont toujours orientés vers un résultat spécifique; une application pour un système d'exploitation spécifique par exemple (MFC pour MS Windows par exemple) ou 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 permettant au programmeur de créer et de déployer du code/contenu qui est très spécifiquement destiné à être exécuté sur une plate-forme très particulière ou de manière très particulière. Un SDK peut consister simplement en un ensemble de bibliothèques qui ne doivent être utilisées que de manière spécifique 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 en produire un (le SDK). ) sortie.
Moteur
Un moteur (en termes de collection de code) est un binaire qui exécutera le contenu sur mesure ou traitera les données d'entrée d'une manière ou d'une autre. Les moteurs de jeu et graphiques sont peut-être les utilisateurs les plus importants de ce terme et sont presque universellement utilisés avec un SDK pour cibler le moteur lui-même, tel que le kit de développement Unreal (UDK), mais d'autres moteurs existent également, tels que les moteurs de recherche et les moteurs de SGBDR. .
Un moteur ne permet souvent, mais pas toujours, que quelques-uns de ses composants internes soient accessibles à ses clients. Le plus souvent, vous pouvez cibler une architecture différente, modifier la présentation de la sortie du moteur ou procéder à des réglages. Les moteurs Open Source sont par définition ouverts aux clients qui peuvent en changer et les modifier selon leurs besoins, et certains moteurs propriétaires sont complètement réparés. Cependant, les moteurs les plus utilisés dans le monde sont presque certainement des moteurs Javascript. Intégrés dans tous les navigateurs, il existe une multitude de moteurs JavaScript qui prennent le javascript en entrée, le traitent, puis le rendent au rendu.API: "Interface de programmation d'application".
Le dernier terme auquel je réponds est un de mes ennemis personnels: API, a été utilisé historiquement pour décrire l'interface externe d'une application ou d'un environnement qui, lui-même, était capable de fonctionner de manière indépendante, ou du moins de mener à bien ses tâches sans aucune intervention du client. après l'exécution initiale. Des applications telles que des bases de données, des traitements de texte et des systèmes Windows exposeraient à l'interface externe un ensemble fixe de crochets internes ou d'objets internes qu'un client pourrait ensuite appeler/modifier/utiliser, etc. pour exécuter les fonctionnalités que l'application d'origine pouvait exécuter. Les API variaient entre le nombre de fonctionnalités disponibles via l'API et la quantité d'utilisation de l'application principale (ré) utilisée par le code client. (Par exemple, une API de traitement de texte peut nécessiter que l'application complète soit chargée en arrière-plan lorsque chaque instance du code client est exécutée, ou peut-être simplement 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 à gérer par lui-même et renvoyer les poignées au code client à utiliser à la place.
Actuellement, le terme API a une gamme 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 sous contrat à un autre logiciel (Code client de l'API). Dans la pratique, cela signifie qu'une API dépend du langage et dispose d'une implémentation concrète fournie par l'une des collections de codes ci-dessus, telle qu'une bibliothèque, une boîte à outils ou un cadre. Pour examiner une zone 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, mais une implémentation individuelle d’un protocole/d’une suite de protocoles spécifique qui expose une interface externe. d’autres logiciels s’appellerait le plus souvent d’une API.
Remarque.
Comme indiqué ci-dessus, les définitions historiques et actuelles des termes ci-dessus ont changé, ce qui peut être perçu comme une avancée scientifique dans la compréhension des principes et paradigmes informatiques sous-jacents, ainsi que dans l'émergence de modèles de logiciels particuliers. En particulier, les systèmes d'interface utilisateur graphique et de Windowing du début des années 90 ont permis de définir nombre de ces termes, mais depuis l'hybridation efficace des systèmes d'exploitation OS Kernel et Windowing pour les systèmes d'exploitation grand public (sauf peut-être Linux), et l'adoption massive de l'injection de dépendance/inversion du contrôle en tant que mécanisme de consommation de bibliothèques et de frameworks, ces termes ont dû changer leurs significations respectives.
.
P.S. (Un an plus tard)
Après avoir réfléchi à ce sujet pendant plus d'un an, je rejette le principe d'IoC en tant que différence fondamentale entre un framework et une bibliothèque. Il y a un grand nombre d'auteurs populaires qui disent que c'est le cas, mais un nombre presque égal de personnes qui disent que ce n'est pas le cas. Il y a tout simplement trop de «cadres» qui n'utilisent PAS IoC pour dire que c'est le principe qui définit. Une recherche de cadres de contrôleurs intégrés ou de micro-contrôleurs révèle toute une pléthore qui n'utilise PAS l'IoC et je crois maintenant que le langage .Net et le CLR sont des descendants acceptables du cadre "général". Dire que l'IoC est la caractéristique qui la définit est tout simplement trop rigide pour que je l'accepte, je le crains, 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 intégrés et micro, ainsi que tout framework historique dans un langage qui ne fournit pas de rappel par le langage (OK. Les rappels peuvent être piratés pour tout périphérique doté d'une interface moderne. système d’enregistrement, mais pas par le programmeur moyen), et évidemment, le framework .net.
For details of non-IoC frameworks, see, as mentioned above, many embedded and micro frameworks, as well as any historical framework in a language that does not provide callback through the language (OK. Callbacks can be hacked for any device with a modern register system, but not by the average programmer), and obviously, the .net framework.
Diagramme
Si vous êtes un apprenant plus visuel, voici un diagramme qui le rend plus clair:
(Crédits: http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks )
La réponse fournie par Menzani et Barrass } est probablement la plus complète. Cependant, l'explication pourrait facilement être énoncée plus clairement. La plupart des gens manquent le fait que ce sont tous des concepts imbriqués. Alors laissez-moi vous le présenter.
Lors de l'écriture du code:
- vous finissez par découvrir des sections de code que vous répétez dans votre programme, vous devez donc les reformater dans Fonctions/Méthodes.
- finalement, après avoir écrit quelques programmes, vous vous retrouvez à copier des fonctions que vous avez déjà créées dans de nouveaux programmes. Pour gagner du temps, regroupez ces fonctions dans Libraries.
- vous finissez par créer le même type d’interfaces utilisateur chaque fois que vous utilisez certaines bibliothèques. Vous refactorisez donc votre travail et créez un Toolkit qui vous permet de créer plus facilement vos interfaces utilisateur à partir d'appels de méthodes génériques.
- vous avez finalement écrit tant d'applications utilisant les mêmes boîtes à outils et bibliothèques que vous avez créé un Framework contenant déjà une version générique de ce code passe-partout; gérer les événements résultant de l'interaction de l'utilisateur.
De manière générale, cela explique complètement les différences entre les termes.
Une bibliothèque est simplement un ensemble de méthodes/fonctions regroupées dans un package pouvant être importé dans un projet de code et réutilisé.
Un framework est une bibliothèque ou une collection de bibliothèques robuste qui fournit une "fondation" pour votre code. Un cadre suit le modèle Inversion of Control. Par exemple, le framework .NET est une vaste collection de bibliothèques cohérentes dans laquelle vous construisez votre application par-dessus. Vous pouvez affirmer qu'il n'y a pas une grande différence entre un framework et une bibliothèque, mais quand les gens parlent de "framework", cela implique généralement une suite de bibliothèques plus grande et plus robuste qui fera partie intégrante d'une application.
Je pense à une boîte à outils de la même façon que je pense à un SDK. Il est livré avec de la documentation, des exemples, des bibliothèques, des wrappers, etc. Encore une fois, vous pouvez dire que ceci est identique à un framework et vous auriez probablement raison de le faire.
Ils peuvent presque tous être utilisés de manière interchangeable.
très, très similaire, un framework est généralement un peu plus développé et complet qu’une bibliothèque, et une boîte à outils peut simplement être une collection de bibliothèques et de frameworks similaires.
c'est une très bonne question qui est peut-être même la moindre part de nature subjective, mais je pense que c'est à peu près la meilleure réponse que je puisse donner.
Bibliothèque
Je pense qu'il est unanime qu'une bibliothèque possède déjà un code que vous pouvez utiliser pour ne pas avoir à la coder à nouveau. Le code doit être organisé de manière à vous permettre de rechercher la fonctionnalité souhaitée et de l’utiliser à partir de votre propre code.
La plupart des langages de programmation sont livrés avec des bibliothèques standard, notamment du code qui implémente une sorte de collection. C'est toujours pour la commodité que vous n'avez pas à coder ces choses vous-même. De même, la plupart des langages de programmation ont été conçus pour vous permettre de rechercher des fonctionnalités dans des bibliothèques, avec des éléments tels que les liens dynamiques, les espaces de noms, etc.
Ainsi, le code qui doit souvent être réutilisé est un excellent code à insérer dans une bibliothèque.
Boîte à outils
Un ensemble d'outils utilisés dans un but particulier. C'est unanime. La question est de savoir ce qui est considéré comme un outil et ce qui ne l’est pas. Je dirais qu'il n'y a pas de définition fixe, cela dépend du contexte de la chose qui s'appelle une boîte à outils. Des exemples d’outils peuvent être des bibliothèques, des widgets, des scripts, des programmes, des éditeurs, de la documentation, des serveurs, des débogueurs, etc.
Une autre chose à noter est le "but particulier". Cela est toujours vrai, mais la portée de l'objectif peut facilement changer en fonction de la personne qui a créé la boîte à outils. Il peut donc s'agir facilement d'un toolkit pour programmeur ou d'un toolkit d'analyse de chaînes. L’un est tellement large qu’il pourrait avoir un outil touchant à tout ce qui concerne la programmation, tandis que l’autre est plus précis.
Les SDK sont généralement des boîtes à outils, dans la mesure où ils essaient de regrouper un ensemble d’outils (souvent de plusieurs types) dans un seul package.
Je pense que le fil conducteur est qu'un outil fait quelque chose pour vous, complètement ou qu'il vous aide à le faire. Et une boîte à outils est simplement un ensemble d'outils qui exécutent tous ou vous aident à effectuer un ensemble d'activités particulier.
Cadre
Les cadres ne sont pas définis aussi unanimement. Cela semble être un terme générique pour tout ce qui peut encadrer votre code. Ce qui voudrait dire: toute structure qui sous-tend ou supporte votre code.
Cela implique que vous construisez votre code sur un framework, alors que vous construisez une bibliothèque sur votre code.
Mais, il semble que parfois le framework Word soit utilisé dans le même sens que le toolkit ou même la bibliothèque. Le .NET Framework est principalement une boîte à outils, car il est composé du FCL qui est une bibliothèque et du CLR, qui est une machine virtuelle. Vous considéreriez donc cela comme une boîte à outils pour le développement C # sous Windows. Mono étant une boîte à outils pour le développement C # sous Linux. Pourtant, ils ont appelé cela un cadre. Il est logique de penser de cette façon aussi, car cela encadre en quelque sorte votre code, mais un cadre devrait davantage soutenir et lier les choses, puis faire tout type de travail, donc j’estime que ce n’est pas ainsi que vous devriez utiliser le Mot.
Et je pense que l’industrie essaie de passer à un cadre qui signifie un programme déjà écrit avec des pièces manquantes que vous devez fournir ou personnaliser. Ce qui, à mon avis, est une bonne chose, car toolkit et library sont d'excellents termes précis pour d'autres utilisations du "framework".
Framework: installé sur votre machine et vous permettant d’interagir avec elle. sans le cadre, vous ne pouvez pas envoyer de commandes de programmation à votre machine
Bibliothèque: vise à résoudre un certain problème (ou plusieurs problèmes liés à la même catégorie)
Boîte à outils: une collection de nombreux morceaux de code pouvant résoudre plusieurs problèmes sur plusieurs problèmes (comme une boîte à outils)
Je pense que c'est un peu subjectif. La boîte à outils est la plus simple. C'est juste un tas de méthodes, de classes qui peuvent être utilisées.
La bibliothèque par rapport à la question cadre, je fais la différence en les utilisant. J'ai lu quelque part la réponse parfaite il y a longtemps. Le framework appelle votre code, mais d'autre part votre code appelle la bibliothèque.
D'autres ont noté que .net peut être à la fois un cadre, une bibliothèque et une boîte à outils, en fonction de la partie utilisée, mais peut-être qu'un exemple est utile. Entity Framework pour gérer les bases de données est une partie de .net qui utilise l'inversion du modèle de contrôle. Vous lui indiquez que vos modèles déterminent quoi en faire. En tant que programmeur, vous devez comprendre "l'esprit du framework", ou de manière plus réaliste l'esprit du concepteur et ce qu'il va faire de vos entrées. D'autre part, datareader et les appels associés ne sont qu'un outil permettant d'obtenir ou de placer des données dans une table ou une vue et de les mettre à votre disposition. Il ne comprendrait jamais comment prendre une relation parent-enfant et la traduire d'objet en relationnel, vous utiliseriez plusieurs outils pour le faire. Mais vous auriez beaucoup plus de contrôle sur la manière dont ces données ont été stockées, quand, les transactions, etc.
En relation avec la réponse correcte de Mittag:
un exemple simple. Supposons que vous implémentiez l'interface ISerializable (.Net) dans l'une de vos classes. Vous utilisez alors le cadre qualités de .Net, plutôt que ses qualités de bibliothèque. Vous remplissez les "taches blanches" (comme le dit Mittag) et vous avez terminé le squelette. Vous devez savoir à l'avance comment le framework va "réagir" avec votre code. En fait, .net IS est un cadre, et c’est là que je ne partage pas l’opinion de Mittag.
Le réponse complète, complète à votre question est présenté très clairement au chapitre 19 (tout le chapitre consacré à ce thème) de ce livre , qui est un très bon livre au fait (pas du tout "juste pour Smalltalk").