Le projet sur lequel je travaille comporte des problèmes d’architecture que j’ai déjà évoqué dans mon billet précédent. Aujourd’hui, je souhaite aborder un autre problème de conception, qui concerne la répartition des responsabilités dans une classe.

Craig Larman nous conseille de respecter le principe de forte cohésion lorsqu’on défini les responsabilités que doit implémenter une classe. A une échelle inférieure, une méthode doit également respecter une certaine cohésion.

Pour être concret prenons l’exemple d’une méthode qui s’appellerait isValide() et supposons que l’implémentation de cette méthode nécessite d’effectuer une itération sur une liste. La tentation est de profiter du parcours de cette liste pour effectuer des traitements annexes “à la volée”, ce qui évite de parcourir la liste une deuxième fois. Dans notre cas, le contrat annoncé par la méthode isValide() consiste fournir la réponse à une question. Pour respecter la cohérence de la fonction, celle-ci doit se contenter strictement d’y répondre et rien d’autre. Tout traitement annexe vient polluer la méthode et rend son utilité moins évidente.

Le problème qu’on peut rencontrer est que cela peut aboutir à une duplication de code. Pour reprendre l’exemple d’une fonction qui implémente une itération sur une liste, on peut se retrouver à implémenter cette itération dans plusieurs méthodes pour respecter l’unitarité de chacune d’elle. Si cela pose des problèmes rédhibitoires de performance, la solution est de n’avoir qu’une seule itération et d’implémenter le pattern Observer pour effectuer plusieurs traitements sur les éléments de la liste.

La cohérence d’une fonction rend son utilité plus claire ce qui facilite la maintenance du code.

Je travaille actuellement sur un projet dans lequel nous avons besoin de manipuler des dates. Le projet est assez ancien, il date de plus de quatre ans, et à l’évidence, ceux qui ont écrit cette appli ne maîtrisaient pas très bien la programmation orientée objet. Et comme dans le même temps, très peu de documentation a été rédigée et que le projet a changé de domaine, je me retrouve tout seul à essayer de décrypter des lignes de code absconses et indigestes.

Je souhaite donc vous faire profiter d’un petit retour d’expérience afin d’améliorer la gestion des dates dans vos projets Java.

Petit rappel, il existe deux classes qui permettent de représenter une date dans l’api standard. Il s’agit de Calendar et Date, toutes deux dans le package java.util. Je ne traite pas ici du package java.sql.

Lorsque vous avez besoin de représenter une date en attribut d’une classe, je recommande l’utilisation de Date plutôt que Calendar. En effet, Date est un objet immuable (ou presque), il garanti qu’il ne sera pas modifié par mégarde et élimine les problèmes d’accès concurrent en cas de programmation multithread :

public class Personne {
    public final String nom, prenom;
    public final Date dateDeNaissance;
}

Faites attention lorsque vous initialisez une Date. Si vous utilisez le constructeur par défaut, la date sera initialisée avec pour valeur le nombre de milliseconde depuis le 1er janvier 1970. Le problème est que lorsque vous récupérez une deuxième Date par défaut et que vous les comparez toutes les deux, bien que ces deux dates correspondent au même jour calendaire, la comparaison échouera car la valeur en milliseconde sera différente.

Je recommande donc l’écriture d’une classe d’utilitaire qui permettra de manipuler les dates en adoptant une approche fonctionnelle :

public class CalendarUtil {
    private static final Calendar calendar = Calendar.getInstance();

    public static Date getDate(int jour, int mois, int année) {
    }
    public static Date getDate() {
        //retourne une date correspondant à la date courante (aujourd'hui)
    }
    public static Date incrementer(Date date, int jours) {
    }
    public static boolean equals(Date date1, Date date2) {
        //indique si deux dates correspondent au même jour calendaire
        //sans tenir compte des heures, minutes, secondes
    }
    public static int difference(Date date1, Date date2) {
        //retourne la différence en nombre de jours
    }
    public static boolean isEcheanceEchue(Date date, Periodicite period) {
    }
    public static String format(Date date, String pattern) {
    }
    [...]
}

