Vous êtes sur la page 1sur 8

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

24.04.2001 - version 5.5 - Nettoyage du code Html [Arme]. 26.06.2000 - version 5.4 - Insertion du journal de log. 21.06.2000 - version 5.3 - Corrections apportes par Jean-Pierre Vidal. 18.06.2000 - version 5.2 - Modification des tags <url: http://www.blahblah.com> en www.blahblah.com. - Modification des guillemets "" en . 10.06.2000 - version 5.1 - Premire publication sur eGroups.

C : Conseils pour une programmation style en Java


Cette annexe contient des conseils destins vous aider structurer vos programmes et crire le code source de ceux-ci.
Bien entendu, ce ne sont que des suggestions, en aucun cas des rgles suivre la lettre. L'ide ici est de s'en inspirer, tout en se rappelant que certaines situations imposent de faire une entorse aux rgles.

Conception
1. L'lgance est toujours rcompense. C'est vrai que cela peut prendre un peu plus de temps pour arriver une solution lgante du problme considr, mais les bnfices en sont tout de suite apparents (mme si personne ne peut les quantifier rellement) lorsque le programme marche du premier coup et s'adapte facilement de nouvelles situations plutt que de devoir se battre avec pendant des heures, des jours et des mois. Non seulement le programme est plus facile crire et dbugguer, mais il est aussi plus facile comprendre et maintenir, et c'est l que rside sa valeur financire. Ce point demande de l'exprience pour tre compltement assimil, parce qu'on est tent de se dire que la recherche d'un code lgant fait baisser la productivit. Se prcipiter ne peut que vous ralentir. 2. D'abord le faire marcher, ensuite l'optimiser. Ceci est vrai mme si on est certain qu'une portion de code est rellement importante et sera un goulot d'tranglement pour le systme. D'abord faire fonctionner le systme avec une conception aussi simple que possible. Ensuite le profiler s'il n'est pas assez rapide : on se rendra compte la plupart du temps que le problme ne se situe pas l o on pensait qu'il serait. Il faut prserver son temps pour les choses rellement importantes. 3. Se rappeler le principe Diviser pour mieux rgner . Si le problme considr est trop embrouill, il faut essayer d'imaginer quelles oprations ferait le programme s'il existait une entit magique qui prendrait en charge les parties confuses. Cette entit est un objet - il suffit d'crire le code qui utilise l'objet, puis analyser cet objet et encapsuler ses parties confuses dans d'autres objets, et ainsi de suite. 4. Sparer le crateur de la classe de l'utilisateur de la classe (le programmeur client).L'utilisateur de la classe est le client , il n'a pas besoin et ne veut pas savoir ce qui se passe dans les coulisses de la classe.

1 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

