Blogounage - Bonnes pratiques de programmation en Java - Commentaires

Bonnes pratiques de programmation en Java - Batmat

Batmat — Tue, 21 Apr 2009 22:18:09 +0200

> Donc, si j'ai bien tout compris HashMap et Vector doivent être utilisé si on a besoin d'une collection synchronized, exact?
Non. Il ne faut pas utiliser Vector.

Plus précisément, il faut toujours préférer l'utilisation de l'interface Map (via l'une de ses implémentations dont la plus connu est certainement HashMap effectivement). Et si tu as besoin de la même chose synchronisée, passe simplement ta Map à la méthode Collections.synchronizedMap() pour l'enrober dans une Map thread-safe.

> Et le fait de les utilisé sans ce besoin de synchronisme entraîne des pertes de performances, toujours exact?
Oui, c'est ça.

Bonnes pratiques de programmation en Java - DaveNull

DaveNull — Tue, 21 Apr 2009 21:17:38 +0200

Hello, merci pour ces infos.
Donc, si j'ai bien tout compris HashMap et Vector doivent être utilisé si on a besoin d'une collection synchronized, exact?
Et le fait de les utilisé sans ce besoin de synchronisme entraîne des pertes de performances, toujours exact?

Voilà, j'espère que mes questions étaieant pas trop bêtes.

Bonne continuation pour le site.

Bonnes pratiques de programmation en Java - Camel&on

Camel&on — Tue, 21 Jun 2005 16:03:49 +0000

Merci pour la réponse!

Effectivement, il est préférable en terme d'évolutivité d'avoir un code un chtouille moins performant mais mieux conçu.

Cependant (au risque de passer pour un casse-pied (mais c'est le but :)) ) quels critères permettent de dirent que Vector est mal conçu ? Est-ce parcequ'il a "loads of legacy operation" ? Je doit t'avouer que mes piètres compétences en anglais ont du mal a déchiffrer cette phrase ("Vector contient des méthodes héritées" ???).

Bonnes pratiques de programmation en Java - Batmat

Batmat — Thu, 09 Jun 2005 14:20:16 +0000

Alors :

tu as zappé une partie de la phrase qui me semble très importante et rejoins ce dont je parle dans le billet : If you need synchronization, a Vector will be slightly faster than an ArrayList synchronized with Collections.synchronizedList. But Vector has loads of legacy operations, so be careful to always manipulate the Vector with the List interface, or you won't be able to replace the implementation at a later time.

En français dans le texte : Vector est mal conçu, donc si on l'utilise, il faut prendre grande attention à ne pas le montrer. C'est la raison pour laquelle il ne faut pas l'utiliser dans l'absolu.

OK, il est dit que c'est légèrement plus rapide :

Je ne sais pas de quand date cette doc, mais j'aimerais être sûr que ce commentaire soit toujours d'actualité, notamment avec les améliorations très importantes annoncées pour Tiger.
L'éternel problème des performances... À ce sujet, je suis d'accord avec Vincent. Si tu es au millième de seconde et que tu as une problématique de fou-furieux en terme de perfs, c'est pas du Java qu'il faut faire, soyons clair. C'est un langage sans vm comme le C++ qu'il faut utiliser.

Pour moi, à considérer que les performances sont proches, dans la majorité des développements, il vaut donc bien mieux perdre ce millième de seconde et obtenir une plus grande qualité et cohérence du code que de vouloir gagner des temps insensibles pour le client (qui à part un informaticien vous fera chier parce qu'un programme met 0.2s, même 0.5s de plus à faire que ce qu'on lui demande ?).

Dans l'absolu, je préfère largement perdre ce temps à l'exécution mais gagner en maintenance et en réactivité des équipes de développement.

Bonnes pratiques de programmation en Java - Camel&on

Camel&on — Wed, 08 Jun 2005 17:10:32 +0000

Je sais que j'arrive un peu tard ! Mais je releve cette phrase sur le site de sun :

If you need synchronization, a Vector will be slightly faster than an ArrayList synchronized with Collections.synchronizedList.

http://java.sun.com/docs/books/tutorial/collections/implementations/list.html

Donc SI mon appli a besoin de la synchronisation (genre appli J2EE) il vaut mieux utiliser Vector. Non ?
Ce que je comprend moi ce que y a une classe pour la synchronisation et l'autre non, donc en fonction de nos besoins y a qu'a choisir !

[ping] Bonnes pratiques de programmation en Java - Blogounage

Blogounage — Tue, 14 Dec 2004 19:34:08 +0000

Best Practices in Java

This post is a translation of this one. Many people commented it at the moment at the moment it was published although it was only available to those who speak french. I found it very interesting to try and compare my opinion with the others. I though...

Bonnes pratiques de programmation en Java - Anubis

Anubis — Mon, 05 Jul 2004 15:24:45 +0000

Juste une petite chose à propos de tes Pouet, PouetImpl et PouetFactory... Tu aurais très bien pu faire une seule classe Pouet qui affichait « bonjour » tout simplement.

Je pense qu'il faut bien réfléchir au choix de faire une interface et une factory, 3 classes sont bien plus couteuses qu'1 seule pour une JVM. Déjà que l'on est en Java, il ne faut pas non plus faire de son PC un tracteur :D

Bien sûr, c'est très utile pour tout ce qui est classe utilitaire dont l'implémentation peut changer. Maintenant le concept objet de méthodes est bien souvent suffisant pour cacher une implémentation et les interfaces ne servent bien souvent qu'à définir plusieurs implémentations différentes d'un même « objet ». Ce concept est très souvent utilisé pour le développement de code externe (plugin).

Pour la cas des List par exemples, je ne vois pas d'autres intérêts que le regroupement de fonctionnalités dans l'AbstractList. Et qu'on ne me dise pas que ça permet de passer facilement d'un ArrayList à une LinkedList... Ce choix est normalement à faire en amont, bien avant d'attaquer le code.

Bonnes pratiques de programmation en Java - Batmat

Batmat — Fri, 02 Jul 2004 21:15:51 +0000

J'y pense, j'y pense. Mais pas à MLV, c'est trop loin de Toulouse :-). J'me verrais bien faire des tds en IUT.

J'aimerais surtout éviter que d'autres aient à subir des cours comme ceux de PC (un prof) où il nous faisait dériver la moindre classe pour l'utiliser...

Bonnes pratiques de programmation en Java - Syl

Syl — Fri, 02 Jul 2004 20:52:36 +0000

Hum! ça se sent que l'on a eu les même profs de Java et de Génie Log... Alors Batmat c'est pour quand que tu enseignes à MLV ?

Bonnes pratiques de programmation en Java - Batmat

Batmat — Thu, 01 Jul 2004 13:33:33 +0000

Doit-on faire une interface pour toutes les classes que l'on traite ? C'est à dire, doit-il toujours y avoir le couple Toto.java et TotoImpl.java ?

Je dirais que ça dépend de l'objet que tu implémentes, personnellement je ne le fais pas systématiquement. C'est peut-être d'ailleurs une erreur, j'attends les arguments pour et contre :), un blog est aussi fait pour réfléchir à plusieurs.

Disons que je le fais plutôt avec les objets fonctionnellement complexes que je prévois de faire évoluer ou d'améliorer.

Est-ce qu'il faut mettre en oeuvre un système de factory pour tous les objets que l'on traite ? Si non, comment faire la distinction entre les objets pour lesquels la factory est nécessaire de ceux pour lesquels elle n'est pas utile ?

Je dirais SYSTÉMATIQUEMENT lorsqu'on est dans le cas précédent : une interface publique et les implémentations censées être non utilisées ailleurs.

En résumé, de toute façon, quand on écrit du code (d'après moi), il faut toujours penser à celui qui va l'utiliser. Il faut penser bibliothèque publique. C'est pour ça que j'utilise personnellement toutes les ressources possibles du langage pour contraindre le « développeur utilisateur » de mon code à l'utiliser commme je l'ai prévu.

Par exemple, lorsque c'est possible, il peut être intéressant de mettre protected les constructeurs des classes qui ne sont pas destinées à une utilisation "publique", etc.

Quand j'écris une classe utilitaire, comme expliqué ci-dessus. Il est aberrant qu'on puisse l'instancier ou la dériver => je la mets final avec un constructeur privé. Une autre méthode couramment utilisée est de mettre une classe utilitaire abstract : mais en fait, ce n'est pas bon puisqu'on autorise sa dérivation (c'est le concept même d'une classe abstraite).

Voilà, j'espère que j'ai été clair.

Bonnes pratiques de programmation en Java - Nuwanda

Nuwanda — Mon, 28 Jun 2004 20:44:26 +0000

Bon je me lance... Tout d'abord c'est vachement bien expliqué, sisi c'est vrai...

Cependant, j'ai quelques questions :

Doit-on faire une interface pour toutes les classes que l'on traite ? C'est à dire, doit-il toujours y avoir le couple Toto.java et TotoImpl.java ?
Est-ce qu'il faut mettre en oeuvre un système de factory pour tous les objets que l'on traite ? Si non, comment faire la distinction entre les objets pour lesquels la factory est nécessaire de ceux pour lesquels elle n'est pas utile ?
Question personnelle : est-ce que tu peux me filer les source de ton projet Java Graphique ?

Par ailleurs, comme ce que tu écris est très clair, est-ce que tu pourrais faire un truc sur la reflection et le chargement dynamique ?

Merci !