Comme vous l’aurez constaté, cette classe d’utilitaire ne prend que des Date en paramètre. C’est en effet ma troisième recommandation et sans doute la plus importante. L’usage de Calendar doit être réservé aux calculs sur les dates, et donc être circonscrit à la classe CalendarUtil.

Je ne traite pas de la question des fuseaux et des locales, mais je recommande là encore une approche fonctionnelle

Par ailleurs, les plus perspicaces d’entre vous aurons remarqué que la méthode incrémenter() de CalendarUtil peut entrainer une conflit de signature. C’est le cas si l’on a besoin d’ajouter des mois ou des années à une date.

Dans ce cas, je recommande de suivre les préconisations de Stephan Schmidt :

public static Date incrementer(Date date, NbJours jours) {
}
public static Date incrementer(Date date, NbMois mois) {
}
public static Date incrementer(Date date, NbAnnees annees) {
}
public class NbJours {
    public final int value;
    public Jour(int value) {
        this.value = value;
    }
}
[...]

Ces recommandations, si elles sont suivies à la lettre, vous éviterons bien des soucis tel que je peux en rencontrer actuellement avec mon vieux projet. Dernier conseil qui va de soit, vous devrez évidemment tester unitairement chaque méthode de CalendarUtil.

Je vous annonce le lancement du projet CodeLang.

Il s’agit d’un projet extrêmement ambitieux qui vise à créer un metalangage permettant de retranscrire un document texte dans n’importe quel langage naturel, pourvu que ce langage soit supporté.

J’ai ce projet en tête depuis un certain nombre d’années, mais ce n’est que très récemment que m’est revenue la volonté de le mettre en oeuvre.

Ce projet ce compose en plusieurs phases.

Tout d’abord la rédaction d’une spécification détaillée du metalangage. En parallèle, un Modèle Conceptuel des Données précisera la structure de la base de données.

Puis lorsque les spécifications auront été rédigées, viendra la constitution des données elles-même. Ce travail sera le plus laborieux. J’envisage de le réaliser sur un mode collaboratif à l’instar de l’encyclopédie Wikipedia.

L’annonce de ce lancement se fait à un stade très embryonnaire du projet. Je dois dire que, compte tenu de l’ambition du projet, je ne peut pas affirmer avec certitude qu’il aboutira avec succès. Néanmoins, je pense avoir suffisamment muri le problème pour être convaincu de la pertinence de l’approche.

• http://code.google.com/p/codelang/

Google lance une véritable bombe thermonucléaire sur le monopole bien gardé de Microsoft. Les rumeurs couraient bon train depuis quelques mois, et même quelques années. Personnellement je n’y croyais pas car il me semble que Google s’éloigne de son coeur de métier, mais il faut avouer que je ne suis pas insensible à l’idée de voir un challenger de poids proposer une alternative sérieuse à Windows.

J’aime beaucoup le navigateur Chrome et j’ai hâte qu’il soit disponible en version stable pour Linux. Ce qu’ils ont fait avec Chrome montre que les ingénieurs de Google ont des idées neuves et le talent pour les mettre en oeuvre. Pour Chrome OS, le défi est d’une toute autre ampleur et l’ambition clairement affichée. Créer un OS fiable, rapide et conviviable. Je suis certain que les ingénieurs de Google sauront répondre à chacun de ces critères.

C’est une bonne chose que Google ait décidé de développer un OS spécifique pour le marché des PC car celui-ci a des exigences différentes en matière d’ergonomie que les téléphones portables. Cela permettra d’ailleurs aux équipes d’Android de concentrer leurs développements sur le marché très prometteur des terminaux mobiles, et aux équipes de Chrome OS de travailler sur l’ergonomie propre aux PC.

