Penser en Java - 1) Introduction sur les

1) Introduction sur les « objets »

Texte original

Traducteur : Jérome QUELIN

///

Ce chapitre contient 8 pages
1 2 3 4 5 6 7 8

\\\

Extreme programming

Programmation Extrême

I have studied analysis and design techniques, on and off, since I was in graduate school. The concept of Extreme Programming (XP) is the most radical, and delightful, that I’ve seen. You can find it chronicled in Extreme Programming Explained by Kent Beck (Addison-Wesley, 2000) and on the Web at www.xprogramming.com.

J'ai étudié à différentes reprises les techniques d'analyse et de conception depuis que je suis sorti de l'école. Le concept de Programmation Extreme (XP) est le plus radical et divertissant que j'ai vu. Il est rapporté dans Extreme Programming Explained de Kent Beck (Addison-Wesley, 2000) et sur le web à www.xprogramming.com.

XP is both a philosophy about programming work and a set of guidelines to do it. Some of these guidelines are reflected in other recent methodologies, but the two most important and distinct contributions, in my opinion, are “write tests first” and “pair programming.” Although he argues strongly for the whole process, Beck points out that if you adopt only these two practices you’ll greatly improve your productivity and reliability.

XP est à la fois une philosophie à propos de la programmation et un ensemble de règles de bases. Certaines de ces règles sont reprises dans d'autres méthodologies récentes, mais les deux contributions les plus importantes et novatrices, sont à mon sens « commencer par écrire les tests » et « programmation en binôme ». Bien qu'il soutienne et argumente l'ensemble de la théorie, Beck insiste sur le fait que l'adoption de ces deux pratiques améliore grandement la productivité et la fiabilité.

Write tests first

Commencer par écrire les tests

Testing has traditionally been relegated to the last part of a project, after you’ve “gotten everything working, but just to be sure.” It’s implicitly had a low priority, and people who specialize in it have not been given a lot of status and have often even been cordoned off in a basement, away from the “real programmers.” Test teams have responded in kind, going so far as to wear black clothing and cackling with glee whenever they break something (to be honest, I’ve had this feeling myself when breaking compilers).

