Éviter les get/set de vos variables privés (sauf dans le cas ou vous avez besoin de faire un check en entrée ou une transformation en sortie) [...]
Ok.
[...] et remplacez les get/set par un accès direct à la variable.
Wow ! Non ! Tu expose le fonctionnement de ton objet, c'est vraiment pas génial comme fonctionnement.
Collection<String>ids=// initobj.ids=ids;obj.foo();ids.clear();// je viens de faire un clear() sur le champ ids de l'objet obj...obj.foo();// BOUM !
Au contraire on conseil de faire des recopies de sécurité dans les setter, mais le mieux c'est tout simplement d'éviter autant que possible les setters et d'utiliser des fonctions métier.
Bannir les génériques en cascade comme des Map de List de List Ne pas hésiter à créer des classes pour étaler ses idées simplement, puis tout factoriser dans le moins de classes possible une fois que la logique est là.
C'est bien. J'ajouterais juste que j'ai tendance à essayer d'utiliser les références les plus abstraites possibles. Mes fonctions prennent souvent des Collection en paramètre par exemple (sauf si j'ai besoin de quelque chose de plus précis).
D’autre part les Threads servent aussi à monter en performance en faisant des calculs en parallèles, [...]
[...] mais ça demande d’avoir un très gros niveau technique pour y arriver, car si c’est mal fait, ce ne sera pas plus rapide ou alors ça fera boom !
Personnellement, j'essaie toujours de bien comprendre l'organisation de mes threads. Lancer des threads via la classe Thread ne devrait AMHA presque jamais être fait par exemple.
Une fois j’ai remarqué qu’un for sur les caractères d’une chaine avec plein de if allait 11 fois plus vite qu’une petite regex qui m’a pris des heures à écrire. Ça ma mis en rage quand j’ai découvert ça.
Je ne comprends pas très bien ton exemple, mais est-ce qu'elle était compilée (ça sert à générer la machine à état une bonne fois pour toute ce qui prend pas mal de temps) ? Les regex ont un overead certain, mais sont meilleures quand tu commence à avoir des cas tordus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Merci
Posté par barmic . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 6.
Ton retour est super intéressant !
Mais j'ai quelques remarques :
Ok.
Wow ! Non ! Tu expose le fonctionnement de ton objet, c'est vraiment pas génial comme fonctionnement.
Au contraire on conseil de faire des recopies de sécurité dans les setter, mais le mieux c'est tout simplement d'éviter autant que possible les setters et d'utiliser des fonctions métier.
C'est bien. J'ajouterais juste que j'ai tendance à essayer d'utiliser les références les plus abstraites possibles. Mes fonctions prennent souvent des Collection en paramètre par exemple (sauf si j'ai besoin de quelque chose de plus précis).
Pas toujours, bien souvent avoir plus de threads que de CPU n'apporte pas grand chose. Je te propose de regarder la littérature autour de la programmation réactive (en vf il y a ça de pas mal : http://blog.octo.com/jusquou-peut-aller-un-simple-ordinateur-de-bureau-avec-une-application-web-java-reactive/).
Personnellement, j'essaie toujours de bien comprendre l'organisation de mes threads. Lancer des threads via la classe Thread ne devrait AMHA presque jamais être fait par exemple.
Je ne comprends pas très bien ton exemple, mais est-ce qu'elle était compilée (ça sert à générer la machine à état une bonne fois pour toute ce qui prend pas mal de temps) ? Les regex ont un overead certain, mais sont meilleures quand tu commence à avoir des cas tordus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)