Blogounage

C'est le genre de chose qu'il est sympathique d'avoir écrit en tête de ce type de fichier pour disposer de l'auto-complétion XML dans son IDE favori. Lorsque j'utilise un nouveau format XML, la première chose que je cherche est en effet à ajouter cet entête pour me faciliter la vie (et aux autres une fois commité :)).

Note : dans la liste ci-dessous, je ne mets pas le prologue XML pour gagner en concision. Toutefois, ça ne fait jamais pas de mal de le mettre, personnellement j'essaie de le mettre systématiquement.

Hibernate : mappings hbm.xml

Même s'il vaut mieux à mon avis passer aux annotations lorsqu'on en a la possibilité, voici une déclaration de DTD qui fonctionne chez moi pour ceux qui ont encore des mappings hibernate à la sauce XML :

<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" 

"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="net.batmat.domaine">

...

</hibernate-mapping>

Java Persistence : persistence.xml

Pour ceux qui utilisent Java Persistence, cette "sous-spécification" des EJB3 devenue une spécification autonome dans sa version 2 :

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xsi:schemaLocation="

                http://java.sun.com/xml/ns/persistence

                http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

        version="1.0">

...

</persistence>

Spring : fichier de contexte XML

Depuis la version 2, ils ont subdivisé leur format XML en différents namespaces. Voici un exemple fonctionnel qui met en œuvre un certain nombre de ces espaces de nommages XML. Je laisse en exercice le passage à Spring 2.5 (que nous utilisons, d'ailleurs, mais on n'a pas mis à jour le XML) ou l'ajout d'un autre namespace dont vous auriez besoin :-).

<beans xmlns="http://www.springframework.org/schema/beans"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xmlns:util="http://www.springframework.org/schema/util"

        xmlns:aop="http://www.springframework.org/schema/aop"

        xmlns:tx="http://www.springframework.org/schema/tx"

        xsi:schemaLocation="

                http://www.springframework.org/schema/beans

                http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

                http://www.springframework.org/schema/util

                http://www.springframework.org/schema/util/spring-util-2.0.xsd

                http://www.springframework.org/schema/tx

                http://www.springframework.org/schema/tx/spring-tx-2.0.xsd

                http://www.springframework.org/schema/aop

                http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">

...

</beans>

Maven : pom.xml

Celui-là, il est sacrément pratique vu la taille du truc :

<project xmlns="http://maven.apache.org/POM/4.0.0"

        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

                      http://maven.apache.org/maven-v4_0_0.xsd">

...

</project>

Voilà déjà pour cette fois. Une fois cet entête ajouté, dans Eclipse par exemple, tapez juste "<" quelque part et vous verrez la liste des balises apparaître et leur documentation si les auteurs l'ont indiquée (après qu'Eclipse ait pu récupérer le XSD sur Internet, bien sûr) :

Si vous en avez d'autres, n'hésitez pas à les poster (ou à les demander, si je suis dans un bon jour) dans les commentaires.

Depuis Java 5, les annotations ont été ajoutées. L'une des premières a été @Override, une annotation destinée à informer le compilateur que la méthode ainsi annotée redéfinit une méthode parente.

Le problème, c'est qu'en Java 5, cette annotation ne pouvait être utilisée que sur des méthodes en provenance d'une classe parente, pas d'une interface.

Je l'ignorais jusqu'à hier soir, mais en posant la question de la justification de ce choix d'implémentation sur ma liste de diffusion favorite, c'est mon ancien prof de Java et de Génie Logiciel qui m'a répondu que c'était possible depuis Java 6. Cf. le blog de Peter Ahé.

En clair :

public interface MonInterface

{

        void methode();

}



class MonImpl implements MonInterface

{

        // L'annotation suivante est valide depuis Java6, mais produit à la compilation le 

        // message suivant en Java5 :

        // "The method methode() of type MonImpl must override a superclass method"

        @Override

        public void methode()

        {

        }

}

Ça fait un outil de plus pour augmenter la qualité du code, en l'occurrence en diminuant le risque de se retrouver avec du code mort.

Via InfoQ, voici un article de Bruce Eckel sur l'informatique aujourd'hui.

Il commence par parler du "fascinant" 5% des programmeurs sont 20 fois plus productifs que les autres 95%., et élargit ensuite au monde de l'informatique : jeune, immature, ...

Note : Le titre de l'article de Bruce fait très certainement référence au célèbre livre "The Mythical Man-Month" de Frederick P. Brooks. C'est de ce livre qu'est issu la plus célèbre encore "loi de Brooks" :

Ajouter des ressources à un projet en retard le rend encore plus en retard

Je vous conseille aussi la lecture de cet ouvrage, ça se lit très bien et c'est très instructif.

When I saw the title of this entry in my feed reader, my first thought was who the f*** could be wondering if interfaces have semantics ?. Happily, that's not Gavin who thinks this.

The assertion is the following :

Interfaces in Java don't have any semantics attached. Only a concrete class can define the semantics of a method.

In my opinion, that's even what interfaces are designed for, defining semantics...

I totally agree with Gavin when he says semantics is defined in the Javadoc and the "name of the things". I always find myself taking a long time to carefully choose the naming of my objects, since I want those names to be the most meaningful possible (same for method parameters, method names, and so on. Naming meaninfully local variable is also important, but it goes beyond the scope of the current subject).

Using polymorphism let you see different implementations as the same thing, thanks to the defined contract. Maybe I'm only viewing interfaces throught the Liskov principle. But for me contract is a synonymous for semantics when it comes to programming, although I'd be glad to hear explanations of where it differs in your opinion.

Even more, I think that today, as everybody gets more and more used to using the dependency injection pattern, some concrete classes are not even known to the code they're used by. It's becoming common to use classes only through their interfaces only (services, for example). In those case, semantics resides in the interface only, and implementations obviously have to respect it very carefully.

Via Prendre un café, un petit test rigolo sur vos connaissances HTML4 :

Pas trop mal. J'ai honte d'avoir oublié de citer acronym, abbr que j'ai déjà pas mal utilisé, et toutes les balises des formulaires ;-).

Nous utilisons encore Struts 1 actuellement. Ce n'est normalement qu'une question de temps avant de passer à autre chose. Nous sommes sûrs de ne plus l'utiliser à terme. Nous connaissons donc notre source, mais pas encore la cible. Voici les nombreuses solutions qui s'offrent à nous :

• Struts 2
• GWT
• .Net
• Flex
• ...

Toutefois, je ne suis pas très chaud pour .Net ou Flex ou toute technologie qui nous contraigne forcément à passer par les WS pour accéder à nos services (développés en Java). Je suis réticent à devoir obligatoirement passer par une couche WS alors que nous pourrions garder du java de bout en bout, et ainsi économiser le marshalling/unmarshalling incessant qui va avec les WS, sans parler du problème de l'identification du graphe d'objets à sérialiser pour le renvoyer. Quoi qu'on en dise, utiliser systématiquement des WS n'est pas neutre et amène de nombreuses questions qu'on ne se pose jamais sinon (hein Séb...).

Donc, pour revenir au sujet, nous ne sommes pas encore fixés sur notre future couche présentation (ou plutôt nos futures couches de présentation). Pour le moment, nous avons donc décidé de continuer à fonctionner tant bien que mal Struts 1.x avec la version 2 du socle technique que nous sortons.

Or, la différence fondamentale entre notre version 1 et notre version 2 est que nous avons supprimé une "transformation" systématique entre deux couches. Auparavant, en effet, nos entités persistantes de couche DAO étaient systématiquement transformés en objet de couche service. Entre les deux couches, nous avions systématisé un bidouillage destiné à régler le problème que nous avons dans la couche Web dans la gestion des multiplicités 0..1.

La gestion du null de Struts 1.x

Avec Struts 1, si vous demandez par exemple le prénom d'un client null, vous n'aurez pas quelque chose de null, mais une exception. La question a été discutée il y a déjà un moment sur la liste de Struts et posée sur le tracker de Struts en février 2001 (quand je vous disais que ça faisait un moment), et Craig Mc Clanahan d'expliquer que le principe était que si vous vouliez afficher le prénom d'un client, eh bien il fallait protéger le code pour n'afficher le prénom que si le client est non null :

<logic:present name="beanname" property="client">

  <bean:write property="client.prenom"/>

</logic:present>

