Grandeur et décadence de l'objet 2/2

Dans l'article précédent, j'avais évoqué la grandeur de l'approche objet. En des temps reculés que les plus jeunes développeurs ne pouvaient pas connaître, Java n'existait pas (et si, ça a existé, il n'y avait pas l'Internet non plus), la plupart des applications de gestion étaient développées en C, voire en C++ ou en Visual Basic.
Quelques chanceux pouvaient utiliser des langages dynamiques comme LISP ou Perl. D'autres étaient confinés dans les affres des RAD tels que Delphi ou WinDEV.

C'est à cette époque que j'ai commencé ma carrière professionnelle comme développeur C++. J'avais découvert ce langage en école, par moi-même, aidé en cela par un bon niveau en C et l'étude de la théorie des types.
J'avais déjà l'habitude de coder de manière modulaire en C, en fait, je faisais de l'objet sans le savoir.

Mon premier job en tant que développeur (j'avais été recruté pour ma connaissance de C et C++) fut de maintenir une application écrite en VB 4.0, un langage purement procédural dont la syntaxe était conçue pour les mauvais développeurs, ceux qui ont séché les cours de pointeurs, de structures de données et d'algorithmique de la faculté d'informatique.

Comme il arrive neuf fois sur dix dans ce genre de cas, le code était énorme, peu modulaire, avec beaucoup de motifs répétés (par la fameuse méthode de développement dite du "copier/coller"). En vertu des lois de la statistique, plus il y a de lignes de code (et, a fortiori de lignes mal écrites), plus il y a de chances que des bugs apparaissent.
Force fut de constater que la loi s'appliquait parfaitement à la situation, maintenir cette application devenait un cauchemar. Les développeurs étaient démotivés, les chefs de projet n'avaient plus assez de ressources pour travailler sur des produits plus innovants.

Nous n'avons eu alors de cesse que de préconiser l'approche objet et le passage à C++ pour le coeur de l'application, pensant que l'utilisation d'un autre paradigme enlieu et place du (mauvais) procédural allaient arranger nos problèmes.

Dans un premier temps, je me suis chargé d'appliquer les méthodes de l'approche objet au code VB 4.0. En pratique, c'est revenu à porter l'intégralité du code vers VB 5.0 et à réarchitecturer certains modules en taillant dans le code mort, en identifiant et factorisant les répétitions.
De 150000 lignes, les programmes sont passés à 60000 lignes. Parallèlement à ça, les nouveaux projets commençaient directement à être écrits en C++ en se basant sur les MFC (Microsoft Foundation Classes) et la STL (Standard Template Library).

Et puis, tout s'est accéléré. L'approche objet tendait à se généraliser, les ouvrages sur le sujet devenaient plus accessibles. UML est apparu.

Au bout de quelques mois, on s'est retrouvés à produire plus de modèles que de code, à définir des architectures de produit et à parler en termes de motifs de conception (Design Patterns).
Dans le même temps, les développeurs essayaient de transposer sous forme de code C++ le résultat de ces conceptions et, force fut de constater là encore, que le résultats n'étaient pas à la hauteur de nos attentes.

Le code se retrouvait aussi compliqué, touffu et verbeux que s'il avait été écrit en procédural. Plus encore, des choses simples se trouvaient artificiellement complexifiées à cause du respect zélé que nous avions de l'approche objet généralisée.

La première conclusion de cet exemple est que l'approche objet généralisé n'est pas adaptée à tous les contextes. En gros "trop d'objet tue l'objet".

Et pourtant, C++ n'étant qu'un "meilleur C" suivant les termes de son concepteur Bjaarne Soustrup, il restait possible de coder simplement à base de fonctions et de structures de données simples les choses simples sans avoir à fournir un substrat objet simplement pour respecter des normes de développement qui devenaient inadéquates.

Dans le même temps, la syntaxe de C++ héritait celle de C avec son cortège de pointeurs, de chaînes à zéro terminal et autres joyeusetés qui sont des portes ouvertes aux bugs de toutes sortes pour qui ne les maîtrisent pas.
Dans le même temps, rien n'imposait aux développeurs d'utiliser l'approche objet en C++ et certains d'entre eux continuaient à penser et à coder en procédural.

La chose est impossible en Java. A cette époque, Java quittait les labos de Sun et entrait par la grande porte dans les SI des entreprises. Et Java était une révolution.

En Java, il n'y a pas de pointeurs, juste des références anonymes (en fait ce sont des pointeurs de pointeurs qui ne sont pas déréférençables).
En Java, tout est objet (ce qui n'est pas en soi une révolution car SmallTalk fut, dans les années 80, le premier langage pur objet).
En Java, tout se détermine par la classe. Impossible de coder ne serait-ce qu'une fonction hors d'une classe même main, le point d'entrée d'un programme.
En Java, plus besoin de se forcer à libérer les références allouées en mémoire, il y a un ramasseur de miettes qui nettoie les saletés des développeurs.

Java a été conçu pour être le langage standard de l'approche objet avec la ferme d'intention de forcer l'utilisation de l'approche objet pour l'écriture de n'importe quel programme.
Voici le programme iconique "Hello World !" écrit en Java (à titre de comparaison, sa version C++/STL)

En Java:
public class HelloWorld {
public static void main(String[] args) {
System.out.print("Hello world!");
}
}

En C++:
#include <iostream>
using namespace std;

int main()
{
cout << "Hello world!" <<>
return 0;
}

Les deux programmes font respectivement 91 (en Java) et 45 (en C++) caractères pour effectuer la même chose. Soit le double pour Java.
Si Java est verbeux pour quelquechose d'aussi simple que d'afficher une chaîne de caractères littérale, imaginez ce que ça doit être pour trier une liste d'entier.
Je ne fournirai pas le code en Java (Google est votre ami) pour cette tâche mais à titre de teaser voici comment on fait en Perl:

use strict;
my @list = (4, 10, 56, 78, 12, 2, 6);
print join(',',sort { $a <=> $b } @list);

La sortie écran donne : 2,4,6,10,12,56,78

Sans fonctions statiques, avec du tout objet (enfin presque), les développeurs d'applications, les concepteurs de bibliothèques de classes et de frameworks se sont mis à créer des objets sans état avec juste du comportement pour imiter le fonctionnement (simple) des fonctions des langages procéduraux.
Et, en bons adeptes de Design Patterns, ils firent collaborer ces classes dans des modèles de conception jusqu'à aboutir à des constructions intellectuellement très satisfaisantes mais parfaitement impraticables sans une bonne dose de self-control.

Et voilà ce que ça peut donner avec l'exemple du tri :

import framework.algorithmes.* // bibliotheques d'objets fonctions qui implémentent les algorithmes sur les structures de données (tri, parcours, recherche)
import framework.structures.* // bibliotheques d'objets qui implémentent les structures de données de base (listes, piles, tableaux, arbres)
public class TRiListeDEntiers {
public static void main(String[] args) {
int[] tableau = {4, 10, 56, 78, 12, 2, 6};
ListeDEntiers liste = new ListeDEntiers(tableau);
TriNumerique operateur_tri = new TriNumerique(TriNumerique.TriRapide);
ListeDEntiers liste_triee = operateur_tri.trier(liste);
System.out.print(liste_triee.EnChaine(","));
}
}

On peut se plaindre de Java mais C++ et la STL ont des concepts similaires :


#include <iostream>
#include <algorithm>
using namespace std;

int main() {
int tableau[7] = {4, 10, 56, 78, 12, 2, 6};

sort(tableau, tableau+7);

for (int i=0; i<7; i++) {
cout << a[i] << " ";
}
}

L'idée derrière tout mon propos est que pour faire des choses simples qu'on fait tous les jours quand on développe des programmes, il faut des langages qui permettent de le faire en un minimum de signes.
Java (et C++) autorisent beaucoup de choses et permettent de faire de grandes choses d'ailleurs mais pour les petites choses du quotidien, ils sont absolument impraticables.

C'est la décadence de l'objet : devoir écrire des choses de plus en plus baroques et artificielles pour des choses simples qu'un étudiant de première année sait coder en Pascal ou en Scheme.
C'est à dire : des structures de données (paire, listes, tableaux, vecteurs, cartes, chaînes de caractères, arbres, graphes) et des algorithmes (insertion et suppression d'élément, accès aléatoire, parcours, recherche et tri)

Je vois les langages à objets historiques comme des empereurs romains. Après avoir connu la gloire des triomphes sur les hordes barbares procédurales (l'immonde Basic en tête), les langages à objets ont sombré dans une lente et inexorable décadence, devenant de plus en plus boursouflés, encombrants et maladroits.

Péché capital de l'objet : Un paradigme omniprésent mais incomplet
Difficile de passer à côté de l'héritage, de l'encapsulation et du concept de classe quand on code en Java (ou en C++). Et pourtant, certaines constructions du langage qui auraient mérités d'être des objets ne le sont pas (le type int, les structures de contrôles).
D'une manière générale, l'approche objet est criticable car elle ne repose pas sur des fondations formelles précises qui permettraient de démontrer les capacités des langages qu'elle inspire.
D'un autre côté, il existe un fort engouement pour les langages à objets, engouement qui confine à l'irrationnalité et à la pensée magique. Certains pensent que passer à l'objet va magiquement résoudre leurs problèmes de cycle de développement, de couverture de code ou de spécifications fonctionnelles. En aucun cas.

Il existe des tentatives de définition formelle des langages à objets, l'une des mieux abouties est présentée dans ce livre (A Theory of Objects).
Cette définition formelle n'est pas unique malheureusement, et les différentes théories n'ont pas pu être prouvées équivalentes.

Péché capital de l'objet : Des langages verbeux
La base de la théorie de la programmation repose sur les structures de l'information et les algorithmes de traitement. La productivité logicielle se mesure par le rapport entre la qualité du produit et le nombre d'heures de réalisation.
La plupart des langages à objets manquent de ces structures et de ces algorithmes. Ils peuvent se voir étendus, certes, par des bibliothèques.
Mais ces modules complémentaires sont difficiles à concevoir et à mettre au point en raison d'un système de typage très évolué, généralement strict et statique.
Il en résulte que chaque structure classique comme une liste ou un vecteur doit être construit comme un type dérivé basé sur un modèle (de liste ou de vecteur) et affublé du type des éléments contenus.
Pareillement, les algorithmes classiques (tri rapide, recherche dichotomique ou parcours infixe) sont implémentés dans des objets sans états.
Résultat ? Il est quasiment impossible de concevoir simplement une liste opérationnelle capable de contenir des éléments hétérogènes et de la parcourir aisément. Chose qu'il est parfaitement possible de faire dans des langages comme LISP ou Python.

Péché capital de l'objet : La difficulté de faire simple
Vous avez déjà regardé l'implémentation du type String en Java ? (ou du type CString en C++/MFC) ? C'est abominable !
Pour quelque chose d'aussi simple et de consensuel qu'une chaîne de caractères, Java et C++ englobent un tableau de caractères ou d'entiers non signés dans une enveloppe très épaisse qui donne l'illusion au programmeur de manipuler une entité très simple.
En soi, il est vrai que manipuler une variable de type String ou CString est simple mais c'est au prix d'une perte de performance.
Heureusement, les concepteurs de Java ont pensé à fournir aux développeurs une bibliothèque de types simples comme String ou BigDecimal. Mais quand le développeur a à représenter le contenu d'une table relationnelle dans un objet, ou pire à rendre persistant l'état d'un objet, il s'arrache les cheveux, il vient de rencontrer le problème de l'adaptation objet-relationnel (Object-relational impedance mismatch en anglais)
Plutôt que de développer ce concept de manière exhaustive, j'invite le lecteur à consulter ces deux liens (en anglais)
The Object-Relational Impedance Mismatch
The Viet-Nam of Computer Science

Cet exemple particulier illustre le fait que l'approche objet met en exergue des éléments structurels statiques (architecturaux on peut dire) alors que le modèle procédural (et le modèle relationel jusqu'à un certain point) se concentre sur la dynamique des systèmes et les changements d'états.

L'approche objet est d'un grand secours quand il s'agit de concevoir et de maintenir l'architecture d'un ensemble logiciel (comme on le voit à l'heure actuelle avec les Entreprise Service Bus, Entreprise Application Integration et autres Services Oriented Architecture)
C'est un outil pour les concepteurs et les architectes logicielles misant sur des concepts industriels tels que réutilisabilité, sécurité, extensibilité, compréhension, etc.
Mais dès que la granularité devient faible ou que les spécifications se transforment en garanties de comportement, l'approche objet atteint ses limites, manque d'agilité et la respecter à la lettre devient contre-productif.

