331 votes

Cadre, boîte à outils et bibliothèque

Quelle est la différence entre un cadre, une boîte à outils et une bibliothèque ?

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.

490voto

Jörg W Mittag Points 153275

La différence la plus importante, et en fait la définir différence entre une bibliothèque et un cadre est Inversion du contrôle .

Qu'est-ce que cela signifie ? Eh bien, cela signifie que lorsque vous appelez une bibliothèque, vous ont le contrôle. Mais avec un cadre, le contrôle est inversé : le cadre vous appelle. (C'est ce qu'on appelle le principe d'Hollywood : ne nous appelez pas, nous vous appellerons). S'il n'y a pas d'inversion de contrôle, ce n'est pas un cadre. (Je vous regarde, .NET !)

En fait, tout le flux de contrôle est déjà dans le cadre, et il y a juste un tas de zones blanches prédéfinies que vous pouvez remplir avec votre code.

D'autre part, une bibliothèque est une collection de fonctionnalités qui vous peut appeler.

Je ne sais pas si le terme toolkit est vraiment bien défini. Le simple mot "kit" semble suggérer une sorte de modularité, c'est-à-dire un ensemble de bibliothèques indépendantes parmi lesquelles vous pouvez choisir. Qu'est-ce qui différencie donc une boîte à outils d'un simple ensemble de bibliothèques indépendantes ? Intégration : si vous disposez d'un ensemble de bibliothèques indépendantes, il n'y a aucune garantie qu'elles fonctionneront bien ensemble, alors que les bibliothèques d'une boîte à outils ont été conçues pour fonctionner bien ensemble - vous n'avez simplement pas besoin d'utiliser les outils de la boîte à outils. todos d'entre eux.

Mais ce n'est que mon interprétation du terme. Contrairement à bibliothèque et cadre, qui sont bien défini, je ne pense pas qu'il y ait est une définition largement acceptée de boîte à outils .

3 votes

C'est probablement incorrect. Les frameworks peuvent, mais ne doivent pas, effectuer une inversion de contrôle. Que dites-vous des frameworks CSS ? Un framework fait silencieusement beaucoup de choses pour vous sans que vous le demandiez. C'est la raison pour laquelle ils ne peuvent pas être composés avec un autre framework du même type (si vous composez 2 frameworks CSS, préparez-vous à des surprises). L'une des choses qu'ils peuvent faire sans que vous le demandiez est de s'approprier le flux de contrôle d'une application. Je pense que la réponse de @Sridhar-Sarnobat est probablement meilleure.

0 votes

Pour une référence solide, la section 1.6 de l'ouvrage Modèles de conception Le GdF définit une boîte à outils como classe c'est-à-dire l'équivalent orienté objet d'une sous-routine bibliothèque : Souvent, une application intègre des classes provenant d'une ou plusieurs bibliothèques de classes prédéfinies appelées les boîtes à outils. Une boîte à outils est un ensemble de classes connexes et réutilisables conçues pour fournir une fonctionnalité utile et générale. Un exemple de boîte à outils est un ensemble de classes de collection pour les listes, les tableaux associatifs, les piles, etc. La bibliothèque de flux d'E/S C++ en est un autre exemple.

1 votes

Les boîtes à outils n'imposent pas une conception particulière à votre application ; elles fournissent simplement des fonctionnalités qui peuvent aider votre application à faire son travail. Elles vous permettent, en tant qu'implémenteur, d'éviter de recoder des fonctionnalités communes. Les boîtes à outils mettent l'accent sur la réutilisation du code. Ils sont l'équivalent orienté objet des bibliothèques de sous-routines".

131voto

Pascal Thivent Points 295221

Martin Fowler discute de la différence entre une bibliothèque et un framework dans son article sur Inversion du contrôle :

L'inversion du contrôle est un élément clé de ce qui différencie un framework d'une bibliothèque. Une bibliothèque est essentiellement un ensemble de fonctions que vous pouvez appeler , Ces jours-ci, ils sont généralement organisés en classes. Chaque appel effectue un travail et rend le contrôle au client.

Un cadre incarne une certaine abstraction abstraite, avec un comportement plus intégré. Pour l'utiliser, vous devez insérer votre comportement à différents endroits dans le cadre soit par sous-classement ou en ajoutant vos propres classes. Le site Le code du framework appelle alors votre code à ces endroits .

En résumé, votre code appelle une bibliothèque, mais un framework appelle votre code.

72voto

KimberleyBarrass Points 101

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.

0 votes

À la lumière de votre mise à jour, avez-vous une distinction affinée ? Ou sous-entendez-vous que le "framework" est juste une vague dépendance qui fait des choses pour vous ? Je suppose qu'en tant que développeur d'applications, on n'a pas à s'inquiéter du vocabulaire des programmeurs embarqués.

0 votes

Pouvez-vous préciser/élaborer ce que vous entendez par "interface externe" dans votre explication de l'API ?

0 votes

Je pense qu'une meilleure façon de démystifier l'argument IoC est de demander "est-ce qu'une bibliothèque ou une boîte à outils peut aussi prendre le contrôle du consommateur ?". Je pense que la réponse est catégoriquement oui.

13voto

Jordan Parmer Points 12286

Une bibliothèque est simplement une collection de méthodes/fonctions regroupées dans un package qui peut être importé dans un projet de code et réutilisé.

Un framework est une bibliothèque robuste ou une collection de bibliothèques qui fournit une "fondation" pour votre code. Un framework suit le modèle d'inversion de contrôle. Par exemple, le framework .NET est une grande collection de bibliothèques cohésives sur lesquelles vous construisez votre application. On peut dire qu'il n'y a pas une grande différence entre un framework et une bibliothèque, mais quand on dit "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 manière que je pense à un SDK. Elle s'accompagne de documentation, d'exemples, de bibliothèques, de wrappers, etc. Là encore, vous pouvez dire que c'est la même chose qu'un framework et vous auriez probablement raison de le faire.

Ils peuvent presque tous être utilisés de manière interchangeable.

5voto

Jake Kalstad Points 1379

Très, très similaires, 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 un peu subjective par nature, mais je crois que c'est à peu près la meilleure réponse que je puisse donner.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X