Les tests ont traditionnellement été relégués à la dernière partie d'un projet, une fois que « tout marche, mais c'est juste pour s'en assurer ». Ils ne sont généralement pas prioritaires et les gens qui se spécialisent dedans ne sont pas reconnus à leur juste valeur et se sont souvent vus cantonnés dans un sous-sol, loin des « véritables programmeurs ». Les équipes de test ont réagi en conséquence, allant jusqu'à porter des vêtements de deuil et glousser joyeusement quand ils trouvaient des erreurs (pour être honnête, j'ai eu moi aussi ce genre de sentiments lorsque je mettais des compilateurs en faute).

XP completely revolutionizes the concept of testing by giving it equal (or even greater) priority than the code. In fact, you write the tests before you write the code that will be tested, and the tests stay with the code forever. The tests must be executed successfully every time you do an integration of the project (which is often, sometimes more than once a day).

XP révolutionne complètement le concept du test en lui donnant une priorité aussi importante (ou même plus forte) que le code. En fait, les tests sont écrits avant le code qui sera testé, et les tests restent tout le temps avec le code. Ces tests doivent être exécutés avec succès à chaque nouvelle intégration dans le projet (ce qui peut arriver plus d'une fois par jour).

Writing tests first has two extremely important effects.

Ecrire les tests d'abord a deux effets extrêmement importants.

First, it forces a clear definition of the interface of a class. I’ve often suggested that people “imagine the perfect class to solve a particular problem” as a tool when trying to design the system. The XP testing strategy goes further than that—it specifies exactly what the class must look like, to the consumer of that class, and exactly how the class must behave. In no uncertain terms. You can write all the prose, or create all the diagrams you want, describing how a class should behave and what it looks like, but nothing is as real as a set of tests. The former is a wish list, but the tests are a contract that is enforced by the compiler and the running program. It’s hard to imagine a more concrete description of a class than the tests.

Premièrement, cela nécessite une définition claire de l'interface d'une classe. J'ai souvent suggéré que les gens « imaginent la classe parfaite qui résolve un problème particulier » comme outil pour concevoir le système. La stratégie de test de XP va plus loin - elle spécifie exactement ce à quoi la classe doit ressembler pour le client de cette classe, et comment la classe doit se comporter. Dans des termes non ambigus. On peut écrire tout ce qu'on veut, ou créer tous les diagrammes qu'on veut, décrivant comment une classe devrait se comporter et ce à quoi elle ressemble, mais rien n'est aussi réel qu'une batterie de tests. Le premier est une liste de voeux, mais les tests sont un contrat certifié par un compilateur et un programme qui marche. Il est dur d'imaginer une description plus concrète d'une classe que des tests.

While creating the tests, you are forced to completely think out the class and will often discover needed functionality that might be missed during the thought experiments of UML diagrams, CRC cards, use cases, etc.

En créant les tests, on est forcé de penser complètement la classe et souvent on découvre des fonctionnalités nécessaires qui ont pu être manquées lors de l'utilisation des diagrammes UML, des cartes CRC, des cas d'utilisation, etc...

The second important effect of writing the tests first comes from running the tests every time you do a build of your software. This activity gives you the other half of the testing that’s performed by the compiler. If you look at the evolution of programming languages from this perspective, you’ll see that the real improvements in the technology have actually revolved around testing. Assembly language checked only for syntax, but C imposed some semantic restrictions, and these prevented you from making certain types of mistakes. OOP languages impose even more semantic restrictions, which if you think about it are actually forms of testing. “Is this data type being used properly?” and “Is this function being called properly?” are the kinds of tests that are being performed by the compiler or run-time system. We’ve seen the results of having these tests built into the language: people have been able to write more complex systems, and get them to work, with much less time and effort. I’ve puzzled over why this is, but now I realize it’s the tests: you do something wrong, and the safety net of the built-in tests tells you there’s a problem and points you to where it is.

Le deuxième effet important dans l'écriture des tests en premier vient du fait qu'on peut lancer les tests à chaque nouvelle version du logiciel. Cela permet d'obtenir l'autre moitié des tests réalisés par le compilateur. Si on regarde l'évolution des langages de programmation de ce point de vue, on se rend compte que les améliorations réelles dans la technologie ont en fait tourné autour du test. Les langages assembleur vérifiaient uniquement la syntaxe, puis le C a imposé des restrictions sémantiques, et cela permettait d'éviter certains types d'erreurs. Les langages orientés objet imposent encore plus de restrictions sémantiques, qui sont quand on y pense des formes de test. « Est-ce que ce type de données est utilisé correctement ? » et « Est-ce que cette fonction est appelée correctement ? » sont le genre de tests effectués par le compilateur ou le système d'exécution. On a pu voir le résultat d'avoir ces tests dans le langage même : les gens ont été capables de construire des systèmes plus complexes, et de les faire marcher, et ce en moins de temps et d'efforts. Je me suis souvent demandé pourquoi, mais maintenant je réalise que c'est grâce aux tests : si on fait quelque chose de faux, le filet de sécurité des tests intégré au langage prévient qu'il y a un problème et montre même où il réside.

But the built-in testing afforded by the design of the language can only go so far. At some point, you must step in and add the rest of the tests that produce a full suite (in cooperation with the compiler and run-time system) that verifies all of your program. And, just like having a compiler watching over your shoulder, wouldn’t you want these tests helping you right from the beginning? That’s why you write them first, and run them automatically with every build of your system. Your tests become an extension of the safety net provided by the language.

Mais les tests intégrés permis par la conception du langage ne peuvent aller plus loin. A partir d'un certain point, il est de notre responsabilité de produire une suite complète de tests (en coopération avec le compilateur et le système d'exécution) qui vérifie tout le programme. Et, de même qu'il est agréable d'avoir un compilateur qui vérifie ce qu'on code, ne serait-il pas préférable que ces tests soient présents depuis le début ? C'est pourquoi on les écrit en premier, et qu'on les exécute automatiquement à chaque nouvelle version du système. Les tests deviennent une extension du filet de sécurité fourni par le langage.

One of the things that I’ve discovered about the use of more and more powerful programming languages is that I am emboldened to try more brazen experiments, because I know that the language will keep me from wasting my time chasing bugs. The XP test scheme does the same thing for your entire project. Because you know your tests will always catch any problems that you introduce (and you regularly add any new tests as you think of them), you can make big changes when you need to without worrying that you’ll throw the whole project into complete disarray. This is incredibly powerful.

L'utilisation de langages de programmation de plus en plus puissants m'a permis de tenter plus de choses audacieuses, parce que je sais que le langage m'empêchera de perdre mon temps à chasser les bugs. La stratégie de tests de XP réalise la même chose pour l'ensemble du projet. Et parce qu'on sait que les tests vont révéler tous les problèmes introduits (et on ajoute de nouveaux tests au fur et à mesure qu'on les imagine), on peut faire de gros changements sans se soucier de mettre le projet complet en déroute. Ceci est une approche particulièrement puissante.

