Chapitre 1 - Introduction sur les « objets »

Java ressemble beaucoup au C++, et il semblerait naturel que le C++ soit remplacé par Java. Mais je commence à m'interroger sur cette logique. D'une part, C++ dispose toujours de fonctionnalités que Java n'a pas, et bien que de nombreuses promesses aient été faites sur le fait que Java soit un jour aussi rapide, voire même plus, que le C++, on a vu de grosses améliorations mais pas de révolutions spectaculaires. De plus, il semblerait que le C++ intéresse une large communauté passionnée, et je ne pense donc pas que ce langage puisse disparaître prochainement (les langages semblent résister au cours du temps. Allen Hollub a affirmé durant l'un de mes « Séminaires Java Intermédiaire/Avancé » que les deux langages les plus utilisés étaient Rexx et COBOL, dans cet ordre).

Je commence à croire que la force de Java réside dans une optique différente de celle du C++. C++ est un langage qui n'essaie pas de se fondre dans un moule. Il a déjà  été adapté un certain nombre de fois pour résoudre des problèmes particuliers. Certains des outils du C++ combinent des bibliothèques, des modèles de composants et des outils de génération de code pour résoudre les problèmes concernant le développement d'applications fenêtrées (pour Microsoft Windows). Et pourtant, la vaste majorité des développeurs Windows utilisent Microsoft Visual Basic (VB). Et ceci malgré le fait que VB produise le genre de code qui devient ingérable quand le programme fait plus de quelques pages de long (sans compter que la syntaxe peut être profondément mystérieuse). Aussi populaire que soit VB, ce n'est pas un très bon exemple de conception de langage. Il serait agréable de pouvoir disposer des facilités et de la puissance fournies par VB sans se retrouver avec ce code ingérable. Et c'est là où je pense que Java va pouvoir briller : comme le « VB du futur ». On peut frissonner en entendant ceci, mais Java est conçu pour aider le développeur à résoudre des problèmes comme les applications réseaux ou interfaces utilisateurs multiplateformes, et la conception du langage permet la création de portions de code très importantes mais néanmoins flexibles. Ajoutons à ceci le fait que Java dispose des systèmes de vérifications de types et de gestion des erreurs les plus robustes que j'ai jamais rencontré dans un langage et on se retrouve avec les éléments constitutifs d'un bond significatif dans l'amélioration de la productivité dans la programmation.

Faut-il utiliser Java en lieu et place du C++ dans les projets ? En dehors des applets Web, il y a deux points à considérer. Premièrement, si on veut réutiliser un certain nombre de bibliothèques C++ (et on y gagnera certainement en productivité), ou si on dispose d'une base existante en C ou C++, Java peut ralentir le développement plutôt que l'accélérer.

Si on développe tout le code en partant de zéro, alors la simplicité de Java comparée au C++ réduira significativement le temps de développement - des anecdotes (selon des équipes C++ à qui j'ai parlé après qu'ils eurent changé pour Java) suggèrent un doublement de la vitesse de développement comparé au C++. Si les performances moindres de Java ne rentrent pas en ligne de compte ou qu'on peut les compenser, les contraintes de temps font qu'il est difficile de choisir le C++ aux détriments de Java.

Le point le plus important est la performance. Java interprété est lent, environ 20 à 50 fois plus lent que le C dans les interpréteurs Java originels. Ceci a été grandement amélioré avec le temps, mais il restera toujours un important facteur de différence. Les ordinateurs existent de par leur rapidité ; si ce n'était pas considérablement plus rapide de réaliser une tâche sur ordinateur, on la ferait à la main. J'ai même entendu suggérer de démarrer avec Java, pour gagner sur le temps de développement plus court, et ensuite utiliser un outil et des bibliothèques de support pour traduire le code en C++ si on a un besoin de vitesse d'exécution plus rapide.

La clef pour rendre Java viable dans la plupart des projets consiste en des améliorations de vitesse d'exécution, grâce à  des compilateurs « juste à temps » (« just in time », JIT), la technologie « hotspot » de Sun, et même des compilateurs de code natif. Bien sûr, les compilateurs de code natif éliminent les possibilités d'exécution interplateformes du programme compilé, mais la vitesse des exécutables produits se rapprochera de celle du C et du C++. Et réaliser un programme multiplateformes en Java devrait être beaucoup plus facile qu'en C ou C++ (en théorie, il suffit de recompiler, mais cette promesse a déjà été faite pour les autres langages).

Vous trouverez des comparaisons entre Java et C++ et des observations sur Java dans les annexes de la première édition de ce livre (disponible sur le CD ROM accompagnant ce livre, et à www.BruceEckel.com).

Résumé

Ce chapitre tente de vous donner un aperçu des sujets couverts par la programmation orientée objet et Java (les raisons qui font que la POO est particulière, de même que Java), les concepts des méthodologies de la POO, et finalement le genre de problèmes que vous rencontrerez quand vous migrerez dans votre entreprise à la programmation orientée objet et Java.

