> Tech > La genèse des composants remonte aux objets

La genèse des composants remonte aux objets

Tech - Par iTPro - Publié le 24 juin 2010
email

Il y a quatre ans, pratiquement tous les magazines spécialisés en informatique arboraient des séries d'articles vantant les mérites de la programmation orientée objet (OO). Les objets étaient présentés comme la voie royale et les gourous prédisaient qu'à  l'heure actuelle, tout le monde programmerait en utilisant des objets. Il se

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

Téléchargez cette ressource

Checklist de protection contre les ransomwares

Checklist de protection contre les ransomwares

Comment évaluer votre niveau de protection contre les ransomwares à la périphérie du réseau, et améliorer vos défenses notamment pour la détection des ransomwares sur les terminaux, la configuration des appareils, les stratégies de sauvegarde, les opérations de délestage... Découvrez la check list complète des facteurs clés pour améliorer immédiatement la sécurité des terminaux.

Tech - Par iTPro - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT