Retour sur UML

UML n’est pas mal en soi, c’est plutôt l’écosystème qui gravite autour qui est problématique. Ainsi l’idée détestable qui avait court il y a quelques années : sans UML, impossible de mener un projet à terme. Hors les ayatollahs de l’UML sont les mêmes à vouloir générer du code à partir de leurs diagrammes, garantie quasi-obligatoire de code médiocre, de performances ridicules. Il suffit d’ajouter à cela un cycle en V et des EJB 2 pour être certain de finir dans le mur.

C’est donc avec un plaisir immense que je vois aujourd’hui scrum bénéficier de l’effet de mode qu’UML avait il y a quelques années. Et pourtant, grande différence : scrum est une méthode, alors qu’UML ne l’est pas. Le M n’était pas celui de la méthode mais celui de la modélisation. UML doit-il pour autant mourir ? non. C’est une bonne façon de dialoguer en se servant d’un langage commun et connu entre plusieurs interlocuteurs. Mais aussitôt tout le monde d’accord, le diagramme est jeté, et on passe au code… Le retour serait donc : en auxiliaire. pas plus. Et puis l’objet lui même commence à vaciller de sa domination qu’on pensait éternelle : la programmation fonctionnelle revient en force. La roue tourne, et ça c’est vraiment pas bon pour UML…

Java : passage par valeur ou par référence ?

Même si le langage java permet moins de choses que le C/C++ en ce qui concerne le passage de paramètres à une fonction, il semblerait que certains croient encore que java envoie les objets par valeur (c’est à dire avec une copie locale). L’élémentaire charité chrétienne m’empêche de montrer les sites qui se trompent, le plus simple étant de montrer un petit programme :

Class Reference :

package com.kernelsoft.translator;

public class Reference {

private int a;

private int b;

public Reference(int _a, int _b) {

this.a = _a;

this.b = _b;

}

public int getA() {

return a;

}

public void setA(int a) {

this.a = a;

}

public int getB() {

return b;

}

public void setB(int b) {

this.b = b;

}

public String toString() {

return getA() + ” ” + getB();

}

}

package com.kernelsoft.passage;
public class Reference {
private int a;

private int b;

public Reference(int _a, int _b) {

this.a = _a;

this.b = _b;

}
public int getA() { return a; }
public void setA(int a) { this.a = a; }
public int getB() { return b; }
public void setB(int b) { this.b = b; }

public String toString() {

return getA() + ” ” + getB();

}

}

Classe TryReference qui va faire le test :

package com.kernelsoft.passage;

public class TryReference {

public static void main(String[] args) {

TryReference tryRef = new TryReference();

tryRef.run();

}

public void run() {

Reference ref = new Reference(2,1);

System.out.println(ref);

changeValue(ref);

System.out.println(ref);

}

public void changeValue(Reference reference) {

reference.setA(5);

reference.setB(6);

}

}

En exécutant le programme on a

2 1

5 6

CQFD. Précisions, les primitives sont envoyées par valeur. Les tests avec les String sont à éviter car une instruction s = “foobar”; n’est pas une bonne façon de vérifier, car il  y a recréation de String locale.

“java efficace” de Joshua Bloch, un ouvrage indispensable

Toute personne versée dans la programmation Java devrait posséder un exemplaire de ce livre. J Bloch fut l’architecte des librairies de la plate-forme java. Il a conçu, implémenté et maintenu certaines des libs, et joué le rôle de consultant pour d’autres. C’est dire s’il connaît le langage et comment bien l’utiliser.

Son livre est très libre de ton et montre un bon recul sur le langage. Par exemple, en schématisant on pourra dire qu’il déconseille l’utilisation des finaliseurs et conseille de redéfinir clone(). En lisant le livre, vous aurez peut-être la même impression que moi : je croyais connaître, mais je ne connaissais pas vraiment…