Si dans l'exemple ci-dessus, on met un champ de saisie à la place du <bean:write />, on est dans une impasse : certes, il n'y aura pas de plantage, mais il devient alors impossible de saisir le prénom du client puisque le textfield n'apparaîtra même pas...

Si votre objectif est de créer le client seulement si l'utilisateur a saisi des données (exemple : le formbean en cours gère un objet Facture qui a une multiplicité 0..1 vers un objet client), vous êtes obligé de créer dans votre FormBean un objet destiné à recevoir ces données. Le problème qui survient alors, c'est que si vous voulez conserver des objets "propres"^[1], vous devez ensuite vérifier l'instance de Client pour la remettre à null ou l'associer manuellement (si pas encore fait) à la Facture avant de transmettre la Facture à la couche service pour mettre à jour. Ouf...

La longueur de l'explication ci-dessus par rapport à la complexité de ce qu'il faut gérer me paraît parler d'elle-même. Et le code qu'il faut écrire pour gérer ce cas est toujours le même... :

1. avant affichage de la JSP : instancier les propriétés null pour pouvoir les afficher. Eh oui, rappel comme je l'ai dit plus haut : la demande de la propriété "a.b" déclenche une exception si a est null, il faut donc s'assurer que a est non null et l'instancier le cas échéant.
2. après soumission du formulaire de la JSP et avant de passer les données à la couche application : supprimer les objets 0..1 non modifiés dans la JSP.

Struts 2

Dans Struts 2, le premier point est géré différemment : la demande de "a.b" si a est null renvoie simplement null. Par contre, le deuxième point est toujours à gérer manuellement et plantera si on cherche à valoriser a.b.

Une étape a déjà été franchie, pourquoi ne pas aller plus loin ?

Une solution

Pourquoi ne pas instancier automatiquement a s'il est null lorsqu'on cherche à valoriser a.b ? La question se pose d'autant que nous ne sommes pas les seuls à nous être posés la question : ce patch apportait déjà les modifications nécessaires aux commons-beanutils (utilisé par Struts, c'est cette bibliothèque qui impose le comportement de lever une exception si une propriété imbriquée est demandée à l'intérieur d'un objet null)...

Une autre solution (sans patch, cette fois) intermédiaire a été proposée pour la partie "get" : mettre en place un handler externe pour gérer le cas des propriétés imbriquées (nested properties) dans un conteneur null. Cette solution est un intermédiaire intéressant parce qu'elle est très courte à implémenter et permet de faciler renvoyer null ou de lancer une autre exception dans le cas en question.

Cette deuxième solution ne gère toutefois que le cas get. Peut-être le même principe serait-il utilisable pour le "set". Cela permettrait de même de positionner une sorte de NestedSetterHandler qui pourrait s'occuper d'instancier les propriétés intermédiaires si besoin. Avec un fonctionnement de ce type, on pourrait même envisager de définir un handler qui serait observable afin de gérer à la fois l'instanciation "dynamique" et de pouvoir suivre les instanciations effectuées. C'est à creuser.

Ce mode de fonctionnement aurait toutefois quelques inconvénients : lorsqu'on instancie manuellement a, on sait qu'on risque de devoir l'enlever s'il n'est pas vraiment saisi avant de l'envoyer à la couche service. Et que faire si on décide de faire gérer ça en standard par le service ? Imaginons par exemple qu'une adresse ait été automatiquement instanciée pour un Client. À quel composant, à quelle couche, incombe le rôle de supprimer l'adresse créée dynamiquement si le fonctionnel indique qu'elle n'est pas correcte ?

Conclusion

Dommage que l'équipe de commons-beanutils soit peu réactive sur cette question à mon avis primordiale de gestion des propriétés. C'est aussi très dommage que l'idée d'avoir derrière la classe statique BeanUtils une instance de BeanUtilsBean ne soit pas poussée à son terme : en l'état, il est en effet impossible d'utiliser de façon transparente une sous-classe BeanUtilsBean qu'on aurait adaptée à ses besoins.

Je nous vois bien maintenir en interne une version patchée de commons-beanutils afin de résoudre le problème tant que nous utiliserons Struts 1, en espérant bien sûr que le patch en question soit finalement appliqué.

En même temps, il reste la question de la gestion de la suppression des propriétés instanciées dynamiquement. Mais je ne suis pas sûr que ce soit un véritable problème, c'est un code qu'il faut de toute façon écrire. Au final, il y a actuellement les deux points suivants à gérer :

1. instanciation manuelle pour gérer l'affichage ;
2. vérification des données et suppression des créations incorrectes si les données n'ont par exemple pas été saisies.

C'est à mon sens un point qu'il serait intéressant de creuser. Avec Struts 2 par exemple, écrire un Interceptor chargé de l'instanciation dynamique ferait l'affaire pour enlever le point 1 ci-dessus.

Le tout serait ensuite de définir un emplacement de choix pour faire la validation, puis la suppression des propriétés fonctionnellement "inacceptables". À part ce point, je ne vois aucun frein à cette évolution. Cette question se posant pour n'importe quel formulaire de saisie, le monde de l'informatique aurait à mon sens beaucoup à gagner à trouver un véritable pattern pour gérer ce cas...

Avec un peu de retard, je prends enfin le temps de faire un billet sur mon deuxième jour aux Tech Days. Cette journée a été très chargée, mais j'ai appris pleins de nouvelles choses. Évidemment, ce sont des choses à approfondir, mais je vais essayer de vous donner aussi envie de le faire. En cherchant un logiciel pour faire des vidéos de démo comme on en voit partout fleurir sur le net, je suis tombé sur Wink. C'est simplissime d'utilisation : avec ça, plus aucune excuse pour ne pas faire de vidéo explicative de l'installation ou d'une démo d'un logiciel (et on peut générer du flash ou un .exe pur windows).

Sun Technical Keynote

Cette introduction a été l'occasion de nous montrer le langage F3 : Form follows function, censé simplifier le développement d'interfaces graphiques. C'est vrai que la partie de la démo montrant comment mettre un fond en dégradé de rouge vers bleu vers jaune (ou d'autres couleurs) a montré que c'était effectivement très simple.

Speach VMWare

En tant que sponsor Platinium, VMWare a eu droit à un speach devant tout le monde. On nous a présenté ce qu'était VMWare, pour ceux qui l'ignoraient encore. Ça a été l'occasion de parler de Lab Manager, une sorte de dépôt central dans lequel on peut stocker des machines virtuelles et les lancer depuis des postes clients. Ça a l'air intéressant dans le cas des recettes par des équipes de tests. En effet, le syndrôme du Chez moi ça marche est effectivement connu de tout informaticien. Avec ce système qui simplifie le partage d'une configuration complète (du logiciel jusqu'à l'OS et sa configuration précise), il devient possible de débugguer un problème dans les conditions qui garantissent la reproductibilité, ce qui est la première difficulté pour un développeur : trouver les conditions permettant de reproduire le problème (essayez de corriger un problème que vous n'avez pas, pour voir !).

Java Jacket Give away

20 minutes pour un mini-show de 4 d'entre nous. Je n'ai pas osé y aller. J'ai eu une idée un peu tard, mais j'aurais dû la préparer la veille. Peut-être pour l'année prochaine :-).

Le gagnant a chanté une petite chanson sur Java et a donc gagné la veste en cuir avec le logo Java :-).

Java scripting: One VM, Many Languages

Cette session a été très intéressante. La démo de Guillaume Laforge m'a notamment donné envie de me mettre au Groovy, pour les apports en rapidité d'écriture par rapport au Java, l'ajout des fermetures, mais aussi pour sa proximité syntaxique et son intégration avec le Java. Ça peut en effet fonctionner directement avec la JVM, être mis dans un jar..., puisqu'on peut générer du pur bytecode Java. L'idée n'est pas de remplacer le Java, mais d'apporter une alternative plus puissante aux scripts shell et une syntaxe plus habituelle pour le développeur Java qui veut déployer un script de batch sur le serveur, par exemple.

Cette présentation a été l'occasion de découvrir la JSR223, la spécification qui permet d'intégrer n'importe quel langage de script à la plate-forme Java. Javascript l'est déjà (cf. la présentation flash plus bas), JRuby, Groovy, etc. En gros, l'architecture mise en place permet à n'importe qui d'intégrer n'importe quel langage de script en implémentant simplement les interfaces de la spéc (pensez à JDBC si vous ne voyez pas ce que je veux dire).

Code Quality issues: Prevention and Detection

C'est certainement l'une des sessions dans lesquelles je me suis senti le plus à l'aise, parce que j'avais déjà mis en place un grand nombre des outils cités. Ça a toutefois été l'occasion de découvrir de nouveaux outils (Selenium, notamment).

La présentation a commencé en citant Dijkstra : Testing can only show you bug presence, not their absence. Et c'est vrai que c'est bien de rappelant l'intérêt essentiel des outils de qualité de code... Ce n'est pas magique.

Pour résumer :

• Test unitaire : Junit, TestNg
• Couverture de code : Emma (+ pleins d'autres), ce type d'outil permet de savoir quelles parties de votre code ont été testées par les tests unitaires. En gros, vous lancez tous les tests de votre projet et l'outil monitore par où ça passe. Ensuite, vous pouvez généralement savoir quelles parties ont été testées, voire même lesquelles l'ont été plusieurs fois et d'autres une seule. La plupart de ces outils possèdent des plugins pour les principaux IDE qui permettent de voir graphiquement la couverture. Bien sûr, il existe aussi des plugins pour des outils comme Maven, permettant de sortir des statistiques.
• Montée en charge : JMeter, LoadRunner (j'ajouterais OpenSTA)
• Mock objects : EasyMock, JMock
• Qualité du code : PMD, Checstyle
• Test fonctionnel d'une webapp : Selenium
• P6Spy pour voir la valeur des "?" dans les requêtes SQL paramétrées.

TP : Les nouveautés de Java 6

Comme j'en ai parlé plus haut, il est possible d'interfacer la JVM avec d'autres langages. Avec Java 6, vous disposez de jrunscript, un interpréteur Ecmascript (javascript normalisé).

En voici une petite démo :(cliquez sur l'image pour voir la démo flash) :

JMX, Performance et concurrence

JMX

J'ai appris au cours de cette session que l'équipe de développement de JMX était située à Grenoble.

L'objet de cette session a été principalement de développer un MBean et de l'exposer via le MBeanServer. Ceux qui, comme moi, ont déjà développé un MBean et joué avec JConsole juste pour voir n'auront pas été surpris.

Par contre, j'en ai appris sur les différentes espaces mémoires de la JVM :

• Eden : c'est l'espace mémoire où les objets à courte durée durée de vie sont stockés (la plupart en général) ;
• Survivor : pour les objets qui ont une durée de vie un peu plus grande ;
• Tenured : ben euu, encore plus :-).

Autre chose que les conférenciers ont dit, je n'ai pas vérifié, mais à propos des options -client et -server :

• -client est toujours utilisé sous Windows, quelle que soit la machine
• -server est utilisé automatiquement sous Linux ou sous Solaris si la machine possède plus de 2Go de mémoire vive.

Truc génial : la possibilité de repérer des deadlocks avec un simple bouton ! (je crois que c'est un ajout dans le JConsole embarqué dans Mustang, parce que je ne me souviens pas de l'avoir dans Tiger).

JSR 262

La façon dont on accède à JMX, JMX Remote, n'est pas liée fortement à JMX. En effet, l'implémentation par défaut dans Java 5 est effectivement en RMI, mais il reste très faisable de permettre l'accès aux fonctionnalités d'un serveur JMX par n'importe quelle autre implémentation.

C'est justement l'objet de la JSR 262 : implémenter une couche WebServices d'accès à JMX. Comme il existe une norme appelée WS-Man qui n'est pas liée au Java. Cette implémentation permettra donc l'accès au management de la JVM d'une façon normalisée. WiseMan est ainsi l'implémentation Java de WS-Man.

Lors de la séance de Q/R, j'ai posé la seule question de ces deux jours à Paris : pourquoi n'y a-t-il pas pour les MBeans, de la même façon qu'il y a l'annotation @WebService pour les Webservices, une annotation @MBean qui indiquerait automatiquement aux MBeanServer quels sont les MBeans à exposer ? Éamonn McMannus a répondu que c'était une question qu'on leur posait souvent, et que c'était justement prévu.

Performance

Bon, ils ont parlé du classique StringBuffer à la place de concaténer des String. Attention : depuis la version 5 de Java, la classe StringBuilder est à privilégier : de la même manière qu'il est recommandé d'utiliser HashMap à la place de Hashtable, il faut utiliser StringBuilder dans un contexte qui ne nécessite pas de synchronisation. En effet, la synchro n'est pas gratuite, donc l'utiliser de façon systématique est une grave erreur.

Concurrence

Ils ont présenté la nouvelle API de gestion de la concurrence ajoutée au JDK5, encore peu connue.

Java Puzzle

Pour finir, on a eu droit à un Java Puzzle (en anglais, puzzled correspond à surpris, étonné), c'est un bout de code qui surprend ou pour lequel on n'a généralement pas une réponse évidente pour tout le monde :

public class PingPong {

    public static synchronized void main(String[] a) {

        Thread t = new Thread() {

            public void run() { pong(); }

        };

        t.run();

        System.out.print("Ping");

    }



    static synchronized void pong() {

        System.out.print("Pong");

    }

}

Qu'affiche ce bout de code ?

1. PingPong
2. PongPing
3. Ça varie

J'avoue sans honte que j'ai répondu correctement à cette question :-). Je mettrai la réponse dans les commentaires un peu plus tard (si personne d'autre ne le fait avant, d'ailleurs).

Franchement génial ce qu'on peut faire en trois coups de cuillère à pot grâce à Scriptaculous. J'avais fait, il y a un moment déjà, un petit test pour voir comment fonctionnait Ajax au marteau et au burin, sans aller bien loin. Ça avait donné ça.

Après en avoir entendu parlé un peu, ce soir, j'ai testé la bibliothèque Scriptaculous. Et voilà ce que ça donne. Franchement, en partant du wiki de scriptaculous, il m'aura fallu moins d'une heure, le temps de refaire un bout de php et trouver la fonction stristr à utiliser ! J'ai par ailleurs testé les effets (bibliothèque Effects) et c'est aussi très impressionnant : rien à faire ou presque et on peut tout de suite obtenir de superbes effets de fondus sur n'importe quel élément HTML.

Ajax en mode marteau/burin, j'y crois mais alors pas du tout. Faut être chtarbé pour envisager de faire coder à des dizaines de développeurs un truc aussi difficile à maintenir et à débugguer. Par contre, avec des bibliothèques comme celles-ci, ça devient tout de suite plus crédible. Toutefois, attention, comme c'est souvent rappelé, il ne faut pas s'emballer à en faire à bloc partout tout le temps : ça tape quand même beaucoup sur le serveur à coup de requêtes HTTP (exemple avec l'autocomplétion : à chaque lettre un échange avec le serveur est effectué, ben oui, c'est pas magique non plus), donc ça peut vite devenir gênant en terme de performance. Ne pas en abuser et à surveiller, donc.

Bravo pour cet outil si bien documenté et simple à utiliser, c'est pas toujours comme ça :-).

Il y a quelques temps, j'ai eu l'occasion de rencontrer un cas qui m'a donné à réfléchir sur la signification des suffixes anglais able et ed. En l'occurrence, le cas portait sur une classe qui dérivait en Java de ArrayList qui s'appelait SortedArrayList.

Cette classe ajoutait la possibilité de tri à sa super-classe ArrayList. Elle possédait pour ce faire la méthode sort(), et c'est justement ça que je le lui reprochais.

Le suffixe able signifie qu'un objet peut atteindre un état, sans y être nécessairement constamment, par l'appel par exemple d'une méthode qui lui fera atteindre cet état à un instant t. Pour une propriété X, le sufixe ed signifie quant à lui qu'un objet est constamment Xed.

C'est peut-être un peu abstrait comme ça, je vais donc illustrer avec la classe SortedArrayList dont j'ai parlé ci-dessus.

SortableArrayList et non SortedArrayList

Une classe en ed, comme sorted, est triée. Cela signifie qu'elle l'est constamment, en considérant un point de vue extérieur à l'objet : en interne, l'objet peut ne plus respecter l'état, mais au retour de la méthode, il doit y être revenu. Exemple : dans le corps d'une méthode add d'un conteneur trié, il peut se faire que l'objet soit non trié à un instant t, mais jamais au retour de la méthode add en question.

Toute action occasionnant une modification de son contenu doit laisser l'objet ...Sorted trié à l'issue de l'opération. Par exemple, un add sur un SortedSet en Java n'a pas besoin d'être suivi par un tri pour qu'une itération ultérieure sur l'instance se fasse toujours dans l'ordre de tri.

À l'inverse, un objet suffixé par able est par exemple Triable et non Trié, ce qui n'est pas du tout la même chose. Ainsi, une classe nommée SortableArrayList possédera une méthode sort() et l'ajout d'un objet à cette liste pourra ne pas forcément garantir que l'objet soit constamment dans un état trié. Il sera alors possible d'appeler la méthode sort() pour rétablir l'état trié au moment voulu.

Quand utiliser able ou ed ?

C'est assez simple. Je dirais que ça peut d'ailleurs souvent être lié à des questions de performances. Il sera en effet certainement plus coûteux de chercher à maintenir un état particulier constamment si ce n'est pas absolument nécessaire. Auquel cas, il semblera alors plus approprié d'utiliser le suffixe able et la méthode permettant de revenir à cet état.

Si par contre, vous avez souvent, voire toujours besoin d'accéder à l'objet alors que celui-ci est dans l'état voulu, utilisez le suffixe ed pour que toute opération touchant à la structure de l'objet conserve l'état à son retour.

Comme si un billet en appelait un autre :-).

