Ou comment petit à petit, ne plus vouloir crééer de classes...

Jeune et innocent

Lors de mes études universitaire, la programmation objet avait fortement le vent en poupe. Les langages procéduraux qui en était dépourvu comme PHP les intégraient doucement, même les langages fonctionnels y prenaient gout, comme ML avec par exemple OCAML. Bref, il semblait difficile de remettre en question les avantages du paradigme objet. C’est qu’on nous promettait le Graal. Meilleure modularité, regroupement du code logique, meilleur contrôle, façon de penser plus naturelle... Bref,à l’époque, sans (trop de) recul sur le métier, il semblait difficile de remettre tout ça en cause. Alors j’ai fait de l’objet. Et, c’est là peut être une impression tout a fait personnelle, j’ai commencé à me sentir mal à l’aise. Notamment quand j’ai commencé à regarder comment les objets étaient utilisés.

Les racines du mal

Prenons un exemple: une société développe un très beau concept autour des objets Foo, elle en développe de nombreuses variantes avec toujours la même interface, on a donc une interface Foo et des instances FooBar, Foobaz, FooWazaaa, etc. Elle rend le tout disponible, et ça correspond aux besoins de plein de monde. Comme souvent malheureusement, les fonctionnalités de l’objet Foo sont légèrement insuffisantes. On aimerait pouvoir manipuler l’objet Foo d’une certaine manière, mais ce n’est pas prévu. Hériter des classes pour étendre les objets seraient possible mais... quelques classes sont déclarées comme finales et surtout on serait obligé d’étendre toutes les sous classes, ça serait très pénible. Cherchant une solution, on propose finalement une classe utilitaire FooUtils, remplis de méthode statique qui vont permette d’ajouter ce qui manque. Et là, pour moi, c’est le drame. Tout d’abord, dans le concept objet, la notion de méthode statique m’a toujours semblé bancale. On a là une méthode qui n’est pas issue d’un objet, il s’agit en soit d’une entorse à une vue “pure” du concept. Mais admettons, le pire est à venir. Car maintenant, en fonction de la fonctionnalité de l’objet Foo que vous voudrez utilisé, vous aurez deux syntaxes très différentes : une orientée objet, où l’objet appelle la méthode, et une fonctionnelle, où vous appelez une méthode qui transforme un objet donné en paramètre. Oh bien sûr, on s’en sort. Mais je trouve ça horriblement pénible. Pour pallier à un système d’encapsulation du code dans un objet non adapté à la réutilisation, on se retrouve avec un mélange de concept pour faire le boulot. Je tiens à remercier les classes de la librairies collection de java et la classe java.util.Collections pour leur rôle de doublure lumière de la famille Foo et de la classe FooUtils.

Programmons en objet des services non objets

Si seulement le malaise s’arrêtait là. Seulement, comme beaucoup de développeurs Java, j’ai eu à faire aux merveilleux monde des EJB, qui repoussent ces limites du paradigme. Chez nos amis les EJB, un entity bean est principalement un ensemble de données, que l’on manipule à l’aide de session beans. Et la plupart des sessions beans ne sont pas dépendants d’un état, ils ne sont donc qu’un ensemble de fonctions. On est là dans un monde formidable. Où un énorme framework a accouché de class “données” et de fonctions. Comme en dehors du java, il y a aussi un monde, regardons ce que l’on fait avec nos langages. Prenons les webservices: on envoie des données, on reçoit une réponse. Sauf dans de rare cas où les données contiennent aussi un peu de logique, on est de nouveau dans un monde purement fonctionnel, dépourvu d’objet. Bref, nous manipulons un concept qui est principalement un frein au raisonnement, uniquement par habitude. Il s’agit moins de remettre en cause l’approche objet que sa prédominance et son implémentation dans les langages actuels. En fait, en cherchant un peu, on peut retrouver traces de discussions où l’on remet en cause l’approche objet des langages modernes, exception faite peut-être de Erlang, que je n’ai pas assez pratiqué pour pouvoir juger.

Et après?

Chez moi, ce constat est venu en reprenant la programmation fonctionnelle, plus précisémment Haskell. D’un seul coup, cette gêne est devenue évidente. Du coup, la prochaine fois, je vous parlerai de programmation fonctionnelle, de Haskell et de typeclasses, juste pour partager comment les choses pourraient être autrement.