Le crateur de la classe doit tre un expert en conception et crire la classe de manire ce qu'elle puisse tre utilise mme par le plus novice des programmeurs, tout en remplissant efficacement son rle dans le fonctionnement de l'application. L'utilisation d'une bibliothque ne sera aise que si elle est transparente. Quand on cre une classe, essayer de choisir des noms explicites afin de rendre les commentaires inutiles. Le but est de prsenter une interface conceptuellement simple au programmeur client. Ne pas hsiter surcharger une mthode si cela est ncessaire pour proposer une interface intuitive et facile utiliser. L'analyse et la conception doivent fournir, au minimum, les classes du systme, leur interface publique et leurs relations avec les autres classes, en particulier les classes de base. Si la mthodologie de conception produit plus de renseignements que cela, il faut se demander si tout ce qui est produit a de la valeur pendant toute la dure du vie du programme. Si ce n'est pas le cas, les maintenir sera coteux. Les membres d'une quipe de dveloppement tendent oublier de maintenir tout ce qui ne contribue pas leur productivit ; ceci est un fait que beaucoup de mthodologie de conception ngligent. Tout automatiser. D'abord crire le code de test (avant d'crire la classe), et le garder avec la classe. Automatiser l'excution des tests avec un Makefile ou un outil similaire. De cette manire, chaque changement peut tre automatiquement vrifi en excutant les tests, et les erreurs seront immdiatement dtectes. La prsence du filet de scurit que constitue la suite de tests vous donnera plus d'audace pour effectuer des changements radicaux quand vous en dcouvrirez le besoin. Se rappeler que l'amlioration la plus importante dans les langages de programmation vient des tests intgrs fournis par la vrification de type, la gestion des exceptions, etc. mais que ces tests ne sont pas exhaustifs. Il est de votre responsabilit de fournir un systme robuste en crant des tests qui vrifient les fonctionnalits spcifiques votre classe ou votre programme. D'abord crire le code de test (avant d'crire la classe) afin de vrifier que la conception de la classe est complte. Si on ne peut crire le code de test, c'est qu'on ne sait pas ce quoi la classe ressemble. De plus, l'criture du code de test montrera souvent de nouvelles fonctionnalits ou contraintes requises dans la classe - ces fonctionnalits ou contraintes n'apparaissent pas toujours dans la phase d'analyse et de conception. Les tests fournissent aussi des exemples de code qui montrent comment utiliser la classe. Tous les problmes de conception logicielle peuvent tre simplifis en introduisant un niveau supplmentaire dans l'abstraction. Cette rgle fondamentale de l'ingnierie logicielle [85] constitue la base de l'abstraction, la fonctionnalit premire de la programmation oriente objet. Toute abstraction doit avoir une signification ( mettre en parallle avec la rgle no 9). Cette signification peut tre aussi simple que mettre du code frquemment utilis dans une mthode . Si on ajoute des abstractions (abstraction, encapsulation, etc.) qui n'ont pas de sens, cela est aussi futile que de ne pas en rajouter. Rendre les classes aussi atomiques que possible. Donner chaque classe un but simple et prcis. Si les classes ou la conception du systme gagnent en complexit, diviser les classes complexes en classes plus simples. L'indicateur le plus vident est bien sr la taille : si une classe est grosse, il y a des chances qu'elle en fasse trop et devrait tre dcoupe. Les indices suggrant la reconception d'une classe sont : 1. Une instruction switch complique : utiliser le polymorphisme ; 2. Un grand nombre de mthodes couvrant un large ventail d'oprations diffrentes : utiliser plusieurs classes ; 3. Un grand nombre de variables membres couvrant des caractristiques fondamentalement diffrentes : utiliser plusieurs classes. Eviter les longues listes d'arguments. Les appels de mthode deviennent alors difficiles crire, lire et maintenir. A la place, essayer de dplacer la mthode dans une classe plus approprie, et / ou passer des objets en tant qu'arguments. Ne pas se rpter. Si une portion de code est rcurrente dans plusieurs mthodes dans des classes drives, mettre ce code dans une mthode dans la classe de base et l'appeler depuis les mthodes des classes drives. Non seulement on gagne en taille de code, mais de plus les changements seront immdiatement effectifs. De plus, la dcouverte de ces parties de code commun peut ajouter des

2 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

15.

16.

17.

18.

19. 20.

21.

22. 23.

24.

25.

26.

