1) Introduction sur les « objets » Texte original Traducteur : Jérome QUELIN /// Ce chapitre contient 8 pages 1 2 3 4 5 6 7 8      Java vs. C++? Java vs. C++ ? Java looks a lot like C++, and so naturally it would seem that C++ will be replaced by Java. But I’m starting to question this logic. For one thing, C++ still has some features that Java doesn’t, and although there have been a lot of promises about Java someday being as fast or faster than C++, we’ve seen steady improvements but no dramatic breakthroughs. Also, there seems to be a continuing interest in C++, so I don’t think that language is going away any time soon. (Languages seem to hang around. Speaking at one of my “Intermediate/Advanced Java Seminars,” Allen Holub asserted that the two most commonly used languages are Rexx and COBOL, in that order.) 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). I’m beginning to think that the strength of Java lies in a slightly different arena than that of C++. C++ is a language that doesn’t try to fit a mold. Certainly it has been adapted in a number of ways to solve particular problems. Some C++ tools combine libraries, component models, and code-generation tools to solve the problem of developing windowed end-user applications (for Microsoft Windows). And yet, what do the vast majority of Windows developers use? Microsoft’s Visual Basic (VB). This despite the fact that VB produces the kind of code that becomes unmanageable when the program is only a few pages long (and syntax that can be positively mystifying). As successful and popular as VB is, it’s not a very good example of language design. It would be nice to have the ease and power of VB without the resulting unmanageable code. And that’s where I think Java will shine: as the “next VB.” You may or may not shudder to hear this, but think about it: so much of Java is intended to make it easy for the programmer to solve application-level problems like networking and cross-platform UI, and yet it has a language design that allows the creation of very large and flexible bodies of code. Add to this the fact that Java has the most robust type checking and error handling systems I’ve ever seen in a language and you have the makings of a significant leap forward in programming productivity. 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. Should you use Java instead of C++ for your project? Other than Web applets, there are two issues to consider. First, if you want to use a lot of existing C++ libraries (and you’ll certainly get a lot of productivity gains there), or if you have an existing C or C++ code base, Java might slow your development down rather than speeding it up. 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. If you’re developing all your code primarily from scratch, then the simplicity of Java over C++ will significantly shorten your development time—the anecdotal evidence (stories from C++ teams that I’ve talked to who have switched to Java) suggests a doubling of development speed over C++. If Java performance doesn’t matter or you can somehow compensate for it, sheer time-to-market issues make it difficult to choose C++ over Java. 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. The biggest issue is performance. Interpreted Java has been slow, even 20 to 50 times slower than C in the original Java interpreters. This has improved greatly over time, but it will still remain an important number. Computers are about speed; if it wasn’t significantly faster to do something on a computer then you’d do it by hand. (I’ve even heard it suggested that you start with Java, to gain the short development time, then use a tool and support libraries to translate your code to C++, if you need faster execution speed.) 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. The key to making Java feasible for most development projects is the appearance of speed improvements like so-called “just-in time” (JIT) compilers, Sun’s own “hotspot” technology, and even native code compilers. Of course, native code compilers will eliminate the touted cross-platform execution of the compiled programs, but they will also bring the speed of the executable closer to that of C and C++. And cross-compiling a program in Java should be a lot easier than doing so in C or C++. (In theory, you just recompile, but that promise has been made before for other languages.) 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). You can find comparisons of Java and C++ and observations about Java realities in the appendices of the first edition of this book (Available on this book’s accompanying CD ROM, as well as at www.BruceEckel.com). 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). Summary Résumé This chapter attempts to give you a feel for the broad issues of object-oriented programming and Java, including why OOP is different, and why Java in particular is different, concepts of OOP methodologies, and finally the kinds of issues you will encounter when moving your own company to OOP and Java. 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. OOP and Java may not be for everyone. It’s important to evaluate your own needs and decide whether Java will optimally satisfy those needs, or if you might be better off with another programming system (including the one you’re currently using). If you know that your needs will be very specialized for the foreseeable future and if you have specific constraints that may not be satisfied by Java, then you owe it to yourself to investigate the alternatives[19]. Even if you eventually choose Java as your language, you’ll at least understand what the options were and have a clear vision of why you took that direction. 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. You know what a procedural program looks like: data definitions and function calls. To find the meaning of such a program you have to work a little, looking through the function calls and low-level concepts to create a model in your mind. This is the reason we need intermediate representations when designing procedural programs—by themselves, these programs tend to be confusing because the terms of expression are oriented more toward the computer than to the problem you’re solving. 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. Because Java adds many new concepts on top of what you find in a procedural language, your natural assumption may be that the main( ) in a Java program will be far more complicated than for the equivalent C program. Here, you’ll be pleasantly surprised: A well-written Java program is generally far simpler and much easier to understand than the equivalent C program. What you’ll see are the definitions of the objects that represent concepts in your problem space (rather than the issues of the computer representation) and messages sent to those objects to represent the activities in that space. One of the delights of object-oriented programming is that, with a well-designed program, it’s easy to understand the code by reading it. Usually there’s a lot less code as well, because many of your problems will be solved by reusing existing library code. 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] See Multiparadigm Programming in Leda by Timothy Budd (Addison-Wesley 1995). [2]Voir Multiparadigm Programming in Leda de Timothy Budd (Addison-Wesley 1995). [3] Some people make a distinction, stating that type determines the interface while class is a particular implementation of that interface. [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] I’m indebted to my friend Scott Meyers for this term. [4]Je suis reconnaissant envers mon ami Scott Meyers pour cette expression. [5] This is usually enough detail for most diagrams, and you don’t need to get specific about whether you’re using aggregation or composition. [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] My term. [6]Invention personnelle. [7] Primitive types, which you’ll learn about later, are a special case. [7]Les types primitifs, que vous rencontrerez plus loin, sont un cas spécial. [8] An excellent example of this is UML Distilled, 2nd edition, by Martin Fowler (Addison-Wesley 2000), which reduces the sometimes-overwhelming UML process to a manageable subset. [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] My rule of thumb for estimating such projects: If there’s more than one wild card, don’t even try to plan how long it’s going to take or how much it will cost until you’ve created a working prototype. There are too many degrees of freedom. [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] Thanks for help from James H Jarrett. [10]Merci à James H Jarrett pour son aide. [11] More information on use cases can be found in Applying Use Cases by Schneider & Winters (Addison-Wesley 1998) and Use Case Driven Object Modeling with UML by Rosenberg (Addison-Wesley 1999). [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] My personal take on this has changed lately. Doubling and adding 10 percent will give you a reasonably accurate estimate (assuming there are not too many wild-card factors), but you still have to work quite diligently to finish in that time. If you want time to really make it elegant and to enjoy yourself in the process, the correct multiplier is more like three or four times, I believe. [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] For starters, I recommend the aforementioned UML Distilled, 2nd edition. [13]Pour les débutants, je recommande UML Distilled, 2nd edition, déjà mentionné plus haut. [14] Python (www.Python.org) is often used as “executable pseudocode.” [14]Python (www.python.org) est souvent utilisé en tant que « pseudocode exécutable ». [15] At least one aspect of evolution is covered in Martin Fowler’s book Refactoring: improving the design of existing code (Addison-Wesley 1999), which uses Java examples exclusively. [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] This is something like “rapid prototyping,” where you were supposed to build a quick-and-dirty version so that you could learn about the system, and then throw away your prototype and build it right. The trouble with rapid prototyping is that people didn’t throw away the prototype, but instead built upon it. Combined with the lack of structure in procedural programming, this often leads to messy systems that are expensive to maintain. [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] Although this may be a more American perspective, the stories of Hollywood reach everywhere. [17]Bien que ceci soit plus une perception américaine, les productions hollywoodiennes touchent tout le monde. [18] Including (especially) the PA system. I once worked in a company that insisted on broadcasting every phone call that arrived for every executive, and it constantly interrupted our productivity (but the managers couldn’t begin to conceive of stifling such an important service as the PA). Finally, when no one was looking I started snipping speaker wires. [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] In particular, I recommend looking at Python (http://www.Python.org). [ Previous Chapter ] [ Short TOC ] [ Table of Contents ] [ Index ] [ Next Chapter ] Last Update:04/24/2000 [19]En particulier, je recommande de regarder dans la direction de Python (www.Python.org). \\\ Haut de page