Pair programming

Programmation en binôme

Pair programming goes against the rugged individualism that we’ve been indoctrinated into from the beginning, through school (where we succeed or fail on our own, and working with our neighbors is considered “cheating”), and media, especially Hollywood movies in which the hero is usually fighting against mindless conformity[17]. Programmers, too, are considered paragons of individuality—“cowboy coders” as Larry Constantine likes to say. And yet XP, which is itself battling against conventional thinking, says that code should be written with two people per workstation. And that this should be done in an area with a group of workstations, without the barriers that the facilities-design people are so fond of. In fact, Beck says that the first task of converting to XP is to arrive with screwdrivers and Allen wrenches and take apart everything that gets in the way.[18] (This will require a manager who can deflect the ire of the facilities department.)

La programmation en binôme va à l'encontre de l'individualisme farouche endoctriné, depuis l'école (où on réussit ou échoue suivant nos mérites personnels, et où travailler avec ses voisins est considéré comme « tricher »), et jusqu'aux médias, en particulier les films hollywoodiens dans lequel le héros se bat contre la conformité href="#fn17" name="fnB17">[17]. Les programmeurs aussi sont considérés comme des parangons d'individualisme - des « codeurs cowboy » comme aime à le dire Larry Constantine. Et XP, qui se bat lui-même contre la pensée conventionnelle, soutient que le code devrait être écrit avec deux personnes par station de travail. Et cela devrait être fait dans un endroit regroupant plusieurs stations de travail, sans les barrières dont raffolent les gens des Moyens Généraux. En fait, Beck dit que la première tâche nécessaire pour implémenter XP est de venir avec des tournevis et d'enlever tout ce qui se trouve dans le passage "fnB18">[18](cela nécessite un responsable qui puisse absorber la colère du département des Moyens Généraux).

The value of pair programming is that one person is actually doing the coding while the other is thinking about it. The thinker keeps the big picture in mind—not only the picture of the problem at hand, but the guidelines of XP. If two people are working, it’s less likely that one of them will get away with saying, “I don’t want to write the tests first,” for example. And if the coder gets stuck, they can swap places. If both of them get stuck, their musings may be overheard by someone else in the work area who can contribute. Working in pairs keeps things flowing and on track. Probably more important, it makes programming a lot more social and fun.

Dans la programmation en binôme, une personne produit le code tandis que l'autre y réfléchit. Le penseur garde la conception générale à l'esprit - la description du problème, mais aussi les règles de XP à portée de main. Si deux personnes travaillent, il y a moins de chance que l'une d'entre elles s'en aille en disant « Je ne veux pas commencer en écrivant les tests », par exemple. Et si le codeur reste bloqué, ils peuvent changer leurs places. Si les deux restent bloqués, leurs songeries peuvent être remarquées par quelqu'un d'autre dans la zone de travail qui peut venir les aider. Travailler en binôme permet de garder une bonne productivité et de rester sur la bonne pente. Probablement plus important, cela rend la programmation beaucoup plus sociable et amusante.

I’ve begun using pair programming during the exercise periods in some of my seminars and it seems to significantly improve everyone’s experience.

J'ai commencé à utiliser la programmation en binôme durant les périodes d'exercice dans certains de mes séminaires et il semblerait que cela enrichisse l'expérience personnelle de chacun.

Why Java succeeds

Les raisons du succès de Java