La POO et Java ne sont pas forcément destinés à tout le monde. Il est important d'évaluer ses besoins et décider si Java satisfera au mieux ces besoins, ou si un autre système de programmation ne conviendrait pas mieux (celui qu'on utilise actuellement y compris). Si on connaît ses besoins futurs et qu'ils impliquent des contraintes spécifiques non satisfaites par Java, alors on se doit d'étudier les alternatives existantes  [19]. Et même si finalement Java est retenu, on saura au moins quelles étaient les options et les raisons de ce choix.

On sait à quoi ressemble un programme procédural : des définitions de données et des appels de fonctions. Pour trouver le sens d'un tel programme il faut se plonger dans la chaîne des appels de fonctions et des concepts de bas niveau pour se représenter le modèle du programme. C'est la raison pour laquelle on a besoin de représentations intermédiaires quand on conçoit des programmes procéduraux - par nature, ces programmes tendent à être confus car le code utilise des termes plus orientés vers la machine que vers le problème qu'on tente de résoudre.

Parce que Java introduit de nombreux nouveaux concepts par rapport à ceux qu'on trouve dans un langage procédural, on pourrait se dire que la fonction main() dans un programme Java sera bien plus compliquée que son équivalent dans un programme C. On sera agréablement surpris de constater qu'un programme Java bien écrit est généralement beaucoup plus simple et facile à comprendre que son équivalent en C. On n'y voit que les définitions des objets qui représentent les concepts de l'espace problème (plutôt que leur représentation dans l'espace machine) et les messages envoyés à ces objets pour représenter les activités dans cet espace. L'un des avantages de la POO est qu'avec un programme bien conçu, il est facile de comprendre le code en le lisant. De plus, il y a généralement moins de code, car beaucoup de problèmes sont résolus en réutilisant du code existant dans des bibliothèques.

[2]Voir Multiparadigm Programming in Leda de Timothy Budd (Addison-Wesley 1995).

[3]Certaines personnes établissent une distinction, en disant qu'un type détermine une interface tandis qu'une classe est une implémentation particulière de cette interface.

[4]Je suis reconnaissant envers mon ami Scott Meyers pour cette expression.

[5]Cela suffit généralement pour la plupart des diagrammes, et on n'a pas besoin de préciser si on utilise un agrégat ou une composition.

[6]Invention personnelle.

[7]Les types primitifs, que vous rencontrerez plus loin, sont un cas spécial.

[8]Un très bon exemple en est UML Distilled, 2nd edition, de Martin Fowler (Addison-Wesley 2000), qui réduit la méthode UML - parfois écrasante - à un sous-ensemble facilement gérable.

[9]Ma règle pour estimer de tels projets : s'il y a plus d'un facteur joker, n'essayez même pas de planifier combien de temps cela va prendre ou d'estimer le coût avant d'avoir créé un prototype fonctionnel. Il y a trop de degrés de liberté.

[10]Merci à James H Jarrett pour son aide.

[11]D'autres informations sur les cas d'utilisation peuvent être trouvées dans Applying Use Cases de Schneider & Winters (Addison-Wesley 1998) et Use Case Driven Object Modeling with UML de Rosenberg (Addison-Wesley 1999).

[12]Mon avis personnel sur tout cela a changé récemment. Doubler et ajouter 10 pour cent donnera une estimation raisonnablement précise (en assumant qu'il n'y ait pas trop de facteurs joker), mais il faudra tout de même ne pas traîner en cours de route pour respecter ce délai. Si on veut réellement du temps pour rendre le système élégant et ne pas être continuellement sous pression, le multiplicateur correct serait plus trois ou quatre fois le temps prévu, je pense..

[13]Pour les débutants, je recommande UML Distilled, 2nd edition, déjà mentionné plus haut.

[14]Python (www.python.org) est souvent utilisé en tant que « pseudocode exécutable ».

[15]Au moins un aspect de l'évolution est couvert dans le livre de Martin Fowler Refactoring : improving the design of existing code (Addison-Wesley 1999), qui utilise exclusivement des exemples Java.

[16]Cela peut ressembler au « prototypage rapide » où on est supposé fournir une version rapide-et-sale afin de pouvoir appréhender correctement le problème, puis jeter ce prototype et construire une version finale acceptable. L'inconvénient du prototypage rapide est que les gens ne jettent pas le prototype, mais s'en servent de base pour le développement. Combiné au manque de structure de la programmation procédurale, cela mène à des systèmes compliqués et embrouillés, difficiles et onéreux à maintenir.

[17]Bien que ceci soit plus une perception américaine, les productions hollywoodiennes touchent tout le monde.

[18]En particulier le système d'annonces sonores. J'ai travaillé une fois dans une entreprise qui insistait pour diffuser tous les appels téléphoniques à tous les responsables, et cela interrompait constamment notre productivité (mais les responsables n'imaginaient même pas qu'il soit concevable de vouloir couper un service aussi important que le système d'annonces sonores). Finalement, j'ai coupé les fils des haut-parleurs quand personne ne regardait.

[19]En particulier, je recommande de regarder dans la direction de Python (www.Python.org).