 |
|
1) Introduction sur les « objets » |
|
|
|
|
| Texte original |
|
Traducteur :
Jérome Quelin |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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é [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 [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.
|
|
|
|
|
|
|
|
|
|
|
|
|
