Bien que n'étant pas un expert estampillé en technologie objet, je pense m'en sortir pas trop mal. Et au vu de ce qui a pu être écrit pour l'enseigner, je pense comprendre ce qui cloche dans la plupart des méthodes d'apprentissage des langages orientés objet. Ces méthodes d'apprentissage pronent le visualisation par le code (après tout, à quoi sert un éxemple en informatique s'il n'est pas compilable ?) mais ce faisant, elles détournent complètement le sens des concepts qu'elles sont sensées véhiculer. Prenons l'exemple que tout le monde a dû suivre un jour : les formes géométriques qui se dessinent.

1. Pour parler de l'encapslation, on commence par parler du point qui encapsule ses coordonnées. Celà passe généralement par la définition des zones privées et publiques d'un objet, avec un code comme celui-ci :

type
  TPoint = Class
  private
    X,Y : integer
  public
    constructor Create(X,Y : integer);
  end;

Et voilà : pour définir l'encapsulation, le fait pour un objet de rendre inaccessible ces propriétés internes, non seulement c'est la première chose qui est définie après la déclaration de la classe, mais c'est aussi ce qui apparaît dès qu'on parle de l'instancier. Joli exemple à contre-emploi de ce qu'on veut justement enseigner. Je pense qu'il serait au contraire plus judicieux de laisser la partie privée en blanc avec un commentaire du style Ne nous concerne pas et de développer la partie publique de la classe par les méthodes que les instances doivent honorer. Car après tout, si la classe TPoint doit honorer la méthode Draw, peu importe que les coordonnées du point soient exprimées en X,Y ou en coordonnées polaires, ou dans un référenciel cylindrique. La seule chose qui importe, c'est qu'un point soit capable de se dessiner.

2. Justement, concernant l'idée qu'un objet doit honorer un message qui lui est envoyé, on n'insiste jamais assez sur l'importance du nommage des méthodes. Nommer une méthode pour décrire ce que fait effectivement l'objet qui l'implémente c'est déjà au niveau du sens, dévoiler ce que sa zone privée contient, et par ricochet contrevenir à la règle d'encapsulation. Le nommage d'une méthode doit plutôt s'appuyer sur la définition du service que rendra l'objet à son appelant. Si la méthode ainsi définie doit être virtuelle, on s'apercevra rapidement que ce nommage correspond mieux à l'idée générique permettant une surcharge. Pour continuer avec l'exemple du TPoint, la méthode Draw n'a finalement de sens que si elle s'applique à un canevas qui recevra l'effet de la méthode.

3. Cet effet a toutes les chances d'être surchargé à travers plusieurs classes pour lesquelles le canevas serait en droit d'attendre un dessin. Il apparaît alors tout à fait cohérent de faire hériter la classe TPoint d'une classe ancêtre TShape virtuelle qui rassemble les propriété *public* communes à toutes les classes susceptibles d'interagir avec le canevas. Celà signifie aussi que des classes n'ont pas besoin d'avoir aucun membre privé ou protégé commun pour satisfaire un besoin d'héritage. Dans des langages objets ne proposant pas simplement les interfaces, c'est même la seule manière de définir un série de méthodes publiques surchargées.

4. Enfin, s'il y a bien quelque chose de destructeur (oups !) dans l'enseignement des langages orientés objets, c'est qu'il préconisent comme prérequis la connaissance de langage fonctionnels et d'algorithmique. Essayer d'analyser un problème dans une vision orientée objet et de trouver un solution pertinente nécessite d'analyser le problème en systèmes d'entités et d'interactions. Ces choses sont très éloignées de la recherche de la résolution linéaire par un algorithme, au besoin factorisé en fonctions. Un objet sait ce qu'il est et ce qu'il est capable de faire par lui-même . Introduire du code pour tester des classes, ou pire, associer un champs privé au type de l'objet pour pouvoir faire des tests est une hérésie dans un modèle objet correctement analysé.

Pour rappel, la technologie objet a été inventée pour deux objectifs : limiter le nombre de lignes à écrire et faire vivre le principe Closed for modification, opened for extension. C'est contraire à son esprit que de réintroduire par la fenêtre ce qu'on a cherché avec tant d'énergie à éradiquer.

Voilà, j'espère n'avoir pas trop paru présomptueux. Et je suis bien sûr ouvert à tout commentaire !