fonctionnalits intressantes l'interface de la classe. Eviter les instructions switch ou les if-else enchans. Ceci est typiquement un indicateur de code vrificateur de type, ce qui implique qu'on choisit le code excuter suivant une information concernant le type (le type exact peut ne pas tre vident premire vue). On peut gnralement remplacer ce genre de code avec l'hritage et le polymorphisme ; un appel une mthode polymorphique se charge de la vrification de type pour vous, et permet une extensibilit plus sre et plus facile. Du point de vue de la conception, rechercher et sparer les choses qui changent des choses qui restent les mmes. C'est dire, trouver les lments du systme qu'on pourrait vouloir changer sans forcer une reconception, puis encapsuler ces lments dans des classes. Ce concept est largement dvelopp dans Thinking in Patterns with Java, tlchargeable www.BruceEckel.com. Ne pas tendre les fonctionnalits fondamentales dans les sous-classes. Si un lment de l'interface est essentiel dans une classe il doit se trouver dans la classe de base, et non pas rajout par drivation. Si on ajoute des mthodes par hritage, la conception est peut-tre revoir. Moins c'est mieux. Partir d'une interface minimale pour une classe, aussi restreinte et simple que possible pour rsoudre le problme, mais ne pas essayer d'anticiper toutes les faons dont la classe pourrait tre utilise. Au fur et mesure que la classe sera utilise, on dcouvrira de nouvelles fonctionnalits inclure dans l'interface. Cependant, une fois qu'une classe est utilise, son interface ne peut tre rduite sans perturber le code des classes clientes. S'il y a besoin d'ajouter de nouvelles mthodes, cela ne pose pas de problmes : on ne force qu'une recompilation du code. Mais mme si de nouvelles mthodes remplacent les fonctionnalits d'anciennes mthodes, il ne faut pas toucher l'interface (on peut toujours combiner les fonctionnalits dans l'implmentation sous-jacente si on veut). Si on veut tendre l'interface d'une mthode existante en ajoutant des arguments, crer une mthode surcharge avec les nouveaux arguments : de cette manire les appels la mthode existante n'en seront pas affects. Relire la hirarchie de classes voix haute pour s'assurer de sa logique. Les relations se lisent est-une entre classe de base et classe drives, et a-un entre classe et objet membre. Se demander si on a besoin de surtyper jusqu'au type de base avant de choisir entre hritage et composition. Prfrer la composition (objets membres) l'hritage si on n'a pas besoin du transtypage ascendant. Cela permet d'liminer le besoin d'avoir de nombreux types de base. Si l'hritage est utilis, les utilisateurs croiront qu'ils sont supposs surtyper. Utiliser des donnes membres pour le stockage des valeurs, et des redfinitions de fonctions pour des modifications de comportement. Autrement dit, une classe qui utilise des variables d'tat en conjonction avec des mthodes qui modifient leur comportement suivant la valeur de ces variables devrait tre repense afin d'exprimer les diffrences de comportement au sein de classes drives et de mthodes redfinies. Utiliser la surcharge. Une mthode ne doit pas se baser sur la valeur d'un argument pour choisir quelle portion de code excuter. Si le cas se prsente, il faut crer deux (voire plus) mthodes surcharges. Utiliser les hirarchies d'exceptions - prfrablement drives des classes spcifiques appropries de la hirarchie standard d'exceptions de Java. La personne capturant les exceptions peut alors capturer les types spcifiques d'exceptions, suivies du type de base. Si de nouvelles exceptions drives sont ajoutes, le code client continuera de capturer les exceptions travers le type de base. Un simple agrgat peut suffire pour accomplir le travail. Dans un avion, le confort des passagers est assur par des lments totalement indpendants : sige, air conditionn, vido, etc. et pourtant ils sont nombreux dans un avion. Faut-il crer des membres privs et construire une nouvelle interface ? Non dans ce cas, les lments font partie de l'interface publique ; il faut donc crer des objets membres publics. Ces objets ont leur propre implmentation prive, qui reste sre. Un agrgat n'est pas une solution frquemment rencontre, mais cela arrive. Se placer du point de vue du programmeur client et de la personne maintenant le code. Concevoir les classes afin qu'elles soient aussi videntes que possibles utiliser. Anticiper le type de changements qui seront effectus, et concevoir les classes afin de faciliter l'introduction de ces changements. Surveiller qu'on n'est pas victime du syndrome de l'objet gant . Ce syndrome afflige souvent les programmeurs procduraux nouvellement convertis la POO qui se retrouvent crire des programmes

3 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

27. 28.

29.

30.

31.

32.

33.

34.

35.

36.

procduraux en les encapsulant dans un ou deux normes objets. A l'exception des environnements de dveloppement, les objets reprsentent des concepts dans l'application et non l'application elle-mme. Si on doit incorporer une horreur au systme, au moins localiser cette horreur l'intrieur d'une classe. Si on doit incorporer une partie non portable, crer une abstraction pour ce service et le localiser l'intrieur d'une classe. Ce niveau supplmentaire d'abstraction empche la non-portabilit de s'tendre au reste du programme (cet idiome est repris par l'image du Pont). Les objets ne doivent pas seulement contenir des donnes. Ils doivent aussi avoir des comportements bien dfinis (occasionnellement, des objets de donnes peuvent tre appropris, mais seulement s'ils sont utiliss pour empaqueter et transporter un groupe d'articles l o un conteneur plus gnral ne rpondrait pas aux besoins). Privilgier la composition lorsqu'on cre de nouvelles classes partir de classes existantes. L'hritage ne doit tre utilis que s'il est requis par la conception. Si l'hritage est utilis l o la composition aurait suffi, la modlisation deviendra inutilement complique. Utiliser l'hritage et la redfinition de mthodes pour exprimer les diffrences de comportement, et des variables pour exprimer des variations dans l'tat. Un exemple extrme de ce qu'il ne faut pas faire est de driver diffrentes classes pour reprsenter des couleurs plutt qu'utiliser un champ couleur . Se mfier de la variance.Deux objets smantiquement diffrents peuvent avoir des actions ou des responsabilits identiques, et il est tentant de faire de l'une une sous-classe de l'autre pour bnficier de l'hritage. Ceci est appel la variance, mais il n'y a aucune raison d'instaurer une relation superclasse / classe drive l o il n'y en a pas. Une meilleure solution est de crer une classe de base gnrique qui produise une interface pour les deux classes drives - cela ncessite un peu plus de place, mais on bnficie toujours de l'hritage, et on va probablement faire une dcouverte importante concernant la modlisation. Eviter les limitations introduites durant un hritage. Les conceptions les plus claires ajoutent de nouvelles capacits des classes drives. Les conceptions suspectes enlvent des capacits durant l'hritage sans en ajouter de nouvelles. Mais les rgles sont faites pour tre transgresses, et si on travaille avec une ancienne bibliothque de classes, il peut tre plus efficace de restreindre une classe existante dans la classe drive que de restructurer la hirarchie afin que la nouvelle classe s'intgre l o elle devrait, c'est dire au dessus de la vieille classe. Utiliser les patrons de conception (design patterns) pour liminer les fonctionnalits non caches . C'est dire que si un seul objet de la classe doit tre cr, ne pas livrer la classe telle quelle l'application avec un commentaire du genre : Ne crer qu'un seul de ces objets. ; il faut l'encapsuler dans un singleton. Si le programme principal comporte trop de code embrouill destin crer les objets de l'application, rechercher un modle de cration, par exemple une mthode propritaire dans laquelle on pourrait encapsuler la cration de ces objets. Eliminer les fonctionnalits non caches rendra le code non seulement plus facile comprendre et maintenir, mais il le blindera aussi contre les mainteneurs bien intentionns qui viendront aprs. Eviter la paralysie analytique . Se rappeler qu'il faut avancer dans un projet avant de tout savoir, et que parfois le meilleur moyen d'en apprendre sur certains facteurs inconnus est de passer l'tape suivante plutt que d'essayer de les imaginer. On ne peut connatre la solution tant qu'on ne l'a pas. Java possde des pare-feux intgrs ; laissez-les travailler pour vous. Les erreurs introduites dans une classe ou un ensemble de classes ne peuvent dtruire l'intgrit du systme dans son ensemble. Faire une relecture lorsqu'on pense avoir une bonne analyse, conception ou implmentation. Demander une personne extrieure au groupe - pas obligatoirement un consultant, cela peut trs bien tre quelqu'un d'un autre groupe de l'entreprise. Faire examiner le travail accompli par un oeil neuf peut rvler des problmes durant une phase o il est plus facile de les corriger, et largement compenser le temps et l'argent perdus pendant le processus de relecture.

