La genèse des composants remonte aux objets

trouve que cette prédiction ne s’est pas vérifiée.

“ Bon nombre de personnes conçoivent des applications de gestion en utilisant
avec succès des langages et des méthodes orientés objet. Toutefois, elles sont
certainement loin de constituer la majorité des développeurs, ” affirme Keith
Jaeger, Senior Manager du laboratoire Sterling Software.

Les premiers objets furent conçus pour exécuter des tâches relativement simples.
Ensuite, lorsque les développeurs souhaitaient qu’un objet réalise une fonction
légèrement différente, au lieu de créer un objet entièrement neuf, ils créaient
une sous-classe qui héritait de certaines propriétés de la classe du premier objet.
Ces objets dérivés sont rattachés à  leurs parents par le biais d’une hiérarchie
de classes. Les modifications effectuées sur une classe affectent automatiquement
le comportement de tous les objets ou sous-classes apparentés.

“ Pour les moindres changements, et quelle que soient leur importance, la hiérarchie
des classes peut très vite devenir énorme. Si on a besoin d’ajouter ou de modifier
quelque chose, il faut savoir exactement où intervenir dans la hiérarchie de l’héritage.
Ajouter de nouvelles classes qui ne tirent pas profit de la hiérarchie existante
va à  l’encontre de l’objectif visé, qui consiste à  réutiliser les classes existantes.
En revanche, modifier la hiérarchie peut avoir des répercussions parfois inattendues
sur le reste du système ”, indique Keith Jaeger.

Bien que l’orientation objet apporte des gains de productivité non négligeables
et dispense les développeurs de devoir recommencer à  zéro à  chaque objet qu’ils
créent, l’industrie a besoin d’une méthodologie plus conviviale pour atteindre
l’objectif de réutilisation du code. La solution ? Construire des murs entre les
objets pour que chacun existe comme une “ boîte noire ” appelée composant. Un
composant possède une interface qui gère les traitements et masque ses mécanismes
internes.

D’une certaine façon, commente Keith Jaeger, ce modèle génère plus de travail
pour le développeur parce que ces boîtes noires ne peuvent pas partager leurs
mécanismes internes comme le font les classes. Cependant, le côté positif est
que les composants sont plus faciles à  comprendre et à  utiliser dans les applications.
Ils suffit simplement de les intégrer. Nul besoin de se préoccuper de leur origine.

CR