The reason Java has been so successful is that the goal was to solve many of the problems facing developers today. The goal of Java is improved productivity. This productivity comes in many ways, but the language is designed to aid you as much as possible, while hindering you as little as possible with arbitrary rules or any requirement that you use a particular set of features. Java is designed to be practical; Java language design decisions were based on providing the maximum benefits to the programmer.

Java est si populaire actuellement car son but est de résoudre beaucoup de problèmes auxquels les programmeurs doivent faire face aujourd'hui. Le but de Java est d'améliorer la productivité. La productivité vient de différents horizons, mais le langage a été conçu pour aider un maximum tout en entravant le moins possible avec des règles arbitraires ou l'obligation d'utiliser un ensemble particulier de caractéristiques. Java a été conçu pour être pratique ; les décisions concernant la conception de Java furent prises afin que le programmeur en retire le maximum de bénéfices.

Systems are easier to express and understand

Les systèmes sont plus faciles à exprimer et comprendre

Classes designed to fit the problem tend to express it better. This means that when you write the code, you’re describing your solution in the terms of the problem space (“Put the grommet in the bin”) rather than the terms of the computer, which is the solution space (“Set the bit in the chip that means that the relay will close”). You deal with higher-level concepts and can do much more with a single line of code.

Les classes conçues pour résoudre le problème sont plus faciles à exprimer. La solution est mise en oeuvre dans le code avec des termes de l'espace problème (« Mets le fichier à la poubelle ») plutôt qu'en termes machine, l'espace solution (« Positionne le bit à 1 ce qui veut dire que le relais va se fermer »). On traite de concepts de plus haut niveau et une ligne de code est plus porteuse de sens.

The other benefit of this ease of expression is maintenance, which (if reports can be believed) takes a huge portion of the cost over a program’s lifetime. If a program is easier to understand, then it’s easier to maintain. This can also reduce the cost of creating and maintaining the documentation.

