Librairies vs Frameworks – Quelle est la différence ?

La page Wikipedia d’une bibliothèque de code la définit comme suit :

« En informatique, une bibliothèque est une collection de ressources non volatiles utilisées par des programmes informatiques, souvent pour le développement de logiciels. Il peut s’agir de données de configuration, de documentation, de données d’aide, de modèles de messages, de code et de sous-programmes pré-écrits, de classes, de valeurs ou de spécifications de type. »

Comparé à la définition d’un framework:

« En programmation informatique, un framework logiciel est une abstraction dans laquelle un logiciel fournissant des fonctionnalités génériques peut être modifié de manière sélective par du code supplémentaire écrit par l’utilisateur, fournissant ainsi un logiciel spécifique à l’application.

Il fournit un moyen standard de construire et de déployer des applications et constitue un environnement logiciel universel et réutilisable qui fournit une fonctionnalité particulière dans le cadre d’une plateforme logicielle plus large pour faciliter le développement d’applications, de produits et de solutions logicielles. »

Il y a là beaucoup à décortiquer mais si vous avez travaillé avec les deux, vous pouvez probablement déjà voir que, généralement, une bibliothèque de code est utilisée pour résoudre un problème spécifique ou ajouter une fonctionnalité spécifique à votre programme.

Un framework, en revanche, vous fournit quelque chose de beaucoup plus générique et réutilisable. Si vous continuez à lire l’entrée Wikipedia, vous remarquerez que trois éléments séparent un framework d’une bibliothèque.

Inversion de contrôle

Les bibliothèques se branchent sur votre code, Votre code se branche sur un framework.

La première grande différence entre un framework et une bibliothèque est de savoir qui contrôle le processus de développement.

Avec une bibliothèque de code, un développeur fait généralement appel à la bibliothèque quand il le juge approprié. Un framework exige généralement que le développeur soit totalement immergé dans son flux de travail.

En conséquence, on a souvent l’impression que c’est le framework qui contrôle le processus de développement plutôt que le développeur. Il s’agit d’une inversion du contrôle ! Cette situation est communément simplifiée comme une variation de ce qui suit :

  • Bibliothèque : Appelez-nous pour que le travail soit fait.
  • Framework : Vous ne nous appelez pas, nous vous appellerons.

C’est à cause de cette inversion du contrôle que les frameworks sont beaucoup plus opinionnés et aussi pourquoi ils sont capables de faire autant pour les développeurs.

Opinionnés pour ceux qui se posent la question signifie que les frameworks prennent beaucoup de décisions concernant la façon dont le code est écrit, l’emplacement des fichiers, et peut-être même le nom desdits fichiers.

Making these assumptions allows for the usage of the paradigm of convention over configuration which allows developers to skip the process of app configuration in exchange for following certain conventions (such as putting certain files in certain folders, etc.).

Ruby on Rails is a popular framework for developing web applications.

Look at a framework like Ruby on Rails. It is often considered highly opinionated. Lorsque vous créez un nouveau projet avec Ruby on Rails, il va générer de nombreux dossiers et fichiers avec beaucoup de code pré-écrit.

La majeure partie du travail du développeur sera probablement effectuée dans le dossier app (c’est l’emplacement des sous-dossiers des modèles, vues, contrôleurs) mais il y a beaucoup d’autre code dans ce projet Rails qui est conçu pour faire fonctionner votre application.

De plus, Ruby on Rails a un workflow spécifique qu’il s’attend à ce que vous suiviez. Lorsque vous créez un modèle User dans Rails, il suppose qu’il est lié à un UsersController.

Rails veut que ces fichiers soient nommés d’une certaine manière (user.rb pour le modèle et users_controller.rb pour le contrôleur) et les veut dans leurs dossiers respectifs.

S’écarter du flux de travail de Rails vous laissera frustré de savoir comment et pourquoi votre code ne fonctionne pas. Work with it and everything just seems to magically work.

A large part of that magic (some do refer to it as Rails magic) is just all of that pre-written code working in the background. You fill in the models, views, controllers, and draw some routes, and Rails will take care of linking everything up correctly.

ChartJS lets you make some really beautiful charts.

Compare this to Chart.js which is a JavaScript library for creating really beautiful charts.

Vous choisissez quand et où appeler Chart.js et s’il est vrai que vous devez remplir des champs lorsque vous créez un nouveau graphique (vous voudrez spécifier le type de graphique, les étiquettes, les couleurs, etc.), cela ne contrôle pas votre flux de travail.

Chart.js ne se soucie que des informations nécessaires pour dessiner un graphique ; il pourrait moins se soucier du reste de votre code.

Extensibilité

Un concept important dans la programmation orientée objet est le principe ouvert-fermé. Le principe ouvert-fermé stipule que le comportement du code doit être ouvert à la modification/extension sans qu’il soit nécessaire de le modifier directement.

Un exemple simple de cela est l’héritage dans les classes qui permet à une sous-classe d’ajouter les fonctionnalités et les caractéristiques qui lui sont nécessaires sans jamais avoir besoin de modifier directement le code de la classe mère.

L’extensibilité permet à un développeur d’ajouter de nouvelles fonctionnalités à un framework ou d’adapter le comportement des fonctionnalités existantes à ses besoins sans modifier le code source.

Les bons frameworks sont construits avec l’extensibilité en tête. Ils fournissent les fonctionnalités génériques nécessaires au développement d’une application générique mais se laissent ouverts aux ajouts et modifications spécifiques nécessaires à une application spécifique.

Si un framework n’était pas extensible, il serait plutôt limité dans ses fonctionnalités et cela le rendrait beaucoup moins attrayant à apprendre.

Pour rester dans les exemples ci-dessus, il existe plusieurs extensions pour le framework Ruby on Rails afin d’ajouter des fonctionnalités supplémentaires telles que l’authentification des utilisateurs.

Si Rails n’avait pas ces extensions, cela entraverait fortement ce que vous pourriez faire en l’utilisant. Pour être juste, Chart.js dispose également de nombreux plugins et extensions. Ceux-ci permettent des choses comme dessiner des types supplémentaires de graphiques.

La différence ici est beaucoup moins visible, cependant, parce que les frameworks fournissent des fonctionnalités générales, ils devraient être construits avec l’extensibilité à l’esprit afin que les fonctionnalités spécifiques à l’app puissent être mises en œuvre.

Une bibliothèque n’a pas nécessairement besoin d’être construite avec l’extensibilité à l’esprit, son objectif principal est d’accomplir une tâche spécifique.

Code non modifiable

Ce concept est heureusement beaucoup plus facile et plus simple à expliquer. La réponse courte et simple est que les frameworks vont générer un tas de code et que, pour la plupart, vous ne touchez pas à ce code.

Pour en revenir à Rails comme expliqué précédemment, généralement, un développeur passe la plupart de son temps à travailler sur le dossier de l’application. Le développeur ne modifiera généralement pas ou ne supprimera pas le code pré-écrit.

C’est le cas.

Laisser un commentaire