Implmentation
4 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

1. D'une manire gnrale, suivre les conventions de codage de Sun. Celles-ci sont disponibles java.sun.com/docs/codeconv/index.html (le code fourni dans ce livre respecte ces conventions du mieux que j'ai pu). Elles sont utilises dans la majeure partie du code laquelle la majorit des programmeurs Java seront exposs. Si vous dcidez de vous en tenir obstinment vos propres conventions de codage, vous rendrez la tche plus ardue au lecteur. Quelles que soient les conventions de codage retenues, s'assurer qu'elles sont respectes dans tout le projet. Il existe un outil gratuit de reformatage de code Java disponible home.wtal.de/software-solutions/jindent/. 2. Quelles que soient les conventions de codage utilises, cela change tout de les standardiser au sein de l'quipe (ou mme mieux, au niveau de l'entreprise). Cela devrait mme aller jusqu'au point o tout le monde devrait accepter de voir son style de codage modifi s'il ne se conforme pas aux rgles de codage en vigueur. La standardisation permet de passer moins de temps analyser la forme du code afin de se concentrer sur son sens. 3. Suivre les rgles standard de capitalisation. Capitaliser la premire lettre des noms de classe. La premire lettre des variables, mthodes et des objets (rfrences) doit tre une minuscule. Les identifiants doivent tre forms de mots colls ensemble, et la premire lettre des mots intermdiaires doit tre capitalise. Ainsi : CeciEstUnNomDeClasse, ceciEstUnNomDeMethodeOuDeVariable. Capitaliser toutes les lettres des identifiants dclars comme static final et initialiss par une valeur constante lors de leur dclaration. Cela indique que ce sont des constantes ds la phase de compilation. Les packages constituent un cas part - ils doivent tre crits en minuscules, mme pour les mots intermdiaires. Les extensions de domaine (com, org, net, edu, etc.) doivent aussi tre crits en minuscules (ceci a chang entre Java 1.1 et Java 2). 4. Ne pas crer des noms dcors de donnes membres prives. On voit souvent utiliser des prfixes constitus d'underscores et de caractres. La notation hongroise en est le pire exemple, o on prfixe le nom de variable par son type, son utilisation, sa localisation, etc., comme si on crivait en assembleur ; et le compilateur ne fournit aucune assistance supplmentaire pour cela. Ces notations sont confuses, difficiles lire, mettre en oeuvre et maintenir. Laisser les classes et les packages s'occuper de la porte des noms. 5. Suivre une forme canonique quand on cre une classe pour un usage gnrique. Inclure les dfinitions pour equals(), hashCode(), toString(), clone() (implmentation de Cloneable), et implmenter Comparable et Serializable. 6. Utiliser les conventions de nommage get , set et is de JavaBeans pour les mthodes qui lisent et changent les variables private, mme si on ne pense pas raliser un JavaBean au moment prsent. Non seulement cela facilitera l'utilisation de la classe comme un Bean, mais ce sont des noms standards pour ce genre de mthode qui seront donc plus facilement comprises par le lecteur. 7. Pour chaque classe cre, inclure une mthode static public test() qui contienne du code testant cette classe. On n'a pas besoin d'enlever le code de test pour utiliser la classe dans un projet, et on peut facilement relancer les tests aprs chaque changement effectu dans la classe. Ce code fournit aussi des exemples sur l'utilisation de la classe. 8. Il arrive qu'on ait besoin de driver une classe afin d'accder ses donnes protected.Ceci peut conduire percevoir un besoin pour de nombreux types de base. Si on n'a pas besoin de surtyper, il suffit de driver une nouvelle classe pour accder aux accs protgs, puis de faire de cette classe un objet membre l'intrieur des classes qui en ont besoin, plutt que driver nouveau la classe de base. 9. Eviter l'utilisation de mthodes final juste pour des questions d'efficacit.Utiliser final seulement si le programme marche, mais pas assez rapidement, et qu'un profilage a montr que l'invocation d'une mthode est le goulot d'tranglement. 10. Si deux classes sont associes d'une certaine manire (telles que les conteneurs et les itrateurs), essayer de faire de l'une une classe interne l'autre. Non seulement cela fait ressortir l'association entre les classes, mais cela permet de rutiliser le nom de la classe l'intrieur du mme package en l'incorporant dans une autre classe. La bibliothque des conteneurs Java ralise cela en dfinissant une classe interne Iterator l'intrieur de chaque classe conteneur, fournissant ainsi une interface commune aux conteneurs. Utiliser une classe interne permet aussi une implmentation private. Le bnfice de la
5 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