Voilà pourquoi le tout objet est idiot.

"Et quand on ne dispose que d'un langage à objets ?" me demanderons les lecteurs qui n'ont pas encore décroché.
Nous allons voir que les langages à objets qui subsistent aux pieds de Java dans le monde de l'industrie du logiciel sont beaucoup moins impérialistes et décadents que leur illustre ancêtre.

A la semaine prochaine, à la découverte des langages dynamiques.

Grandeur et décadence de l'objet 1/2

Où je raconte encore ma vie

Les quelques (rares) lecteurs qui fréquentent cet endroit doivent se dire que ce mec n'a rien à raconter à part ses sorties ciné et ses soirées télé.
C'est pas faux mais de temps en temps comme tout un chacun, j'aime aussi penser et réfléchir à des choses moins terre-à-terre.
Jusqu'à tout récemment, tant professionnellement que personnellement, j'avais complètement laissé tomber en friche ma culture de langages informatiques jusqu'à ce que deux événements sans aucun rapport entre eux surviennent à quelques jours d'intervalle.

D'abord, je suis tombé sans le chercher précisément sur un numéro hors-série du magazine Tangente qui traitait des nombres et parmi eux, deux nombres rigolos, petit oméga et Grand Oméga (voir ce lien).
Pour faire simple, sachez que ces deux nombres ont un rapport avec la probabilité d'un programme s'arrête ou boucle indéfiniment.
Dans l'article, l'auteur expliquait que ces deux nombres ne pouvait être calculés, c'est à dire qu'il n'existe aucun programme qui permette d'en donner une suite plus ou moins longue de décimales (alors que pi ou racine de 2 peuvent être calculés comme on le verra dans un prochain article)