Je suis en train d'effectuer la relecture de la traduction d'une documentation d'un framework Java très connu et je tombe sur une phrase qui me choque :

La classe identifiante doit surcharger equals() et hashCode() et implémenter Serializable

Je me dis que l'erreur vient peut-être de la version anglaise. Je vérifie immédiatement que non :

The identifier class must override equals() and hashCode() and implement Serializable.

Les équivalents anglais de surcharge et redéfinition sont overloading et overriding. C'est pourtant simple à se souvenir : overload contient le mot load, dont tout le monde sait, même les plus anglophobes, qu'il veut dire charge (ou charger, selon le contexte, bref).

Donc :

• Overload => Surcharge
• Override => redéfinition

Rappel

Surcharge (overload)

Il y a surcharge lorsqu'on utilise le même nom qu'une autre méthode, mais en changeant la signature des paramètres.

Exemple :

class MaClasse
{
   public void maMethode(int i) { ... }
   public void maMethode(float f) { ... }
}

Ici, la méthode maMethode est surchargée.

Redéfinition

On touche ici à ce qu'on appelle le polymorphisme. Un des apports de la POO qui permet d'appeler une méthode spécialisée dans une hiérarchie de classes. La redéfinition d'une méthode est étroitement liée à la notion de dérivation (ou d'héritage) et consiste à définir dans une sous-classe une méthode déjà définie dans une classe parente. La méthode en question doit posséder exactement la même signature, sinon ce n'est justement plus de la redéfinition, mais de la surcharge !

