|
Ecrit par Joshua Bloch, chef de projet chez Sun, « Java efficace » édité chez Vuibert regroupe de nombreux conseils de programmation applicables sur la plate-forme J2SE. Ce livre s’adresse à des personnes ayant déjà une certaine expérience du développement Java, on ne peut donc le conseiller à des débutants.
Le but de cet ouvrage est l’écriture de programmes clairs, robustes, flexibles et facilement maintenables. L’auteur a lui-même participé à l’élaboration de bibliothèques Java, il connaît particulièrement bien leur fonctionnement et nous explique pourquoi procéder de telle manière plutôt qu’une autre. De nombreux exemples de code sont inclus pour illustrer les conseils donnés, dont certains montrant ce qu’il ne faut pas faire.
Les recommandations, au nombre de 57, sont réparties en plusieurs chapitres : création et destruction d’objets, méthodes communes à tous les objets, classes et interfaces, équivalents pour constructions du langage C, méthodes, programmation générale, exceptions, threads et sérialisation. On y apprend entre autres comment bien redéfinir les méthodes equals, hashCode, pourquoi préférer les interfaces aux classes abstraites, la bonne gestion des exceptions…
En résumé, un très bon livre qui permet d’optimiser son code tout en comprenant pourquoi. Il est recommandé par James Gosling en personne, co-créateur du langage Java.
Des extraits gratuits du livre sont disponibles au format PDF sur http://java.sun.com/docs/books/effective/, ainsi que les codes sources présents dans le livre.
Sommaire
Création et destruction d'objets
- 1. Privilégier des méthodes de fabrique statiques aux constructeurs
- 2. Appliquer la propriété du singleton avec un constructeur privé
- 3. Empêcher l'instanciation avec un constructeur privé
- 4. Empêcher la duplication d'objets
- 5. Éliminer les références d'objets obsolètes
- 6. Éviter les finaliseurs
Méthodes communes à tous les objets
- 7. Obéir au contrat général lors d’une redéfinition de la méthode equals
- 8. Toujours redéfinir hashCode lorsque equals est redéfini
- 9. Toujours redéfinir toString
- 10. Redéfinir judicieusement clone
- 11. Envisager l'implémentation de Comparable
Classes et Interfaces
- 12. Restreindre l'accès des classes et de leurs membres
- 13. Favoriser l'immuabilité
- 14. Préférer la composition à l’héritage
- 15. Prévoir et documenter l'héritage ou bien l’interdire
- 16. Préférer les interfaces aux classes abstraites
- 17. N’utiliser les interfaces que pour définir les types
- 18. Favoriser les classes imbriquées statiques
Équivalents pour constructions du langage C
- 19. Remplacer les structures par des classes
- 20. Remplacer une union par une hiérarchie de classes
- 21. Remplacer les constructions enum par des classes
- 22. Remplacer les pointeurs de fonctions par des classes et des interfaces
Méthodes
- 23. Vérifier la validité d’un paramètre
- 24. Procéder à des recopies défensives en cas de besoin
- 25. Concevoir avec attention la signature d'une méthode
- 26. Utiliser la surcharge avec discernement
- 27. Renvoyer des tableaux vides plutôt que null
- 28. Écrire des commentaires de documentation pour tous les éléments exposés d’une API
Programmation générale
- 29. Minimiser la portée des variables locales
- 30. Connaître et utiliser les bibliothèques
- 31. Éviter float et double si un résultat exact est requis
- 32. Éviter les chaînes de caractères là où d'autres types sont plus appropriés
- 33. Attention à la performance dans la concaténation de chaînes de caractères
- 34. Faire référence à un objet via son interface
- 35. Préférer les interfaces à la réflexion
- 36. Utiliser judicieusement les méthodes natives
- 37. Optimiser judicieusement
- 38. Suivre les conventions de nommage généralement acceptées
Exceptions
- 39. N'utiliser une exception que dans des situations exceptionnelles
- 40. Utiliser une exception vérifiée pour une situation récupérable et une exception non vérifiée pour une erreur de programmation
- 41. Ne pas abuser des exceptions vérifiées
- 42. Préférer l'utilisation d’une exception standard
- 43. Lever des exceptions en rapport avec l’abstraction
- 44. Documenter toutes les exceptions levées par une méthode
- 45. Inclure l'information de contexte dans les messages détaillés
- 46. Garantir l'atomicité d’une erreur
- 47. Ne pas ignorer une exception
Threads
- 48. Synchroniser l'accès à toute donnée partagée et muable
- 49. Éviter toute synchronisation excessive
- 50. Ne jamais invoquer wait en dehors d’une boucle
- 51. Ne pas s'appuyer sur l'ordonnanceur de threads
- 52. Documenter la sûreté des threads
- 53. Éviter les groupes de threads
Sérialisation
- 54. Implémenter judicieusement Serializable
- 55. Envisager l'utilisation d’une sérialisation sur mesure
- 56. Rédiger la méthode readObject de manière défensive
- 57. Fournir une méthode readResolve lorsque cela est nécessaire
Annexes
- Bibliographie
- Index des idiomes et patterns
- Index
|