J'ai trouvé cet article très intéressant d'autant plus qu'il éveilla en moi un vieux souvenir d'informatique. A ce niveau, un petit aparté s'impose. Quand je dis informatique, je parle de la science qui étudie les algorithmes et les structures de données. Comme le disait d'ailleurs Edsger Dijkstra : « L'informatique n'est pas plus la science des ordinateurs que l'astronomie n'est celle des télescopes. »

Ce souvenir avait rapport avec la calculabilité et la décidabilité, deux notions étudiées dans le cadre d'une auto-formation à la Théorie de la complexité de Kolmogorov.
L'informatique, à ce niveau d'abstraction là, ne peut supporter que des langages très abstraits. Le premier de ces langages est une sorte d'assembleur conçu pour une machine très simple : la machine de Turing. Le second langage (qui est équivalent au premier) s'appelle le lambda-calcul.
Je reviendrai sur ces deux choses étranges plus tard.

Le second événement a été un message d'un contributeur du Scriptorium qui, cherchant à illustrer la notion de paradigme, prit l'exemple des langages informatiques et commença d'en citer quelque uns.

Les deux événements furent à la source d'une association d'idées qui aboutit à une sorte de petite révélation (faut pas exagérer non plus). J'allais me remettre à m'intéresser aux langages informatiques.

