Y a-t-il une différence entre un composant et un module
J'ai un petit problème avec les termes module et composant. Dans mon esprit, un module sont des classes groupées, qui ne sont accessibles que via une interface bien définie. Ils masquent tous les détails d'implémentation et sont réutilisables. Les modules définissent les modules dont ils dépendent.
Quelle est la différence avec les composants? Je l'ai cherché dans certains livres, mais la description des composants est très similaire.
Les termes sont similaires. Je pense généralement qu'un "module" est plus grand qu'un "composant". Un composant est une pièce unique, généralement de portée relativement petite, peut-être à usage général. Les exemples incluent les contrôles d'interface utilisateur et les "composants d'arrière-plan" tels que les minuteries, les assistants de filetage, etc. Un "module" est une plus grande partie de l'ensemble, généralement quelque chose qui remplit une fonction principale complexe sans interférence extérieure. Il peut s'agir de la bibliothèque de classes d'une application qui assure l'intégration avec le courrier électronique ou la base de données. Il peut être aussi volumineux qu'une seule application d'une suite, comme le "module Comptes clients" d'une plate-forme ERP/comptable.
Je pense aussi que les "modules" sont plus interchangeables. Les composants peuvent être répliqués, les nouveaux ressemblant aux anciens mais étant "meilleurs" d'une certaine manière, mais généralement la conception du système dépend plus strictement d'un composant (ou d'un remplacement conçu pour se conformer au comportement très spécifique de ce composant). En termes non informatiques, un "composant" peut être le bloc moteur d'une voiture; vous pouvez bricoler dans le moteur, même le remplacer entièrement, mais la voiture doit avoir un moteur, et il doit être conforme à des spécifications très rigides telles que les dimensions, le poids, les points de montage, etc. afin de remplacer le moteur "stock" que la voiture a été initialement conçu pour avoir. Un "module", d'autre part, implique une fonctionnalité de type "plug-in"; quel que soit ce module, il peut être communiqué de manière si légère que le module peut être retiré et/ou remplacé avec un effet minimal sur d'autres parties du système. Le système électrique d'une maison est hautement modulaire; vous pouvez brancher n'importe quoi avec une prise 120V15A dans n'importe quelle prise 120V15A et vous attendre à ce que la chose que vous branchez fonctionne. Le câblage de la maison se fiche de ce qui est branché, à condition que la puissance demandée dans une seule branche du système ne dépasse pas les limites de sécurité.
La signification générique de module est un groupe de code réutilisable, non lié à un programme spécifique. Cela pourrait être tout, d'un ensemble complet de bibliothèques GUI à une seule classe.
La signification générique de composant est un module avec la restriction supplémentaire de substituabilité à l'aide d'une interface spécifique. Si vous créez un composant Widget GUI, il peut être utilisé partout où un widget est attendu, sans avoir à faire quoi que ce soit de spécial dans le code appelant. Les modules en général n'ont pas une telle restriction. Qt et GTK + sont des modules, mais je ne peux pas échanger l'un contre l'autre sans un travail considérable dans le code qui l'appelle, donc ce ne sont pas des composants.
De nombreux frameworks ou langages de programmation utilisent les termes pour signifier quelque chose de beaucoup plus spécifique, c'est pourquoi les gens posent des questions sur le contexte. Quelque chose peut être un composant au sens générique, mais s'il n'implémente pas une interface IComponent très spécifique, il peut ne pas être considéré comme un composant dans son contexte. En python, module a la signification technique très spécifique de quelque chose que vous pouvez obtenir en utilisant une commande import. Habituellement, les gens se réfèrent à ces significations spécifiques au contexte.
Si nous devons faire abstraction de langages, de cadres et de leurs propres interprétations particuliers, la hiérarchie de granularité logicielle abstraite est la suivante:
Product - application, library, service
Module - GUI, core logic, data, etc...
Component - purpose specific collection of objects
Object - collection of primitives
Primitive - numbers, functions, etc...
- Produit
Clair et simple, le produit est une collection fonctionnelle de modules fonctionnels connectés.
- Module
Comme son nom l'indique, la motivation d'un module est la modularité. Contrairement à ce que beaucoup prétendent, cela n'implique pas vraiment la réutilisation du code. Il existe de nombreux modules qui ne sont pas vraiment réutilisables et ne correspondent à rien pour lequel ils n'ont pas été conçus.
Il est important de séparer les différentes couches logicielles, ce qui rend le logiciel beaucoup plus facile à implémenter et à maintenir, et si la nécessité de réimplémenter quelque chose comme un frontal à un cadre graphique différent, la modularité permet que cela se produise de manière simple et sûre, sans rupture code partout.
Un module encapsule une collection de composants qui servent tous un objectif commun tel que défini par les exigences du module. Un module doit être autonome et complet, et bien qu'il ne soit pas vraiment utilisable seul, il doit pouvoir fonctionner en conjonction avec n'importe quelle implémentation conforme.
- Composant
En termes de granularité, le composant se situe entre le module et l'objet. Le but d'un composant est de rassembler une collection d'objets à usage général pour former une unité spécifique à un but.
Comme son nom l'indique, contrairement au Module, le Composant n'est pas "autonome", il fait partie d'un ensemble fonctionnel plus large.
- Objet
Les objets sont les plus petits blocs de construction des composants. Les objets sont des collections de primitives et les couplent ensemble pour servir un niveau inférieur, plus universel tout en restant quelque peu spécifique.
- Primitif
Les primitives sont le plus petit, le plus simple et le plus bas niveau de granularité de développement logiciel. Il s'agit essentiellement de nombres entiers et réels et de fonctions/opérateurs, bien que la plupart des langues aient leurs propres "citoyens de première classe" supplémentaires.
Il y a très peu de choses que vous pouvez faire avec les primitives, et en même temps, c'est à un niveau si bas que vous pouvez pratiquement tout faire avec. C'est juste très, très verbeux, incroyablement compliqué et incroyablement fastidieux à accomplir tout en travaillant directement avec des primitives.
- Quel est l'intérêt de tout cela?
Comme déjà mentionné ci-dessus, travailler directement avec des primitives est une très mauvaise idée. Non seulement parce qu'il est incroyablement complexe, lent et fastidieux à faire pour le développement de logiciels modernes, mais il est également extrêmement gênant et gênant pour les tests et la maintenance.
L'intégration de toutes ces parties conceptuelles dans le développement logiciel le rend plus facile, plus rapide, plus simple et plus sûr. Vous ne faites pas une maison d'atomes, quelle que soit la polyvalence et l'universalité des atomes. Ce serait un exercice futile. Vos atomes sont vos primitifs, l'argile est votre objet, les briques sont vos composants, les murs, le sol et le toit sont vos modules, assemblés ensemble ils manifestent le produit final.
Les humains n'inventent vraiment rien, nous découvrons seulement des choses qui existent déjà dans l'univers, puis les copions et les appliquons à nos vies. La même hiérarchie de granularité est intrinsèque à l'univers lui-même, des atomes et même en dessous, aux molécules organiques, protéines, tissus, organes, organismes et au-dessus, la réalité elle-même obéit au même principe - combinant des choses abstraites petites, simples, à fonctions limitées et à des fins abstraites en des choses plus grandes, plus complexes, plus fonctionnelles et des choses plus spécifiques.
- Mises en garde terminologiques
Techniquement, ce sont tous des "objets", ce sont tous des "composants" du développement logiciel, ils sont tous suffisamment "modulaires" pour pouvoir s'emboîter, ce sont tous des "produits" au sens où ils ont été produits et ainsi de suite. ..
Il ne s'agit pas de terminologie ou de nomenclature, mais de la façon dont la mise à l'échelle des choses affecte divers aspects de la créativité et de la productivité. Et sur l'importance d'utiliser non seulement tous ces différents niveaux, mais aussi l'importance de ne pas essayer d'atteindre un objectif au mauvais niveau, ce qui ne peut être que contre-productif.
Cela dépend de votre contexte. Le module est déjà utilisé pour faire référence aux groupes de niveaux DLL dans certaines langues, semblables à "package" ou "Assembly" dans d'autres. Component est utilisé pour les choses COM ainsi que pour les composants Entity Based Component communs dans développement de jeu.
En termes architecturaux généraux, module et composant ont tous deux tendance à faire référence à un ensemble de code derrière une interface bien définie. En général, le module a tendance à se référer à des ensembles plus importants. Il y a souvent un ensemble d'interfaces et le module a tendance à être autonome.
Les composants, d'autre part, ont tendance à être des paquets de code plus petits, souvent plus petits qu'une classe complète. Par leur nom, ils ont tendance à faire partie de quelque chose de plus grand. Parfois, c'est l'application elle-même, mais avec l'utilisation croissante de la composition dans la conception de classes, cela signifie plus souvent un composant d'un objet plus grand. Les interfaces bien définies pour les composants ont également tendance à permettre à l'application d'échanger des composants les uns pour les autres. Les modules n'ont généralement pas cette capacité d'échange.