Petit exemple, avec en plus du multi-projet

org.zeroturnaround
javarebel-maven-plugin

generate-rebel-xml
process-resources

generate

../core/target/classes

../editique/target/classes

En tout cas JRebel procure un véritable gain de temps au quotidien, seul petit regret la non-gestion des fichiers Webflow.
Officiellement car Webflow est censé le faire tout seul en mode developer, mais d’un avis purement personnel, l’auto redéploiement de webflow n’a vraiment rien à voir avec la qualité de celle de JRebel.

private boolean isA(Class clazz, Class class1) {
try {
clazz.asSubclass(class1);
} catch (ClassCastException cce) {
return false;
}
return true;
}

Autant je comprends et approuve fortement la première partie de l’article, autant je ne comprends pas l’utilité du pattern strategy dans ce contexte.

Quelle différence entre doAction(new Syso()); et new Syso().doAction(); ?

Le switch permet de relier un ensemble de valeurs à un ensemble d’exécutions. Si on dispose déjà de l’exécution, on n’est plus tellement dans le cadre d’un switch.

Ce billet m’a toutefois donné envie d’exposer une technique que j’utilise parfois en C# pour éviter la maintenance manuelle d’un “Map” centralisé : http://agilitateur.azeau.com/post/2010/07/01/Un-switch-%C3%A9volutif-en-C
Cela se base sur le concept d’attributs dans .NET
Je connais mal java mais est-ce que la gestion des “case” d’un “switch” via des annotations y serait possible ? Et aurait elle un intérêt ?

Concrètement, est-ce que l’on pourrait écrire quelque chose comme (syntaxe non garantie) :

@Case(“syso”)
public class Syso implements Action {
public void doAction() { System.out.println(“Yeah”); }
}

@Case(“syserr”)
public class Syserr implements Action {
public void doAction() { System.err.println(“Yahoo”); }
}

et avoir un mécanisme générique qui, étant donné une string “syso” ou “syserr” exécuterait le “doAction” correspondant ?

Je ne suis absolument pas d’accord avec ton article (enfin en partie).
Tout d’abord, si le switch existe depuis si longtemps, c’est peut être parce que c’est plus qu’une structure de contrôle; je veux dire, des optimisations sont faites derrière par le compilateur. (Certes, le Java est un cas légèrement différent de part sa VM, et je ne sais pas programmer dans ce dernier, mais je pense que mon post est quand même valable)

Actuellement, un swich avec beaucoup de cas différents est automatiquement remplacé (quand c’est possible) par un pointeur sur fonctions, justement pour éviter une batterie de if/else.

Je t’invite à lire cet article http://www.safercode.com/blog/2008/10/28/optimizing-switch-case-statements-in-c-for-speed.html qui parle de l’optimisation des switch/case en C.

Ensuite je voudrais parler de ton point sur le pattern “strategy”.
C’est un choix dangereux, car si ta classe est lourde, tu n’as pas forcément envie d’en faire X sous classes pour implémenter quelques stratégies, je pense donc que ce genre de patterns est à utiliser avec parcimonie.

De manière générale, il ne faut pas diaboliser les structures de contrôles if/else et switch.
Je pense qu’il serait plus approprié d’apprendre à les utiliser avec parcimonie, et surtout efficacité, car ils ont tous des avantages/désavantages selon les situations.

Un code contenant des switch et if/else n’est pas forcément difficile à maintenir (même si, ça à souvent l’air d’être le cas), ou compliqué à comprendre.

Voila, bonne journée à toi.

Un court article juste pour se souvenir qu’il ne faut pas écrire de gros switch, parce qu’il y a toujours un meilleur design pattern pour ça !…