L'autre aspect bénéfique de cette facilité d'expression se retrouve dans la maintenance, qui représente (s'il faut en croire les rapports) une grosse part du coût d'un programme. Si un programme est plus facile à comprendre, il est forcément plus facile à maintenir. Cela réduit aussi le coût de création et de maintenance de la documentation.

Maximal leverage with libraries

Puissance maximale grâce aux bibliothèques

The fastest way to create a program is to use code that’s already written: a library. A major goal in Java is to make library use easier. This is accomplished by casting libraries into new data types (classes), so that bringing in a library means adding new types to the language. Because the Java compiler takes care of how the library is used—guaranteeing proper initialization and cleanup, and ensuring that functions are called properly—you can focus on what you want the library to do, not how you have to do it.

La façon la plus rapide de créer un programme est d'utiliser du code déjà écrit : une bibliothèque. Un des buts fondamentaux de Java est de faciliter l'emploi des bibliothèques. Ce but est obtenu en convertissant ces bibliothèques en nouveaux types de données (classes), et utiliser une bibliothèque revient à ajouter de nouveaux types au langage. Comme le compilateur Java s'occupe de l'interfaçage avec la bibliothèque - garantissant une initialisation et un nettoyage propres, et s'assurant que les fonctions sont appelées correctement - on peut se concentrer sur ce qu'on attend de la bibliothèque, et non sur les moyens de le faire.

Error handling

Traitement des erreurs

Error handling in C is a notorious problem, and one that is often ignored—finger-crossing is usually involved. If you’re building a large, complex program, there’s nothing worse than having an error buried somewhere with no clue as to where it came from. Java exception handling is a way to guarantee that an error is noticed, and that something happens as a result.

L'une des difficultés du C est la gestion des erreurs, problème connu et largement ignoré - le croisement de doigts est souvent impliqué. Si on construit un programme gros et complexe, il n'y a rien de pire que de trouver une erreur enfouie quelque part sans qu'on sache d'où elle vienne. Le traitement des exceptions de Java est une façon de garantir qu'une erreur a été remarquée, et que quelque chose est mis en oeuvre pour la traiter.

Programming in the large

Mise en oeuvre de gros projets

Many traditional languages have built-in limitations to program size and complexity. BASIC, for example, can be great for pulling together quick solutions for certain classes of problems, but if the program gets more than a few pages long, or ventures out of the normal problem domain of that language, it’s like trying to swim through an ever-more viscous fluid. There’s no clear line that tells you when your language is failing you, and even if there were, you’d ignore it. You don’t say, “My BASIC program just got too big; I’ll have to rewrite it in C!” Instead, you try to shoehorn a few more lines in to add that one new feature. So the extra costs come creeping up on you.

Beaucoup de langages traditionnels imposent des limitations internes sur la taille des programmes et leur complexité. BASIC, par exemple, peut s'avérer intéressant pour mettre en oeuvre rapidement des solutions pour certains types de problèmes ; mais si le programme dépasse quelques pages de long, ou s'aventure en dehors du domaine du langage, cela revient à tenter de nager dans un liquide encore plus visqueux. Aucune limite ne prévient que le cadre du langage est dépassé, et même s'il en existait, elle serait probablement ignorée. On devrait se dire : « Mon programme BASIC devient trop gros, je vais le réécrire en C ! », mais à la place on tente de glisser quelques lignes supplémentaires pour implémenter cette nouvelle fonctionnalité. Le coût total continue donc à augmenter.

Java is designed to aid programming in the large—that is, to erase those creeping-complexity boundaries between a small program and a large one. You certainly don’t need to use OOP when you’re writing a “hello world” style utility program, but the features are there when you need them. And the compiler is aggressive about ferreting out bug-producing errors for small and large programs alike.

Java a été conçu pour pouvoir mettre en oeuvre toutes les tailles de projets - c'est à dire, pour supprimer ces frontières liées à la complexité croissante d'un gros projet. L'utilisation de la programmation orientée objet n'est certainement pas nécessaire pour écrire un programme utilitaire du style « Hello world ! », mais les fonctionnalités sont présentes quand on en a besoin. Et le compilateur ne relâche pas son attention pour dénicher les bugs - produisant indifféremment des erreurs pour les petits comme pour les gros programmes.

Strategies for transition

Stratégies de transition

If you buy into OOP, your next question is probably, “How can I get my manager/colleagues/department/peers to start using objects?” Think about how you—one independent programmer—would go about learning to use a new language and a new programming paradigm. You’ve done it before. First comes education and examples; then comes a trial project to give you a feel for the basics without doing anything too confusing. Then comes a “real world” project that actually does something useful. Throughout your first projects you continue your education by reading, asking questions of experts, and trading hints with friends. This is the approach many experienced programmers suggest for the switch to Java. Switching an entire company will of course introduce certain group dynamics, but it will help at each step to remember how one person would do it.

Si on décide d'investir dans la POO, la question suivante est généralement : « Comment convaincre mes directeur / collègues / département / collaborateurs d'utiliser les objets ? ». Il faut se mettre à leur place et réfléchir comment on ferait s'il fallait apprendre un nouveau langage et un nouveau paradigme de programmation. Ce cas s'est sûrement déjà présenté de par le passé. Il faut commencer par des cours et des exemples ; puis lancer un petit projet d'essai pour inculquer les bases sans les perdre dans les détails. Ensuite passer à un projet « réel » qui réalise quelque chose d'utile. Au cours du premier projet, continuer l'apprentissage par la lecture, poser des questions à des experts et échanger des astuces avec des amis. Cette approche est celle recommandée par de nombreux programmeurs expérimentés pour passer à Java. Si toute l'entreprise décide de passer à Java, cela entraînera bien sûr une dynamique de groupe, mais cela aide de se rappeler à chaque étape comment une personne seule opérerait.

Guidelines

Règles de base

Here are some guidelines to consider when making the transition to OOP and Java:

Voici quelques indications à prendre en compte durant la transition vers la programmation orientée objet et Java.

1. Training

1. Cours

The first step is some form of education. Remember the company’s investment in code, and try not to throw everything into disarray for six to nine months while everyone puzzles over how interfaces work. Pick a small group for indoctrination, preferably one composed of people who are curious, work well together, and can function as their own support network while they’re learning Java.

La première étape comprend une formation. Il ne faut pas jeter la confusion pendant six ou neuf mois dans l'entreprise, le temps que tout le monde comprenne comment fonctionnent les interfaces. Il vaut mieux se contenter d'un petit groupe d'endoctrinement, composé de préférence de personnes curieuses, s'entendant bien entre elles et suffisamment indépendantes pour créer leur propre réseau de support concernant l'apprentissage de Java.

An alternative approach that is sometimes suggested is the education of all company levels at once, including overview courses for strategic managers as well as design and programming courses for project builders. This is especially good for smaller companies making fundamental shifts in the way they do things, or at the division level of larger companies. Because the cost is higher, however, some may choose to start with project-level training, do a pilot project (possibly with an outside mentor), and let the project team become the teachers for the rest of the company.

Une approche alternative suggérée quelquefois comprend la formation de tous les niveaux de l'entreprise à la fois, en incluant à la fois des cours de présentation pour les responsables et des cours de conception et de programmation pour les développeurs. Ceci est particulièrement valable pour les petites entreprises qui n'hésitent pas à introduire des changements radicaux dans leurs manières de faire, ou au niveau division des grosses entreprises. Cependant, comme le coût résultant est plus important, certains choisiront de commencer avec des cours, de réaliser un projet pilote (si possible avec un mentor extérieur), et de laisser l'équipe du projet devenir les professeurs pour le reste de l'entreprise.

2. Low-risk project

2. Projet à faible risque

Try a low-risk project first and allow for mistakes. Once you’ve gained some experience, you can either seed other projects from members of this first team or use the team members as an OOP technical support staff. This first project may not work right the first time, so it should not be mission-critical for the company. It should be simple, self-contained, and instructive; this means that it should involve creating classes that will be meaningful to the other programmers in the company when they get their turn to learn Java.

Tester sur un projet à faible risque qui autorise les erreurs. Une fois gagnée une certaine expérience, on peut soit répartir les membres de cette première équipe sur les autres projets ou utiliser cette équipe comme support technique de la POO. Le premier projet peut ne pas fonctionner correctement dès le début, il ne faut donc pas qu'il soit critique pour l'entreprise. Il doit être simple, indépendant et instructif : cela veut dire qu'il doit impliquer la création de classes qui soient compréhensibles aux autres programmeurs quand arrivera leur tour d'apprendre Java.

3. Model from success

3. S'inspirer de bonnes conceptions

Seek out examples of good object-oriented design before starting from scratch. There’s a good probability that someone has solved your problem already, and if they haven’t solved it exactly you can probably apply what you’ve learned about abstraction to modify an existing design to fit your needs. This is the general concept of design patterns, covered in Thinking in Patterns with Java, downloadable at www.BruceEckel.com.

Rechercher des exemples de bonnes conceptions orientées objet avant de partir de zéro. Il y a de fortes chances que quelqu'un ait déjà résolu le problème, et s'ils ne l'ont pas résolu exactement modifier le système existant (grâce à l'abstraction, cf plus haut) pour qu'il remplisse nos besoins. C'est le concept général des patrons génériques, couverts dans Thinking in Patterns with Java, téléchargeable à www.BruceEckel.com.