Exemple :

public class A
{
   public void direDesBetises()
   {
      System.out.println("Hey, ça foire fouille ?");
   }
}

public class B extends A
{
   public void direDesBetises()
   {
      System.out.println("Hey, vNr ?");
   }

   public void direDesBetises(String msg)
   {
      System.out.println("Alors, comme ça tu veux dire "+msg+" ?");
   }
}

Avec le code ci-dessus, le code main suivant affiche quoi d'après vous ?

public class Test
{
	public static void main(String args[])
	{
		A a = new A();
		B b = new B();		
		A ab = new B();
		
		a.direDesBetises();
		b.direDesBetises();
		ab.direDesBetises();
	}
}

Ici B.direDesBetises() est une redéfinition (override) de A.direDesBetises(). En plus, j'ai surchargé (overloaded) dans la classe B la méthode en question avec la méthode B.direDesBetises(String).

Résultat

baptiste@pumte:~/Temst$ java Test
Hey, ça foire fouille ?
Hey, vNr ?
Hey, vNr ?

Mon propos ici étant simplement de récapituler brièvement ce que sont surcharge et redéfinition en plus de rappeler la correspondance des termes français et anglais, je n'entrerai pas plus dans les détails. Si vous souhaitez en savoir plus, Vincent a par contre déjà écrit un article très complet sur le polymorphisme.