La popularité des langages

Après quelques heures de surf sur l'Internet pour avoir un état de l'art des langages utilisés, je tombe sur cette page : paf !

On peut voir que Java tient le haut du pavé, suivi par C et C++.
On peut voir que les langages à objets et les langages procéduraux sont les plus plébiscités (par rapport aux langages fonctionnels et aux langages logiques)
On peut aussi voir que les langages à typage statique sont préférés aux langages à typage dynamique.
Là, le lecteur de Pougues-les-Eaux est complètement largué et se dit qu'il va retourner lire les vieux articles sur la Nouvelle Star. Non, restez, je vous prie, j'explique.

Tout d'abord, il est facile de comprendre pourquoi les langages à objets et procéduraux d'une part et les les langages à typage statique d'autre part tiennent le haut du pavé.
Parque que Java, C++ et C qui représentent 45% du total de la liste des langages sont des langages à typage statique et orientés objets (beaucoup trop pour Java, juste assez pour C++ et peu pour C)
Là, les lecteurs qui sont des intégristes de la profession s'insurgent : "Comment, ce voyou met sur le même pied Java, C et C++ et il s'en moque ! C'est n'importe quoi, tout le monde sait que Java (ou C ou C++, rayez la mention inutile) est le meilleur langage du monde !"

A ce stade du débat, afin de calmer les esprits avant de tailler dans le vif plus encore, une petite digression factuelle et objective s'impose.

