ISBN : 2-212-09016-1
|
|
L'origine de la programmation objet est liée au besoin de regrouper des éléments informatiques ayant des caractéristiques communes afin de faciliter la programmation et l'exploitation de gros logiciels. La programmation structurée a privilégié les traitements par rapport aux données. La programmation objet s'intéresse aux données et permet de définir les traitements associés.
L'émergence de langages offrant automatiquement le paradigme objet a facilité son implantation et son utilisation. Un concept facile à utiliser permet d'améliorer la qualité des programmes.
L'approche procédurale propose un regroupement par traitement (ou sous-programme). Le modèle de données a un impact important sur l'ensemble des traitements de l'application. Une modification de celui-ci a une incidence sur la plupart des traitements. En effet, il est difficile de réutiliser un sous-programme complexe.
La programmation objet peut être comme un style de programmation permettant d'améliorer la qualité des programmes en répartissant la complexité sur chaque objet. Un programme n'est alors qu'une collection de traitements associés à des données, appelés objets et regroupés pour fonctionner ensemble. Les données n'étant modifiées que par un ensemble restreint et identifié de traitements, les erreurs sont plus facilement localisables. Un autre apport de la programmation objet est le polymorphisme. Ce concept permet de sélectionner un traitement suivant l'objet manipulé et d'enrichir ou de réutiliser un programme existant.
Le modèle objet est utilisable lors de l'analyse, de la conception et du codage. Cela permet d'obtenir une cohérence totale lors du développement. Il est facile de retourner en conception alors que la phase de codage est déjà fortement amorcée. Les langages ne possèdent pas toujours une traduction immédiate des concepts utilisés lors de l'analyse objet (tel est le cas de la relation "a un" par exemple), mais tout programme objet possède une traduction immédiate dans le modèle de conception. On ne retourne pas à la conception initiale mais on reste dans le paradigme objet.
Il n'est pas nécessaire d'utiliser un langage objet pour utiliser ce paradigme. Celui-ci peut s'exprimer avec un langage procédural traditionnel, mais cette procédure est très complexe, donc difficile à réaliser et à maintenir. Dans tous les cas, si un concept n'est pas présent dans un langage, il peut être traduit à la main. Il ne faut pas oublier qu'en final, cela se traduit par des ordres primitifs destinés au microprocesseur du poste de travail.
Plus un concept est apparent, plus le code est facile à maintenir et à comprendre. Par exemple, la syntaxe du langage peut exprimer clairement que l'on utilise une boucle de type "tant que". Il est facile de rédiger une boucle équivalente sans utiliser la syntaxe proposée par le langage. Un commentaire peut alors indiquer que le code traduit une boucle de ce type.
Pour des concepts plus complexes, la démarche est identique. Un code peut être la traduction d'un concept absent du langage. Les commentaires peuvent indiquer l'existence d'un concept. Le plus souvent, le programmeur ne sait même pas qu'il les utilise. Les règles de traduction de ces concepts ne seront pas maîtrisées, et il y aura des erreurs qui auraient pu être évitées si le sens avait été parfaitement compris. C'est pour cela que des langages plus évolués ont été inventés. Après avoir identifié les concepts les plus courants en développement, les langages ont proposé une syntaxe permettant de les exprimer.
L'identification d'un concept facilite également la communication entre développeurs. Un vocabulaire commun permet de négliger les détails d'implémentation. L'expression d'une idée sera éclairée par l'utilisation d'un concept déjà connu des interlocuteurs. Un concept est l'identification d'un traitement répétitif dans les développements. Il possède une traduction syntaxique. Un langage est équipé d'outils syntaxiques facilitant l'utilisation des concepts. Il est préférable d'avoir des informations de sens dans le langage plutôt que dans les commentaires. Les commentaires n'étant pas nécessaires à l'exécution du programme, ils sont souvent négligés. De plus, rien ne garantit leur adéquation au programme. C'est pourquoi il est préférable d'utiliser les éléments syntaxiques du langage plutôt qu'un codage à la main. Un concept est vérifié par le compilateur. Attention : l'existence d'un concept n'entraîne pas forcément la justesse de son utilisation. Il faut bien comprendre son objectif pour utiliser correctement les éléments syntaxiques correspondants.
La qualité d'un langage de programmation s'évalue selon sa richesse, sa cohérence, sa facilité d'utilisation et son intégration des concepts mis en place. De plus, l'environnement de développement doit apporter une aide importante pour faciliter la réalisation des logiciels, mais il est très difficile de comparer les environnements de développement, car ceux-ci sont spécifiques à chaque fournisseur.
Les langages, au contraire, sont normalisés. Ils se concurrencent sur la qualité. Les fournisseurs s'affrontent alors sur les environnements de développement et cherchent à imposer leurs bibliothèques pour fidéliser leurs clients. Smalltalk est un cas à part, car il est très fortement lié à ses environnements de développement. Choisir Smalltalk, c'est également choisir un fournisseur d'environnement et de bibliothèques.
Il existe pour tous les langages orientés objet, des bibliothèques permettant de créer des applications interactives avec fenêtres. Les approches sont différentes, mais les fonctionnalités très similaires. Les environnements de développement proposent des outils d'aide à la manipulation du langage (éditeur, navigateur de classe, références croisées, débogueurs, etc.), et des outils de génération de code spécifiques à leurs bibliothèques.
La famille Visual Age d'IBM est un exemple d'environnement adaptable à différents langages. Cela permet d'ajouter la notion de composants logiciels (Parts) absents du langage, mais supportés par l'environnement. Visual Age propose aussi la programmation visuelle.
Dans ce document, les concepts présents dans les environnements ne sont pas décrits.
Ce document se propose donc de comparer les trois langages orientés objet les plus en vogue : Smalltalk, Java™ et C++. Cet ordre n'est pas chronologique. En effet, Java est le plus jeune des trois. Intercalé entre Smalltalk et C++, sa place correspond à sa position technique, même s'il est proche des deux autres. Cet ordre facilite la description séquentielle des approches.
Le paradigme objet utilise un vocabulaire qui lui est propre. Il vous sera présenté au fur et à mesure. Vous trouverez en annexe un lexique qui vous permettra de vérifier la définition d'un terme.
Le livre est découpé en trois parties : la première, Les concepts, fait place aux Autres caractéristiques, dans la deuxième partie, qu'achève la troisième partie en guise de Conclusion.
Je remercie Stéphane Ducasse et Dan Dimcea, Philippe Duret, Paul-Henri Lampe, Marc Legru et Le Xiaohua pour leurs nombreuses remarques.
Pour me contacter : Ph. Prados