4. Use existing class libraries

4. Utiliser les bibliothèques de classes existantes

The primary economic motivation for switching to OOP is the easy use of existing code in the form of class libraries (in particular, the Standard Java libraries, which are covered throughout this book). The shortest application development cycle will result when you can create and use objects from off-the-shelf libraries. However, some new programmers don’t understand this, are unaware of existing class libraries, or, through fascination with the language, desire to write classes that may already exist. Your success with OOP and Java will be optimized if you make an effort to seek out and reuse other people’s code early in the transition process.

La motivation économique première pour passer à la POO est la facilité de réutilisation de code existant sous la forme de bibliothèques de classes (en particulier, les Bibliothèques Standard Java, couvertes tout au long de ce livre). On arrive au cycle de développement le plus court quand on crée et utilise des objets directement tirés des bibliothèques. Cependant, de nouveaux programmeurs ne saisissent pas ce point, ne connaissent pas l'existence de telles bibliothèques ou, fascinés par le langage, veulent réécrire des classes qui existent déjà. Le succès de la transition vers Java et la POO passe par des efforts pour encourager les gens à réutiliser le plus possible le code des autres.

5. Don’t rewrite existing code in Java

5. Ne pas traduire du code existant en Java

It is not usually the best use of your time to take existing, functional code and rewrite it in Java. (If you must turn it into objects, you can interface to the C or C++ code using the Java Native Interface, described in Appendix B.) There are incremental benefits, especially if the code is slated for reuse. But chances are you aren’t going to see the dramatic increases in productivity that you hope for in your first few projects unless that project is a new one. Java and OOP shine best when taking a project from concept to reality.