Google a une vision de l’informatique diamétralement opposée à celle de Microsoft. Il sera donc intéressant de voir la concrétisation de cette vision car elle apportera un regard nouveau sur notre relation à la machine. Microsoft base son modèle économique sur la notion de biens et de possession alors que Google met en avant les possibilités en matière de services et de mutualisation qu’offrent les réseaux. Il y a autant de différence entre le modèle économique de Microsoft et celui de Google qu’entre la notion d’économique primaire et tertiaire.

Je suis ravi que Google assume sans complexe son rôle de challenger de Microsoft car cela va mettre un terme à l’économie de rente qu’est devenue le marché des systèmes d’exploitation pour favoriser au contraire l’innovation.

Comme le titre l’annonce, j’ai livré une version intermédiaire qui ajoute le support des layouts managers. Il est donc possible de choisir son layout, ce qui n’était pas le cas auparavant.

Cette version corrige également un bug concernant le chargement des scripts groovy à partir d’une librairie externe.

Voila quelques semaines, j’avais décidé d’implémenter les CSS dans le framework Swinger. Je savais que je me lançais dans une tâche ardue. Je m’étais fixé comme objectif de livrer une version ce mois de juin.

Avec l’arrivée du mois de juillet, je dois dire que le choix du parser Batik est un échec, je ne serai pas en mesure de tenir les délais. La raison est que je me suis rendu compte à l’intégration que mon modèle ne collait pas avec celui de Batik. Je m’attendais à un parser plus facilement exploitable, en fait il a été développé dans une philosophie assez rigide et difficile à cerner car mal documentée.

Mais la vraie raison de cet échec est que je ne me suis pas donné suffisamment de temps pour étudier cette api. La conséquence est que je me retrouve confronté à une impasse. Je n’ai que deux options qui s’offrent à moi. Soit détricotter mon code pour me conformer aux attendus de Batik, soit abandonner cette api et développer mon propre parser.

C’est la deuxième option que je choisi. Pour plusieurs raisons. D’abord cela m’ennui de renoncer à plusieurs semaines de travail. Le code que j’ai produit est loin d’être parfait et devrait pêcher par manque de performance dans le cas de CSS très complexes. Mais il est bien à adapté à l’architecture de Swinger qui repose sur des Accessors qui attendent des chaînes de caractères pour l’initialisation des attributs.

L’autre raison qui me trotte dans la tête depuis deux ou trois semaines est que je souhaite que l’api Swinger puisse être intégrée comme bundle Osgi. Or dans ce cas, les librairies externes sont un handicap si elles ne sont pas elles-même livrées en tant que bundles.

Pour ces raisons, je n’ai pas de regret à me séparer de Batik. La conséquence est que cela va retarder sensiblement la livraison d’une version supportant les CSS. Du coup, je vais livrer dans les semaines qui viennent une version intermédiaire qui permettra de choisir son layout. C’était en effet le point de départ de ma réflexion sur la configuration des attributs apparents.

Je ne suis pas en mesure de fixer de date quand au support des CSS. Ce qui est certain est que ce support sera partiel et portera sur quelques attributs seulement. Les aspects les plus délicats, comme le positionnement relatif des composants, sera reporté à une version ultérieure. En tout état de cause, le support de CSS ne sera jamais complet car la philosophie de l’api swing ne permet pas par exemple de gérer le texte de la même manière qu’en html.

Sans fournir de date buttoir en raison des beaux jours dont je profite autant que possible, j’espère néanmoins finir mon parser avant la fin du mois de juillet.

Je vous tiendrai au courant de l’arrivée de la prochaine release dans les semaines à venir qui supportera la personnalisation des layouts.

Je n’ai pas encore pu commencer les tests d’intégrations car j’ai rencontré quelques soucis d’architecture. Je me suis rendu compte que l’ajout d’un attribut au modèle m’obligeait à reporter cette modification à chaque classe de composant, ce qui est évidemment aberrant. J’ai donc réécrit une partie de mon api en utilisant un Decorator ce qui rend l’architecture beaucoup plus saine. Cela va m’obliger à mener des tests de non-régression car ce refactoring n’est pas sans risque vu qu’il touche au coeur de l’api. J’espère néanmoins tenir les délais que je me suis fixé et livrer la version 0.5 avant la fin de ce mois de juin.

