L’adaptation, c’est l’avenir

Il y a des années, sur le blog de Manageability, j’ai découvert le pattern Universal Adapter d’Eclipse.
Pendant des années, j’ai trouvé que c’était de la sorcellerie pure. Sans doute que je n’étais pas encore allé assez loin dans les arcanes du Java.
En tout cas, il y a deux, j’ai été confronté à un problème (que j’ai hélas oublié) pour lequel c’était une solution pas loin d’être parfaite.
Alors, avec mes petits camarades de jeu de l’époque, nous avons défini notre propre interface adaptable :

 

 

Comme vous le voyez, elle est deux fois plus grosses que l’interface originale. Elle fournit cependant un gadget bien pratique : la méthode canAdapt qui nous permet d’éviter la lancée d’exceptions tous les quatre matins. Parce qu’en fait, parfois, on veut adapter quelque chose qui n’est pas adaptable. Et dans ces cas-là, appeler tout de suite getAdapter ne peut conduire qu’à une chose : une belle exception.

 

C’était bien pratique, mais en fait pas encore assez, puisqu’il manque plusieurs choses :
  • un adapteur (au sens MouseAdapter, par exemple) pour nous faciliter la vie. Je l’ai implémenté récemment (mais son code est peut-être un peu long). L’idée est assez simple : si dans votre classe vous écrivez des méthodes < UnType > UnType toUnType() {…}, il me semble assez naturel de considérer que ces méthodes sont des adapteurs pour la classe UnType, non ? Donc, avec un peu d’introspection, je détecte ces méthodes, je les associe dans une bête Map d’UnType, et je peux du coup très facilement vous transformer votre objet en un objet UnType en vous faisant faire seulement le boulot intéressant. Pratique, non ?
  • Une classe adaptant les inadaptables (ça sonne un peu @humourdedroite, ça, non ?). Bon, ça, c’est vraiment trivial, hein, s’agit d’une espèce de classe magique type Registry d’IoC associant des types d’entrée et des types de sortie. Cet objet serait, à grands coups d’appels à reflections, remplie d’instances d’une interface Adapter définie un peu comme ça :

 

Bien sûr, on y trouverait aussi les adaptations « naturelles » fournies par Adaptable. Et, finalement, l’utilisateur pourrait y ajouter les siennes.
Avec ça, les histoires de cast, franchement, ce ne sont plus que des souvenirs. En fait, quand on utilise ça, la seule chose qui importe, c’est que tous les objets soient adaptables. Et d’un coup, la vie devient plus facile. Je le sais, je l’ai déjà fait.
Ah, vous savez pas à quoi ça sert ? Ben par exemple, vous récupérez un objet du domaine, vous lui demandez si il peut se transformer en JComponent (rassurez-vous, lui ne sait pas faire cette transformation, mais quelque part il y a cette fameuse Registry qui le sait, et elle est injectée dans votre objet qui s’en sert dans les cas où il ne sait pas s’adapter directement). Et d’un coup, votre code devient limpide :

 

 

Enfin, limpide, pour peu qu’il n’y ait pas trop de bordel dans les écouteurs d’événements du composant représentant l’objet.

 

La prochaine fois, si j’ai le courage, je vous parlerai de l’étrangement nommé ConfigurationStore.
Publicités

Une réflexion sur “L’adaptation, c’est l’avenir

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s