Composants : le jeu en vaut-il la chandelle ?

Le terme composant est si souvent galvaudé que d’aucuns ont du mal à  savoir de
quoi il retourne au juste.

“ Une excellente manière de déclencher une discussion technique soutenue entre
un groupe d’ingénieurs consiste à  les interroger sur la différence qui existe
entre un objet et un composant. Ensuite, retirez-vous et observez le résultat,
” affirme Andrew Watson, vice-président et directeur technique chez Object Management
Group (OMG), garant des spécifications de composants CORBA (Common Object Request
Broker Architecture).

En effet, plusieurs développeurs semblent utiliser les deux termes de manière
interchangeable. D’autres les différencient par leur taille, leur rôle, ou encore
les plates-formes et les langages qu’ils supportent. Les composants, précisent-ils,
occupent plus de place, contiennent plus de fonctions et sont exécutés sur des
plates-formes hétérogènes alors que développés dans un langage unique afin de
fonctionner sur une plate-forme unique, les objets ont tendance à  représenter
de plus petits bouts de code disposant de fonctions plus limitées.

Toutefois, cette classification ne met pas le doigt sur la différence essentielle.
En effet, les objets et les composants essaient tous deux, de maximiser l’efficacité
du développement en subdivisant le code de l’application en fragments qui effectuent
des fonctions spécifiques et qui peuvent être réutilisés dans une application
partout où cette fonction est nécessaire. Mais la différence se situe dans leur
rapport aux autres objets ou composants. En substance, les objets partagent une
interface commune ainsi que d’autres informations avec les objets dont ils sont
dérivés, ou qui sont dérivés d’eux. Pour leur part, les composants sont complètement
autonomes. Ils sont donc indépendants par rapport à  d’autres composants (pour
un bref rappel historique sur la façon dont les composants ont émergé de la technologie
objet, consultez l’encadré “ La genèse des composants remonte aux objets ”).