Qu'est-ce qui caractérise un langage orienté objets ?

Il faut savoir qu'un objet est un être abstrait qui se compose de trois choses : une identité, un état et un comportement.
L'identité dit que chaque objet est unique (c'est un peu à l'objet ce que le numéro de sécurité sociale est à l'administration, une manière de distinguer les individus des autres)
L'état de l'objet est, plus encore que son identité, ce qui fait l'objet (on vous appelle plus souvent par votre prénom ou votre nom que par votre numéro de SS)
Le comportement est, plus encore que son état, ce qui distingue encore l'objet (bien qu'Einstein et moi ayons en commun une moustache et les cheveux en bataille, je n'ai jamais contribué de manière significative à l'avancée de la Physique)

Un langage orienté objets permet la manipulation de variables qui sont des objets.
Et, dans ce cadre, le C est bien un langage orienté objets:
C'est comme ça que, personnellement, je jouais à "faire de l'objet" avec le vieux compilateur C de Borland. Et c'est comme ça que je continue à faire un peu d'objet avec Perl (mais beaucoup plus de facilité)

Il y a d'autres choses qui font qu'un langage orienté objets est digne, d'après les gourous de l'objet, d'être considéré comme un "bon" langage à objets.
Le langage doit supporter l'encapsulation (c'est dire qu'on ne doit pas pouvoir fouiller l'intérieur des objets, accéder ou modifier l'état de ceux-ci)
Le langage doit supporter l'héritage (c'est dire qu'un objet est une sorte d'autre objet quand ils partagent un état et un comportement commun)
Le langage doit supporter le polymorphisme (c'est dire que celui qui manipule un objet n'en connaît pas la nature exacte a priori mais fait comme si)

Vertu cardinale de l'objet : l'Encapsulation

L'encapsulation empêche le code principale d'accéder directement aux variables qui constituent l'état de l'objet

#include

class PERSONNE
{
public:
char* nom;
private:
char* prenom;
};

int main(void)
{
PERSONNE mezigue;
char nom[] = "SandChaser";
char prenom[] = "";
mezigue.nom = nom;
mezigue.prenom = prenom;
}

Le compilateur (g++ dans mon cas) râle parce que le membre prenom est déclaré comme privé.

La raison d'être de l'encapsulation est le respect de la cohérence interne des objets.
Par exemple, tous le monde sait que le numéro de SS contient une indication sur le sexe de la personne immatriculée.
Imaginons un instant un objet dont l'état est composé d'un numéro de SS et d'un booléen (masculin/feminin) représentant le sexe.
Si les membres de cet objet étaient publics, n'importe qui pourrait modifier sexe et numéro de SS de façon indépendante au risque d'arriver à des incohérences.

Vertu cardinale de l'objet : l'Héritage

L'héritage est une sorte de spécialisation du rôle des objets. Admettons que l'on a un objet CONVERTER qui réalise une conversion d'un texte mis en page avec LATEX vers Postscript.
Si les spécifications de LATEX ou de Postscript viennent à changer, il faudrait modifier notre objet. Ca prend du temps et la nouvelle version ne serait plus compatible pour les anciens formats.
Qu'à cela ne tienne, spécialisons notre objet en disant qu'il est une spécialisation de CONVERTER:

#include

class CONVERTER {
void* convert(char*);
};

class CONVERTER_V2 : CONVERTER {
void* convert(char*);
CONVERTER* get_compatible(void);
};

Un client de notre objet utilisera la nouvelle version et appellera la fonction get_compatible pour objetnir un CONVERTER ancien modèle.

La raison d'être de l'héritage est de factoriser le code pour le réutiliser dans des cas spécifique sans avoir besoin de le recoder.

Vertu cardinale de l'objet : le Polymorphisme

Cet exemple du CONVERTER va aussi me permettre d'aborder le polymorphisme. Le client de notre CONVERTER doit encore faire lui-même le choix du type d'objet à créer en fonction de ce qu'il reçoit et de qu'il veut obtenir.
Imaginons que le CONVERTER doive aussi produire du flux PDF à partir du texte LATEX, nous pourrions créer un autre objet PDF_CONVERTER et renommer les deux premiers en PS_CONVERTER

