Aujourd’hui il n’est pas rare d’utiliser ou de concevoir un composant logiciel. Pour poursuivre l’analogie avec la pyramide, il faudrait même dire une brique logicielle.

Force est de constater qu’une hiérarchie s’installe dans un environnement multi-composant.

Pourquoi écrire un composant??

Un composant logiciel permet d’écrire une seule fois des objets techniques (le plus souvent). Ces objets pourront être réutilisés au travers des composants et des projets.

Pourquoi utiliser un composant??

Un composant logiciel est utilisé afin de ne pas réinventer la roue. Son utilisation accélère la réalisation du composant principal.

Quels sont les bénéfices tirés??

La conception par composant permet de ne pas réécrire plusieurs fois le même objet technique. On parle de factorisation du code.

En allant plus loin, lorsqu’une anomalie est corrigée dans un composant, ce sont tous les autres composants qui l’utilisent qui bénéficient automatiquement de cette correction. Et ceci est vrai également pour les évolutions fonctionnelles. Par contre il faut prêter attention à la compatibilité ascendante!!

Existe-il vraiment une hiérarchie??

La réponse est évidente; et est oui!! Par contre il est moins évident de dire quels sont les composants qui tirent leur épingle du jeu. Est-ce les composants de bas niveau (à la base de la pyramide) ou bien ceux de haut niveau (au sommet de la pyramide)??

Les composants de bas niveau sont extrêmement stables et tendent à la perfection. En effet, plus ils sont utilisés par d’autres composants et plus ils s’améliorent (au fil des corrections). Plus ils s’améliorent, plus ils sont utilisés.

Les composants de haut niveau ont, quant à eux, une stabilité à risque. Non pas qu’ils sont instables, mais le risque est plus important puisqu’ils héritent des tares des composants qu’ils utilisent eux-même (qui héritent également des anomalies d… ça peut aller très loin). Par contre ce sont des composants très riches fonctionnellement et parfois concus à moindre frais.