Implémentation du pattern IoC

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.