class PS_CONVERTER
{
public:
void* convert(char*);
};

class PS_CONVERTER_V2 : PS_CONVERTER
{
public:
void* convert(char*);
PS_CONVERTER* get_compatible(void);
};

class PDF_CONVERTER
{
public:
void* convert(char*);
void set_pdf_header(void*);
};

int main(void)
{
int c;
void * pConverter;
switch(c) {
case 0 : pConverter = new PS_CONVERTER_V2; break;
case 1 : pConverter = new PDF_CONVERTER; break;
default : return(1);
}
/* utiliser le pConverter */

switch(c) {
case 0 : ((PS_CONVERTER*)pConverter)->convert(0); break;
case 1 : ((PDF_CONVERTER*)pConverter)->convert(0); break;
default : return(1);
}

}

A chaque fois qu'on est amener à se poser la question de savoir quel type de document je veux en sortie, il faudra utiliser un switch et du type cast (bouh que c'est laid !).
Heureusement que le polymorphisme peut changer cela :

class CONVERTER // classe qui spécifie une interface de commande avec deux fonctions
{
public:
void* convert(char*);
void set_header(void*);
}

/*
chaque classe de convertisseur hérite maintenant des deux fonctions de l'interface CONVERTER
*/
class PS_CONVERTER : CONVERTER
{
public:
void* convert(char*);
};

class PS_CONVERTER_V2 : PS_CONVERTER
{
public:
void* convert(char*);
PS_CONVERTER* get_compatible(void);
};

class PDF_CONVERTER : CONVERTER
{
public:
void* convert(char*);
void set_header(void*);
};

int main(void)
{
int c;
CONVERTER * pConverter;
switch(c) { // on choisit ici une bonne fois pour toutes quel type de convertisseur on veut
case 0 : pConverter = new PS_CONVERTER_V2; break;
case 1 : pConverter = new PDF_CONVERTER; break;
default : return(1);
}
/* on utilise pConverter sans avoir à se demander de quelle sorte il est*/
pConverter->convert(0); // l'appel à convert est polymorphique !
// jouez chez vous à changer la valeur de c entre 0 ou 1
// implémentez les fonctions des objets et constatez que c'est la bonne fonction
// qui est appelée dans chaque cas.

}

La raison d'être du polymorphisme est de permettre à l'utilisateur d'un objet de lui envoyer des messages (en exécutant des fonctions) sans avoir à faire des hypothèses (parfois fausses) sur la nature réelle de cet objet.

Grandeur des langages à objets

Les langages à objets sont très à la mode depuis que Java a vu le jour. Il n'en était pas de même avant ces années fastueuses où l'on ne jurait que par le procédural.
Les langages à objets ont popularisé l'approche objet (union identité, état, comportement + encapsulation + héritage + polymorphisme) grâce à leur syntaxe adaptée.
Il est possible de programmer en style objet en C ( on vient de le voir) et en Pascal. On améliore ainsi la modularité du code au détriment de sa lisibilité.

La finalité de l'approche objet est de capturer dans le code de meilleures abstraction des concepts réels (par la définition des objets par identité+état+comportement), modulaires et complètes. L'encapsulation a pour finalité d'éviter l'accès à distance de l'état de l'objet qui a pour effet pernicieux de produire des incohérences d'état et, par conséquent, des bugs.
L'héritage a pour finalités la réutilisation du code et la composition du comportement (ces deux choses ne sont pas l'apanage de l'approche objet d'ailleurs, contrairement à ce que beaucoup disent)
Enfin, le polymorphisme aide l'héritage en garantissant que le bon comportement sera déclenché même si l'utilisateur ne sait pas quelle est la nature précise de l'objet qu'il manipule.

Mais les langages à objets ne sont pas exempts de défauts. En fait, la plupart de gens font de l'objet parce que :
1) c'est à la mode (donneur d'ordre, architecte)
2) le chef leur a dit de faire (développeur de base)
3) ils ne connaissent que ça (architecte, développeur de base)
4) il leur serait indigne de ne serait-ce penser qu'il puisse exister d'autres paradigmes (gourou)

Sur ces bonnes paroles, à la semaine prochaine, on verra pourquoi le tout objet est idiot.