Cette livraison portera sur une implémentation basique de CSS avec le support de quelques attributs seulement. Je n’ai pas encore pris de décision définitive pour la configuration du layout. Ce qui est certain est qu’il sera finalement possible de le configurer dans le fichier xml, mais je ne suis pas sûr de vouloir ajouter une propriété non standard à CSS.

J’avais un temps envisagé d’ajouter une balise <layout>, mais à bien y réfléchir cela me poserai un problème. J’ai en effet l’intention d’implémenter XPath pour permettre d’explorer le modèle. Or permettre de récupérer des valeurs de type différent apporterai un niveau de complexité supplémentaire. Je réserve donc cette possibilité à une future release.

Après l’implémentation des CSS, la prochaine étape est la possibilité de définir le modèle des composants complexes comme JTree ou JTable. Là encore, je n’utiliserai pas de balise comme cela se fait avec les tableaux HTML. La définition du modèle se fera dans un premier temps avec un format de fichier texte du type CSV, puis avec un format XML dans une release ultérieure.

J’ai eu le temps dans le train de réfléchir à quelques problèmes qui s’annoncent dans l’évolution à venir de Swinger. Jusqu’à présent, j’ai laissé de côté les composants complexes de Swing tels que les JTree ou encore les JTable. La raison est que cela nécessite de pouvoir spécifier des valeurs à insérer dans le model comme dans le cas des tables en HTML. J’avais commencé à introduire une balise <item> qui était utilisée pour les JList, mais je suis finalement revenu en arrière car l’approche n’était pas la bonne. Les items ne font pas partie de la couche Vue mais de la couche Model. Il n’était donc pas judicieux de traiter communément ces deux types d’élément.

La solution que j’adopterai du point de vue du langage sera l’introduction des namespaces. Ils permettront d’identifier les différentes couches de l’api Swing. Du point de vue de l’implémentation, je suis toujours confronté à la nécessité de différencier les traitements associés à ces couches. Pour cela, j’adopterai une implémentation simplifiée du pattern Inversion of Control.

Prenons comme hypothèse de départ que vous êtes en présence d’une architecture dans laquelle l’implémentation d’une responsabilité varie selon le type de composant passé en paramètre.

Plutôt que d’implémenter la responsabilité dans une seule méthode avec des vérifications de casting, je dispatch la responsabilité dans des méthodes différentes selon le type d’objet à traiter, et je délègue l’appel de la méthode idoine au niveau des composants subalternes.

Typiquement, l’implémentation sera celle-ci :

public class Child1 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method1();
    }
}

public class Child2 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method2();
    }
}

Cette approche me permettra de conserver le caractère modulaire de Swinger. Tout type de composant pourra être ajouté à un parent, ça sera le composant fils qui déterminera de quel manière il sera ajouté à son parent. Actuellement, seule la méthode Container.add() est utilisée. Avec cette nouvelle architecture, il sera même possible d’ajouter un layout à un conteneur grâce à une balise. Je rappelle que c’est ce problème qui m’avait amené à l’origine à implémenter CSS. Je n’ai pas pour autant l’intention d’abandonner CSS car je pense que cela apportera une plus grande simplicité dans la création d’IHM.

J’ai presque terminé de développer mon modèle CSS. Il me manque néanmoins deux parties importantes, la distinction entre les différents type de valeurs : valeurs spécifiées, calculées et réelles, ainsi que le traitement des différents type de sélecteurs.

En revanche, l’héritage et la cascade sont entièrement implémentées, il ne me reste plus qu’à terminer quelques tests unitaires. C’est la classe CSS2EngineImpl qui a la responsabilité de la cascade et de l’héritage. Elle collabore avec les classes StyleRule.SelectorMessenger et Value pour le calcul de la spécificité des sélecteurs et de la prévalence des valeurs dans l’ordre de la cascade.

