L'avis de Nicolas B.

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 23 mai 2012

Programmation désorientée objet

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.

mardi 26 février 2008

Programmer avec style

Après avoir pris le temps de trouver Smalltalk élégant, je me suis mis en tête de lire un peu de documentation sur le sujet. J'ai trouvé en ligne le très bon "Smalltalk with Style" qui doit être lu absolument, non seulement par ceux qui s'intéresse à Smalltalk, mais également par tous ceux qui aiment écrire du code proprement. Ce livre est une mine de bons conseils pour formater son code et ses commentaires. Il y a certes beaucoup de choses évidentes mais c'est toujours bon de faire un bref rappel. Bien sûr, les exemples peuvent être déroutants pour ceux qui ne connaissent pas Smalltalk mais comme ce langage est vraiment très agréable à lire quand on en connait les bases, ça vaut aussi le coup de prendre le temps de lire un didacticiel le concernant.