On Mon, 20 Apr 2009 15:47:46 +0200 Nicolas Dumoulin <nicolas.dumoulin at cemagref.fr> wrote:
Là, c'est facile, j'ai trouvé une solution. Je demande juste votre validation avant de le commiter.
---------- Message transmis ----------
Sujet : [Simexplorer-si-devel] test d'égualité de la classe Entity Date : lundi 23 février 2009 De : Nicolas Dumoulin <nicolas.dumoulin at cemagref.fr> À : simexplorer-si-devel at lists.labs.libre-entreprise.org
Bonjour,
Dans la classe Entity, la méthode equals est surchargé et déclaré en final et définit le comportement d'identification d'une entité. Une entité est donc définie par l'identité de ses attributs n'étant pas listés dans l'attribut excludeFields. La méthode est élégante mais pose certains problèmes. En effet, deux entités peuvent par exemple avoir le même nom, mais ne représenteront pas la même entité. Je viens de me heurter à ce problème avec les constantes d'exploration. Deux composants distincts peuvent avoir chacun une constante nommé "a" de type "Double", ces deux constantes seront pour autant différentes. Hors la méthode ExplorationData.setConstantValue() écrasera la valeur de la première constante au moment d'enregistrer la seconde, en raison de l'utilisation de equals() par ExplorationData. findConstantValue(). Le problème pourrait aussi se présenter avec d'autres entités. Le problème vient du fait que la constant ne possède pas l'association inverse vers le composant père.
La résolution simple que je vois est de faire appel à System.identityHashCode pour redonner le comportement par défaut en utilisant le hashcode de la classe Object, et d'avoir donc dans ExplorationData : private ConstantValue findConstantValue(Constant c) { for (ConstantValue constantValue : constantValues) { if (System.identityHashCode(c) == System.identityHashCode(constantValue.getConstant())) { return constantValue; } } log.debug("Constant not found : " + c); return null; }
Qu'en pensez-vous ?
Tu as commité la modification et tout fonctionne bien ? Je ne sais pas si ta contrainte avait été exprimée au début du projet ? Si oui, il s'agit d'un oubli de notre part, moi je ne suis pas du tout au courant... Vu cette nouvelle contrainte exprimée, je ne trouve pas ça très naturel, car la méthode equals ne reflête plus l'égalité des objets et c'est pas bien :) Et le mot est faible :) violer l'égalité des objets exprimé par la méthode equals n'est vraiment pas du tout recommandé ! car on peut vite arriver à des effets incontrôlables : par exemple une telle violation peut rendre inutilisable du framework Collection de la jdk. Je suis peut-être un peu dramatique dans mon discours mais personnellement je modifierais la méthode equals pour quelle reflète l'égalité des objets ou bien il ne faut pas du tout modifier la méthodes equals et laissé celle définie dans le classe Object. Il faudrait au moins mettre un commentaire sur la méthode equals incriminée pour indiquer que l'ordre naturel n'est pas respecté sur l'objet... Au final si ta modification n'implique pas de régression c'est super mais à terme cela me parait assez risqué :) Cordialement, Tony.