La réalisation des tests d’intégration prendra plus de temps car il me faut encore raccorder le parser CSS avec le modèle CSS. Je pense que je me contenterai d’une implémentation élémentaire du DOM en ne définissant que les méthodes qui sont effectivement appellées.

Enfin, la partie qui s’annonce la plus longue est la plus rébarbative est le support des divers propriétés CSS. Je me contenterai dans un premier temps des propriétés basiques comme la couleur, les dimensions et la position des composants. J’ajouterai une propriété non standard : layout, puisque c’est pour cette raison que j’ai implémenté le support de CSS.

Lorsque j’aurai terminé ces différents points, je publierai la version 0.5, si tout se déroule bien dans le courant du mois de juin.

C’est devenu la grande question du jour. La constatation de base est qu’Internet n’a pas été prévu pour supporter toutes les applications qu’il accueille actuellement. Les problèmes soulevés sont en grande partie liée à la sécurité des divers protocoles applicatifs, qu’il s’agisse de dns, https, etc…mais aussi des protocoles bas niveau sur lesquelles sont basés toute l’architecture des réseaux modernes comme tcp/ip.

Nous pouvons distinger deux catégories de protocoles. Ceux qui n’ont pas pris en compte les questions de sécurité, on pense en particulier à dns et http entre autre. Parmis les protocoles qui remontent au-delà des orgines du Web, tcp/ip non plus n’a pas été conçu dans le but de garantir l’identité de ses usagers mais de garantir la robustesse des canaux de communication. Puis il y a ceux qui sont venus se juxtaposer aux protocoles existants dans le but de pallier à leurs défaillances en terme de sécurité, je pense en particulier à https, mais aussi à des protocoles plus sensibles comme ssh, utilisé dans le monde professionnel.

Le problème est que ces protocoles additionnels sont tous des protocoles applicatifs qui se placent au-dessus des protocoles réseau comme tcp/ip. Ils ne résovent que partiellement les failles inhérantes à l’architecture du réseau. D’autant plus partiellement que la sécurité des protocoles modernes utilisent des systèmes de cryptage assymétrique dont le fondement repose sur la faiblesse supposée des moyens de calcul de l’attaquant. Ce fondement n’est justifié que si le protocole de cryptage est parfaitement robuste, ce qui n’est jamais le cas dans la réalité. Autre problème, l’authentification par mot de passe présente une limite humaine quant à la longueur et la complexité des mots de passe, tandis que les moyens de calcul des attaquants augmentent régulièrement selon la loi de Moore.

Alors, Internet est-il cassé ?

Tout d’abord, nous devons bien distinguer les usages d’Internet, parmis lesquels le Web ou la messagerie, d’Internet lui-même. Le changement d’architecture d’Internet ne devrait théoriquement pas impacter les usages qui en sont fait.

Maintenant que cette distinction est posée, il faut bien admettre que les problèmes de sécurité sont de plus en plus préoccupant ou du moins brident les usages d’internet. Malheureusement, aucun système ne peut garantir une fiabilité à 100%. Cette loi est bien connue des informaticiens, elle a été énoncée et prouvée par Alan Turing dans les années 30. Plus précisément, cette loi énonce qu’il est impossible de prévoir si et quand un algorithme complexe s’arrêtera. En clair, il est impossible de savoir si un problème posé sera un jour résolu.

Il est intéressant de noter l’approche révolutionnaire, pour ne pas dire nihiliste des américains qui tend à ignorer l’énoncé de Turing, et l’approche progressiste des européens qui considère que conserver l’architecture existante présente l’avantage de déjà en connaître les principales failles (sans savoir néanmoins si nous pourrons les colmater).

• http://pisani.blog.lemonde.fr/2009/05/24/internet-%c2%ab-pas-besoin-de-revolution-%c2%bb-disent-les-europeens/