classe interne est donc de cacher l'implmentation en plus de renforcer l'association de classes et de prvenir de la pollution de l'espace de noms. Quand on remarque que certaines classes sont lies entre elles, rflchir aux gains de codage et de maintenance raliss si on en faisait des classes internes l'une l'autre. L'utilisation de classes internes ne va pas casser l'association entre les classes, mais au contraire rendre cette liaison plus explicite et plus pratique. C'est pure folie que de vouloir optimiser trop prmaturment. En particulier, ne pas s'embter crire (ou viter) des mthodes natives, rendre des mthodes final, ou stresser du code pour le rendre efficace dans les premires phases de construction du systme. Le but premier est de valider la conception, sauf si la conception spcifie une certaine efficacit. Restreindre autant que faire se peut les portes afin que la visibilit et la dure de vie des objets soient la plus faible possible. Cela rduit les chances d'utiliser un objet dans un mauvais contexte et la possibilit d'ignorer un bug difficile dtecter. Par exemple, supposons qu'on dispose d'un conteneur et d'une portion de code qui itre en son sein. Si on copie ce code pour l'utiliser avec un nouveau conteneur, il se peut qu'on en arrive utiliser la taille de l'ancien conteneur comme borne suprieure du nouveau. Cependant, si l'ancien conteneur est hors de porte, l'erreur sera reporte lors de la compilation. Utiliser les conteneurs de la bibliothque Java standard. Devenir comptent dans leur utilisation garantit un gain spectaculaire dans la productivit. Prfrer les ArrayList pour les squences, les HashSet pour les sets, les HashMap pour les tableaux associatifs, et les LinkedList pour les piles (plutt que les Stack) et les queues. Pour qu'un programme soit robuste, chaque composant doit l'tre. Utiliser tout l'arsenal d'outils fournis par Java : contrle d'accs, exceptions, vrification de types, etc. dans chaque classe cre. Ainsi on peut passer sans crainte au niveau d'abstraction suivant lorsqu'on construit le systme. Prfrer les erreurs de compilation aux erreurs d'excution. Essayer de grer une erreur aussi prs de son point d'origine que possible. Mieux vaut traiter une erreur quand elle arrive que gnrer une exception. Capturer les exceptions dans le gestionnaire d'exceptions le plus proche qui possde assez d'informations pour les traiter. Faire ce qu'on peut avec l'exception au niveau courant ; si cela ne suffit pas, relancer l'exception. Eviter les longues dfinitions de mthodes. Les mthodes doivent tre des units brves et fonctionnelles qui dcrivent et implmentent une petite part de l'interface d'une classe. Une mthode longue et complique est difficile et chre maintenir, et essaye probablement d'en faire trop par elle-mme. Une telle mthode doit, au minimum, tre dcoupe en plusieurs mthodes. Cela peut aussi tre le signe qu'il faudrait crer une nouvelle classe. De plus, les petites mthodes encouragent leur rutilisation l'intrieur de la classe (quelquefois les mthodes sont grosses, mais elles doivent quand mme ne raliser qu'une seule opration). Rester aussi private que possible . Une fois rendu public un aspect de la bibliothque (une mthode, une classe, une variable), on ne peut plus l'enlever. Si on le fait, on prend le risque de ruiner le code existant de quelqu'un, le forant le rcrire ou mme revoir sa conception. Si on ne publie que ce qu'on doit, on peut changer tout le reste en toute impunit ; et comme la modlisation est sujette changements, ceci est une facilit de dveloppement ne pas ngliger. De cette faon, les changements dans l'implmentation auront un impact minimal sur les classes drives. La privatisation est spcialement importante lorsqu'on traite du multithreading - seuls les champs private peuvent tre protgs contre un accs non synchronized. Utiliser les commentaires sans restrictions, et utiliser la syntaxe de documentation de javadoc pour produire la documentation du programme. Cependant, les commentaires doivent ajouter du sens au code ; les commentaires qui ne font que reprendre ce que le code exprime clairement sont ennuyeux. Notez que le niveau de dtails typique des noms des classes et des mthodes de Java rduit le besoin de commentaires. Eviter l'utilisation des nombres magiques - qui sont des nombres cods en dur dans le code. C'est un cauchemar si on a besoin de les changer, on ne sait jamais si 100 reprsente la taille du tableau ou quelque chose dans son intgralit . A la place, crer une constante avec un nom explicite et utiliser cette constante dans le programme. Cela rend le programme plus facile comprendre et bien plus facile

6 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

maintenir. Quand on cre des constructeurs, rflchir aux exceptions. Dans le meilleur des cas, le constructeur ne fera rien qui gnrera une exception. Dans le meilleur des cas suivant, la classe sera uniquement compose et drive de classes robustes, et aucun nettoyage ne sera ncessaire si une exception est gnre. Sinon, il faut nettoyer les classes composes l'intrieur d'une clause finally. Si un constructeur choue dans la cration, l'action approprie est de gnrer un exception afin que l'appelant ne continue pas aveuglment en pensant que l'objet a t cr correctement. Si la classe ncessite un nettoyage lorsque le programmeur client en a fini avec l'objet, placer la portion de code de nettoyage dans une seule mthode bien dfinie - avec un nom explicite tel que cleanup() qui suggre clairement sa fonction. De plus, utiliser un flag boolean dans la classe pour indiquer si l'objet a t nettoy afin que finalize() puisse vrifier la condition de destruction (cf Chapitre 4). La seule responsabilit qui incombe finalize() est de vrifier la condition de destruction d'un objet pour le dbuggage(cf Chapitre 4). Certains cas spciaux ncessitent de librer de la mmoire qui autrement ne serait pas restitue par le ramasse-miettes. Comme il existe une possibilit pour que le ramasse-miettes ne soit pas appel pour un objet, on ne peut utiliser finalize() pour effectuer le nettoyage ncessaire. Pour cela il faut crer sa propre mthode de nettoyage. Dans la mthode finalize() de la classe, vrifier que l'objet a t nettoy, et gnrer une exception drive de RuntimeException si cela n'est pas le cas, afin d'indiquer une erreur de programmation. Avant de s'appuyer sur un tel dispositif, s'assurer que finalize() fonctionne sur le systme considr (un appel System.gc() peut tre ncessaire pour s'assurer de ce fonctionnement). Si un objet doit tre nettoy (autrement que par le ramasse-miettes) l'intrieur d'une porte particulire, utiliser l'approche suivante : initialiser l'objet et, en cas de succs, entrer immdiatement dans un block try avec une clause finally qui s'occupe du nettoyage. Lors de la redfinition de finalize() dans un hritage, ne pas oublier d'appeler super.finalize()(ceci n'est pas ncessaire si Object est la classe parente immdiate). Un appel super.finalize() doit tre la dernire instruction de la mthode finalize() redfinie plutt que la premire, afin de s'assurer que les composants de la classe de base soient toujours valides si on en a besoin. Lors de la cration d'un conteneur d'objets de taille fixe, les transfrer dans un tableau - surtout si on retourne le conteneur depuis une mthode. De cette manire on bnficie de la vrification de types du tableau lors de la compilation, et le rcipiendiaire du tableau n'a pas besoin de transtyper les objets du tableau pour les utiliser. Notez que la classe de base de la bibliothque de conteneurs, java.util.Collection, possde deux mthodes toArray() pour accomplir ceci. Prfrer les interfaces aux classes abstract.Si on sait que quelque chose va tre une classe de base, il faut en faire une interface, et ne la changer en classe abstract que si on est oblig d'y inclure des dfinitions de mthodes et des variables membres. Une interface parle de ce que le client veut faire, tandis qu'une classe a tendance se focaliser sur (ou autorise) les dtails de l'implmentation. A l'intrieur des constructeurs, ne faire que ce qui est ncessaire pour mettre l'objet dans un tat stable. Eviter autant que faire se peut l'appel d'autres mthodes (les mthodes final exceptes), car ces mthodes peuvent tre redfinies par quelqu'un d'autre et produire des rsultats inattendus durant la construction (se rfrer au chapitre 7 pour plus de dtails). Des constructeurs plus petits et plus simples ont moins de chances de gnrer des exceptions ou de causer des problmes. Afin d'viter une exprience hautement frustrante, s'assurer qu'il n'existe qu'une classe non package de chaque nom dans tout le classpath. Autrement, le compilateur peut trouver l'autre classe de mme nom d'abord, et renvoyer des messages d'erreur qui n'ont aucun sens. Si un problme de classpath est suspect, rechercher les fichiers .class avec le mme nom partir de chacun des points de dpart spcifis dans le classpath, l'idal tant de mettre toutes les classes dans des packages. Surveiller les surcharges accidentelles. Si on essaye de redfinir une mthode de la classe de base et qu'on se trompe dans l'orthographe de la mthode, on se retrouve avec une nouvelle mthode au lieu d'une mthode existante redfinie. Cependant, ceci est parfaitement lgal, et donc ni le compilateur ni le systme d'excution ne signaleront d'erreur - le code ne fonctionnera pas correctement, c'est tout.

7 of 8

7/6/01 9:43 AM

C: Java Programming Guidelines

file:///D|/Daniel/TIJ2FR/All/AppendixC.htm

31. Ne pas optimiser le code trop prmaturment. D'abord le faire marcher, ensuite l'optimiser - mais seulement si on le doit, et seulement s'il est prouv qu'il existe un goulot d'tranglement dans cette portion prcise du code. A moins d'avoir utilis un profileur pour dcouvrir de tels goulots d'tranglement, vous allez probablement perdre votre temps pour rien. De plus, force de triturer le code pour le rendre plus rapide, il devient moins comprhensible et maintenable, ce qui constitue le cot cach de la recherche de la performance tout prix. 32. Se rappeler que le code est lu bien plus souvent qu'il n'est crit. Une modlisation claire permet de crer des programmes faciles comprendre, mais les commentaires, des explications dtailles et des exemples sont inestimables. Ils vous seront utiles autant qu'aux personnes qui viendront aprs vous. Et si cela ne vous suffit pas, la frustration ressentie lorsqu'on tente de dnicher une information utile depuis la documentation online de Java devrait vous convaincre.

[85]Qui m'a t explique par Andrew Koenig.

8 of 8

7/6/01 9:43 AM