Ce n'est généralement pas le meilleur usage de son temps qu'on puisse trouver que de prendre du code existant et fonctionnel et de le traduire en Java (si on doit le transformer en objets, on peut s'interfacer avec du code C ou C++ en utilisant l'Interface Native Java - JNI - décrite dans l'annexe B). Il y a bien sûr des avantages à le faire, particulièrement si ce code est destiné à être réutilisé. Mais il y a de fortes chances pour qu'on passe à côté de la spectaculaire amélioration de productivité espérée sauf si ce premier projet en est un nouveau. Java et la POO sont mis en valeur quand on suit un projet de la conception à la mise en oeuvre.

Management obstacles

Les obstacles au niveau du management

If you’re a manager, your job is to acquire resources for your team, to overcome barriers to your team’s success, and in general to try to provide the most productive and enjoyable environment so your team is most likely to perform those miracles that are always being asked of you. Moving to Java falls in all three of these categories, and it would be wonderful if it didn’t cost you anything as well. Although moving to Java may be cheaper—depending on your constraints—than the OOP alternatives for a team of C programmers (and probably for programmers in other procedural languages), it isn’t free, and there are obstacles you should be aware of before trying to sell the move to Java within your company and embarking on the move itself.

Si on se situe du côté des responsables, le travail consiste à acquérir des ressources pour l'équipe, surmonter les obstacles pouvant gêner l'équipe, et en général tenter de fournir l'environnement le plus productif et agréable afin que l'équipe puisse accomplir ces miracles qu'on vous demande toujours de réaliser. Le passage à Java entre dans ces trois catégories, et ce serait merveilleux si de plus cela ne coûtait rien. Bien que le passage à Java puisse être moins onéreux - suivant les contraintes - que d'autres alternatives de POO pour une équipe de programmeurs C (et probablement pour les développeurs dans d'autres langages), ce coût n'est pas nul, et il y a des obstacles dont il faut être conscient avant de promouvoir le passage à Java à l'intérieur de l'entreprise et de s'embarquer dans la transition.

Startup costs

Coûts de mise en oeuvre

The cost of moving to Java is more than just the acquisition of Java compilers (the Sun Java compiler is free, so this is hardly an obstacle). Your medium- and long-term costs will be minimized if you invest in training (and possibly mentoring for your first project) and also if you identify and purchase class libraries that solve your problem rather than trying to build those libraries yourself. These are hard-money costs that must be factored into a realistic proposal. In addition, there are the hidden costs in loss of productivity while learning a new language and possibly a new programming environment. Training and mentoring can certainly minimize these, but team members must overcome their own struggles to understand the new technology. During this process they will make more mistakes (this is a feature, because acknowledged mistakes are the fastest path to learning) and be less productive. Even then, with some types of programming problems, the right classes, and the right development environment, it’s possible to be more productive while you’re learning Java (even considering that you’re making more mistakes and writing fewer lines of code per day) than if you’d stayed with C.

Le coût du passage à Java recouvre plus que l'acquisition d'un compilateur Java (le compilateur Java fourni par Sun est gratuit, cela n'est donc pas un obstacle). Les coûts à moyen et long terme seront minimisés si on investit dans la formation (et éventuellement dans la participation d'un consultant pour le premier projet), de même que si on identifie et achète des bibliothèques de classes qui résolvent les problèmes plutôt que de tenter de réécrire ces bibliothèques soi-même. Ce sont des investissements lourds qui doivent être relativisés dans une proposition raisonnable. De plus, il existe des coûts cachés dans la baisse de productivité liée à l'apprentissage d'un nouveau langage et éventuellement d'un nouvel environnement de développement. La formation et l'encadrement peuvent certainement les réduire, mais les membres de l'équipe devront mener leur propre combat pour maîtriser la nouvelle technologie. Durant cette phase ils feront plus d'erreurs (c'est prouvé, et les erreurs comprises constituent le meilleur moyen de progresser) et seront moins productifs. Cependant, avec certains types de problèmes, les bonnes classes et le bon environnement de développement, il est possible d'être plus productif pendant l'apprentissage de Java (même en considérant qu'on fait plus d'erreurs et qu'on écrit moins de lignes de code par jour) que si on en était resté au C.

Performance issues

Problèmes de performances

A common question is, “Doesn’t OOP automatically make my programs a lot bigger and slower?” The answer is, “It depends.” The extra safety features in Java have traditionally extracted a performance penalty over a language like C++. Technologies such as “hotspot” and compilation technologies have improved the speed significantly in most cases, and efforts continue toward higher performance.

Une question qui revient souvent est : « Est-ce que la POO ne rend pas obligatoirement mes programmes plus gros et plus lents ? ». La réponse est « Ca dépend. ». Les fonctionnalités de vérification introduites dans Java ont prélevé leur tribut sur la performance comparé à un langage comme le C++. Des technologies telles que le « hotspot » et les techniques de compilation ont significativement amélioré la vitesse dans la plupart des cas, et les efforts pour des performances accrues continuent.

When your focus is on rapid prototyping, you can throw together components as fast as possible while ignoring efficiency issues. If you’re using any third-party libraries, these are usually already optimized by their vendors; in any case it’s not an issue while you’re in rapid-development mode. When you have a system that you like, if it’s small and fast enough, then you’re done. If not, you begin tuning with a profiling tool, looking first for speedups that can be done by rewriting small portions of code. If that doesn’t help, you look for modifications that can be made in the underlying implementation so no code that uses a particular class needs to be changed. Only if nothing else solves the problem do you need to change the design. The fact that performance is so critical in that portion of the design is an indicator that it must be part of the primary design criteria. You have the benefit of finding this out early using rapid development.

Quand on se concentre sur le prototypage rapide, on assemble des composants aussi vite que possible en ignorant les problèmes liés à l'efficacité. Si on utilise des bibliothèques extérieures, celles-ci ont généralement été optimisées par leurs distributeurs ; de toutes façons ce n'est pas la préoccupation première quand on est en phase de développement rapide. Quand on dispose d'un système qui nous satisfait et s'il est suffisamment petit et rapide, alors le tour est joué. Sinon, on tente de mettre au point avec un outil de profilage, en cherchant en premier des améliorations qui peuvent être faites en réécrivant de petites portions de code. Si cela ne suffit pas, il faut chercher si on peut apporter quelques changements à l'implémentation sous-jacente afin qu'aucune classe particulière n'ait besoin de modifier son code. Il ne faut toucher à la conception que si rien d'autre ne résout le problème. Le fait que les performances soient si critiques dans cette phase de la conception est un indicateur que ce doit être un des critères essentiels de la conception. On a le bénéfice de s'en rendre compte relativement tôt en utilisant le prototypage rapide.

If you find a function that is a particular bottleneck, you can rewrite it in C/C++ using Java’s native methods, the subject of Appendix B.

Si on trouve une fonction qui soit un goulot d'étranglement, on peut la réécrire en C ou en C++ en utilisant les méthodes natives de Java, sujet de l'annexe B.

Common design errors

Erreurs classiques de conception

When starting your team into OOP and Java, programmers will typically go through a series of common design errors. This often happens due to insufficient feedback from experts during the design and implementation of early projects, because no experts have been developed within the company, and because there may be resistance to retaining consultants. It’s easy to feel that you understand OOP too early in the cycle and go off on a bad tangent. Something that’s obvious to someone experienced with the language may be a subject of great internal debate for a novice. Much of this trauma can be skipped by using an experienced outside expert for training and mentoring.

Quand l'équipe commencera la programmation orientée objet et Java, les programmeurs vont typiquement passer par une série d'erreurs classiques de conception. Ceci est souvent du à des retours insuffisants de la part d'experts durant la conception et l'implémentation des premiers projets, puisqu'aucun expert n'existe encore au sein de l'entreprise et qu'il peut y avoir des réticences à engager des consultants. Il est facile de se dire trop tôt qu'on maîtrise la POO et partir sur de mauvaises bases. Quelque chose d'évident pour une personne expérimentée peut être le sujet d'un débat interne intense pour un novice. La plupart de ces difficultés peuvent être évitées en utilisant un expert extérieur pour la formation.

\\\

Haut de page

///