La POO (Programmation Orientée Objet) tourne autour de la notion de "classe", un objet au sens de la POO sera toujours une classe. C’est cette notion qui caractérise essentiellement le C++, elle est une extension de la notion de "structure" du C. Dans une structure, tous les éléments étaient accessibles de l’extérieur alors que dans une classe, il y a cette possibilité d’"encapsuler" des données, elles ne sont alors plus accessibles de l’extérieur, elles sont comme protégées, c’est ce qui la différencie d’une structure. On utilise le mot réservé "private" pour désigner des éléments inaccessibles de l’extérieur et "public" pour désigner des éléments accessibles.

Pour déclarer une classe, c’est très simple, on utilise le mot réservé "class", on donne un nom à la classe, on définit la classe entre ses accolades et on termine par un point-virgule.

N’oubliez pas le point-virgule final sinon il y aura une erreur à la compilation.

L’intérêt d’une classe est de pouvoir assembler des éléments liés logiciellement. Ces éléments sont appelés "membres", on parle donc de membres d’une classe. Il y a deux types de membres : les données et les fonctions. En POO pure, les données membres c’est-à-dire la liste des variables appartenant à la classe doivent être encapsulées donc inaccessibles directement de l’extérieur, on n’accède à ces données membres que par les fonctions de la classe, ces fonctions sont dites "méthodes", on appelle donc méthode toute fonction membre d’une classe.

Une classe a la possibilité d’avoir un constructeur et un destructeur, c’est une façon de vous donner la main au moment de l’instanciation de la classe et aussi au moment de sa destruction. On appelle " instanciation " la création d’un objet en mémoire. Constructeur et destructeur sont donc des méthodes particulières, ce sont des fonctions membres de la classe, on les met dans la section "public" puisqu’ils sont accessibles, ils se reconnaissent au fait qu’ils portent le même nom que la classe, nom tel quel pour le constructeur et précédé du tilde (~) pour le destructeur.

Imaginons une application qui traite des fichiers. Ces fichiers vont être lus en mémoire, traités puis sauvegardés. Une fois lu en mémoire, un fichier a deux caractéristiques, une adresse à partir de laquelle se situe le fichier et une longueur, ce qui se concrétisera par un pointeur et une longueur en nombre d’octets. Imaginons la classe "Fichier" avec un constructeur et un destructeur comme suit :

Par défaut les éléments d’une classe sont du type "private", donc le pointeur P et le nombre entier Lg sont des données encapsulées mais bien entendu on peut écrire aussi "private:" juste avant ces données, on peut même alterner les sections "private" et "public". Vient ensuite la section "public" avec la déclaration du constructeur et du destructeur. Il s’agit simplement de la déclaration du prototype de ces fonctions, il faut maintenant les écrire. Le constructeur va simplement initialiser P à NULL et la longueur Lg à 0 et le destructeur va libérer la mémoire censément pointée par P. L’initialisation à NULL du pointeur P est toujours préférable car elle permet un bon fonctionnement de l’instruction delete du destructeur même si P est toujours à NULL au moment du delete c’est-à-dire même s’il n’y a pas eu allocation mémoire à partir de P (car si P n’était pas initialisé, le delete planterait). En initialisant P à NULL donc, on s’assure de ne pas faire planter le delete, qu’il y ait eu allocation mémoire ou non.

Remarquez que le constructeur et le destructeur n’ont aucun type (même pas void qui serait refusé par le compilateur), que le point-virgule n’est pas nécessaire après l’accolade fermée contrairement à la déclaration d’une classe et que toute méthode est préfixée par le nom de la classe suivi de deux points (ici Fichier::).

Imaginons maintenant trois méthodes nouvelles, la méthode "Creation" qui va allouer un certain espace à partir du pointeur P, la méthode "Remplit" qui va remplir arbitrairement cet espace (ces remplissages arbitraires sont la preuve de la bonne gestion mémoire car l’accès à une zone non déclarée provoque une violation d’accès) et la méthode "Affiche" qui va afficher la zone mémoire pointée par P. Puis écrivons un programme maître qui instancie notre classe par new, appelle nos trois méthodes et détruit l’objet par delete.

Pour nos tests, nous utilisons le compilateur gratuit C++ de Borland que vous pouvez télécharger à discrétion.

Le programme maître crée d’abord un pointeur vers notre classe "Fichier" puis instancie par new cette classe. C’est à ce moment, au moment du new, que le constructeur de classe est appelé. Ensuite on appelle la méthode " Creation ", laquelle renvoie un booléen à true si la création a été acceptée, false sinon. Si la création est acceptée, on remplit alors la zone allouée (remplissage arbitraire avec le code ASCII de la lettre a), ensuite on l’affiche, ceci nous prouve d’une part la correction de l’allocation et d’autre part son accessibilité (sinon il y aurait une violation d’accès).

Vous remarquez que toutes les méthodes ont accès au pointeur P et à l’entier Lg mais ces variables ne sont pas accessibles depuis le programme maître. Si par exemple Ptr est un pointeur de type char*, on ne pourrait pas écrire :

le compilateur nous dirait que Fichier::P (lire " le membre P de la classe Fichier ") n’est pas accessible dans la fonction main (i.e. le programme maître). C’est ce qu’on entend par " encapsulation ", P est encapsulé, il n’est visible que depuis les méthodes de la classe. Idem pour Lg et pour toutes données situées dans la section " private ".

Remarquez que pour l’allocation mémoire dans la méthode " Creation " nous avons utilisé l’instruction malloc du C pur et non pas new du C++. La raison en est que le refus de l’allocation s’analyse par les exceptions avec new alors que malloc se contente de renvoyer NULL si l’allocation est refusée. En utilisant new, nous aurions été obligé de le protéger par le couple try/catch et écrit par exemple :

En effet, bien que P soit initialisé à NULL par le constructeur de la classe, on ne peut pas tester P après " new " pour savoir s’il est toujours à NULL car si l’allocation par new est refusée, le programme s’arrêtera de lui-même puisqu’en cas d’exception C++ Windows reprend la main et affiche une fenêtre indiquant une violation d’accès (il y a paraît-il une possibilité avec la spécification __declspec(nothrow), par exemple int* a=new __declspec(nothrow)int[N] mais je n'ai pas réussi à la mettre en oeuvre avec C++ Builder, normalement, dans ces conditions, si N est trop grand, on devrait avoir a=NULL comme si on avait utilisé malloc, nothrow étant censé signifier que les exceptions ne sont pas déclenchées). S’agissant de l’instruction new, il y a donc deux possibilités : ou bien il faut procéder par try/catch comme dans l’exemple précédent, ou bien on considère qu’il ne peut pas y avoir de problème d’allocation mémoire, auquel cas on ne fait aucun test, par exemple :

Dans ce cas, c’est Windows qui prend la main en cas d’erreur. La méthode " Creation " n’est plus booléenne, elle ne renvoie pas d’indication sur l’autorisation d’allocation, le main (programme maître) ne fait que l’appeler sans tester de code retour puisqu’il n’y en a plus (en bleu, les différences avec la programmation précédente).

La règle serait la suivante : l’instanciation par new a deux caractéristiques, d’une part elle s’opère sur un objet fixe (par exemple une classe en elle-même a une taille fixe) et d’autre part on ne teste pas la validité de l’instanciation et ce, parce qu’au plan probabilitaire, il n’est pas possible que l’instanciation soit refusée. En revanche, on continue l’utilisation de l’instruction malloc du C pur s’agissant d’une allocation dynamique d'une part parce qu’il est très aisé de tester le refus de l’allocation (puisqu’en cas de refus malloc renvoie NULL), d'autre part parce qu'il y a possibilité d'un realloc notamment pour agrandir la zone, ce qui est très pratique surtout pour les zones mémoire ou zone de pointeurs (notamment pour les pointeurs de classes). Dans l’absolu, il faudrait toujours préférer le couple new/delete du C++ à l’obsolète malloc/free du C pur mais c'est plus facile à dire qu'à faire car le malloc a son realloc, ce qui n'est pas le cas du new. Si toutefois vous travaillez avec C++Builder, vous disposez alors d’objets sophistiqués tels que les AnsiString, les TSmallIntArray (voir alinéa 43 de mes "Remarques") ou encore les TList (alinéa 47) qui résolvent la question et gèrent parfaitement la mémoire à la mode C++. Bien entendu, on perd légèrement en performance puisqu’on s’est éloigné du système mais on gagne en qualité et sécurité car la gestion mémoire est parfaite.

Observons que la mémoire allouée ne fait pas partie de la classe en tant que telle, la classe contient seulement un pointeur initialisé à NULL à la construction et pointant ensuite une allocation mémoire.

La classe a été instanciée comme suit :

Cette instruction est en fait une double instruction puisqu’il y a d’une part la déclaration du pointeur f et d’autre l’instanciation de la classe "Fichier". On aurait d’ailleurs pu écrire en deux lignes :

Cela dit, nous aurions pu instancier autrement en déclarant simplement un objet du type "Fichier" par exemple :

Dans ce cas, la classe n’est plus instanciée dans le tas (on appelle ainsi la mémoire libre, c’est cette mémoire libre qui est invoquée par new ou malloc), elle est instanciée dans la pile. Il y aura par la suite deux différences, d’une part les membres de la classe vont être accessibles non plus par la petite flèche (objet instancié dans le tas) mais pas un point (objet instancié dans la pile), d’autre part il n’y aura plus de delete car c’est le programme qui se charge de la destruction de l’objet puisqu’il gère la pile. Cela dit, bien qu’il n’y ait pas de delete, le destructeur de la classe est quand même appelé, la mémoire allouée est donc restituée (par le destructeur puisque c’est là que nous avons programmé le delete) mais la classe en elle-même est libérée dans ce cas par la gestion de la pile. Le programme maître s’écrirait donc ainsi :

En général, on évite d’instancier ainsi une classe, la pile n’est pas tellement conçue pour accueillir des objets. Elle peut facilement accueillir quelques pointeurs et quelques variables mais on évite d’instancier ainsi une classe, a fortiori plusieurs. En revanche, on instancie dans la pile un pointeur vers une classe

puis on instancie dans le tas la classe en elle-même

Dans le cas de tableaux de classes, vous pouvez instancier le tableau de pointeurs dans la pile

où NbCl (nombre de classes) est une constante arbitraire puis instancier les NbCl classes dans le tas par une boucle, par exemple :

Remarquez aussi la boucle finale qui détruit les NbCl classes. Une erreur serait d'écrire delete[]f, cette écriture ne convient que si la création s'est faire par new[], à delete correspond new, à delete[] correspond new[]. L'écriture delete[]f aurait correspondu à une instanciation des classes par Fichier *f=new Fichier[NbCl]. Mais l’inconvénient d’une telle écriture est que seul un constructeur par défaut peut être appelé (jamais un autre) alors qu’en passant par un pointeur pour chaque classe (c’est la règle que nous proposons), on a le choix du constructeur.

Cela dit, instancier NbCl pointeurs n’est acceptable que s’il y a peu de pointeurs car c’est la pile qui accueille ce tableau de pointeurs, il est toujours préférable de ne pas surcharger la pile. Le mieux donc serait d’instancier en pile non pas un tableau de pointeurs mais un pointeur de pointeurs de classe (c’est-à-dire un pointeur vers tableau de pointeurs) :

Ainsi f est ici un pointeur vers un tableau de pointeurs de classe. Maintenant on instancie dans le tas ce tableau de pointeurs

Maintenant seul le pointeur f est en pile, le tableau de pointeurs est dans le tas, la constante NbCl peut maintenant être très grande puisque ce tableau se trouve dans le tas. Le reste du programme serait identique.

Il en sera en général ainsi, pas de tableau de pointeurs en pile mais un pointeur unique qui pointe le tas qui contient toute la structure quelque complexe qu’elle soit, cela ne coûte qu’un niveau d’indirection en plus, une étoile de plus dans la déclaration du pointeur.

Imaginons maintenant que vous ayons NbCl classes à traiter. Il serait judicieux d’avoir en mémoire un pointeur (char*) et une longueur (unsigned int) qui soit une copie des mêmes éléments privés de l’instance active à un moment donné (pensez par exemple au logiciel Word qui n’a qu’un seul document actif à un moment donné bien qu’il peut en ouvrir plusieurs simultanément) :

Ainsi, si nous avons instancié NbCl classes du type " Fichier " et si f[i] est la classe active à un moment donné, on fera en sorte que PtrFic soit égal à f[i]->P et Lg à f[i]->Lg. L’intérêt d’une telle démarche est de pouvoir agir sur une zone allouée sans passer par une méthode de classe. Les variables membres restent encapsulées, PtrFic et Lg ne seront que des copies des données membres de l’instance active, on peut ainsi agir sur cette mémoire. Dans ces conditions, on modifierait la méthode Creation en lui donnant en plus la référence du pointeur char* du programme maître.

Ainsi, on alloue à partir de P la mémoire mais on renvoie ce pointeur à l’appelant. Dans ce cas, si PtrFic est le pointeur char* du programme maître, il pointera l’instance active à un moment donné.

Ici la méthode Creation renvoie le pointeur à PtrFic qui pointe l’allocation de l’instance active. On le prouve en appelant la fonction Affiche qui a pour argument PtrFic et la longueur allouée. L’intérêt d’avoir une copie des données membres est de pouvoir maintenant agir sur l’allocation d’une instance active sans avoir à créer de nouvelles méthodes. Affiche est ici une fonction isolée, elle accède à la mémoire de l’instance active sans être une méthode de la classe Fichier car il n’y a aucune raison pour gonfler une classe en lui rajoutant des fonctions membres.

Cela dit, cette méthodologie n’est peut-être pas encore parfaite car Lg n’est qu’une variable du programme maître sans lien avec l’instance active. Imaginons par exemple que la mémoire pointée par PtrFic (et donc par f[i]->P) ait à être augmentée par un realloc, il faudrait prévoir une méthode qui renvoie f[i]->Lg pour l’affecter à Lg du programme maître. Il faudrait d’ailleurs faire de même pour PtrFic car après un realloc, il se peut que la zone allouée change de place. Il faudra donc que PtrFic pointe non plus la zone allouée susceptible de changer d’emplacement mais le pointeur lui-même dans l’instance de classe qui, lui, ne bouge pas. Il faut donc rajouter un niveau d’indirection, Lg deviendra un unsigned int* et PtrFic un char**. Lg pointera donc l’unsigned int du tas (Lg n’est alloué qu’une seule fois ce pourquoi on peut pointer le tas) et PtrFic pointera le char* de l’instance de classe. Dans ces conditions, la longueur de la zone ne sera plus Lg mais *Lg. Lors de la méthode Creation, on renverra &P à l’appelant c’est-à-dire l’adresse de P (dont le contenu pointe la zone allouée).

Par ce petit test, on force un changement d’allocation et on constate que ça marche parfaitement. Si maintenant on ne veut pas manipuler comme dans l’exemple précédent un niveau d’indirection supplémentaire, il faut alors prévoir une méthode qui renverra le pointeur et la longueur de l’instance demandée. C’est peut-être une solution valable, elle a l’avantage de plus de clarté au sens où on a la même déclaration dans le programme maître que dans la classe.

Le programme maître gère ici quatre variables : int s1 qui représente le nombre de pistes de la série 1, int s2 le nombre de pistes de la série 2, char***P qui pointe la base de la structure et unsigned int **L pour les longueurs associées. Il y a donc ici deux séries, la série P[0] et la série P[1].

La série P[0] est un tableau de s1 pointeurs, on a donc P[0][0] pour le premier pointeur de P[0][s1-1] pour le dernier.

La série P[1] est un tableau de s2 pointeurs, on a donc P[1][0] pour le premier pointeur de P[1][s2-1] pour le dernier.

Ne pas oublier bien sûr de déclarer son prototype dans la classe.

Modifions le programme maître précédent pour vérifier. On ne détruit pas tout de suite les NbCl classes de manière à pouvoir initialiser Z avec la partition a[2] à titre d'essai.

On voit donc que traitant un tableau d'objets, on a tout intérêt à disposer dans le programme maître d'un matériel minimal d'accès à une instance active. Le principe que nous proposons consiste à travailler avec des tableaux de pointeurs et des tableaux de longueurs. Le programme maître n'a qu'un pointeur à la racine de la structure pour les zones et idem pour les longueurs. Il faut prévoir une méthode qui renvoie ces paramètres pour une instance donnée (n'oubliez alors pas dans le prototype l'opérateur &, voir e.g. la méthode "Donne" dans notre exemple précédent). Il faut aussi prévoir parmi les différents constructeurs possibles (en fonction des diverses initialisations) un constructeur minimal qui ne crée aucun tableau ni zone (il ne fait que mettre à 0 ou à NULL variables et pointeurs), cela permet de concevoir ensuite une méthode de recopie d'une instance initialisée vers une instance vide. C'est cette méthode qui se chargera de créer ces tableaux et zones en fonction de l'instance à dupliquer.

Je passe sous silence le problème de la dérivation des classes c'est-à-dire le fait qu'une classe puisse être créée sur la base d'une autre classe, héritant ainsi de toutes les caractéristiques de la classe dérivante. La dérivation en effet nous paraît un problème mineur par rapport au concept même de classe qui a suscité cet article. Sachez simplement que si votre classe est susceptible d'être dérivée par la suite, vous pouvez alors protéger vos membres de classes par le mot réservé "protected". C'est une sorte de moyen terme entre "private" et "public". Une donnée protégée reste accessible aux fonctions membres de la classe dérivée mais est inaccessible à l'utilisateur. Puisque c'est normalement le concepteur de la classe qui écrit les fonctions membres, cela revient à dire qu'un membre "protected" est "public" pour le concepteur de la classe mais "private" pour son utilisateur (alors que "private" signifie "définitivement private"). Notre but était simplement de montrer la façon d'utiliser les classes, savoir les instancier par new et les détruire par delete mais surtout savoir déclarer un tableau de pointeurs vers de tels objets et créer des tableaux d'informations parallèles tout en disposant dans les variables générales d'un matériel minimal d'accès à une classe active. C'est là que la notion de classe prend tout son sens, un tableau d'objets et l'accès à un objet actif à un moment donné.

Je conclus en disant qu'aussi aberrant que cela pourra sembler, une classe, ça n'existe pas. Cela peut paraître étrange à ce stade mais il en est ainsi. En effet, quand vous travaillez avec des classes, à aucun moment vous ne vous adressez au microprocesseur qui seul représente la réalité objective et physique, vous vous adressez uniquement au compilateur. C'est une façon de dire au compilateur "veillez à mes données, que les données encapsulées soient bien inaccessibles etc.". D'ailleurs, si vous traduisiez un programme C++ en assembleur, vous ne pourriez jamais poser le problème en termes de classes, ça n'aurait aucun sens et ça serait impossible. Une classe est donc une vue de l'esprit à l'intention du seul compilateur C++ qui vous aide ainsi à structurer vos données et vérifie notamment l'encapsulation. Vous avez ainsi la certitude (et c'est une assurance utile dans le travail en équipe) que les données privées ne sont jamais modifiées par l'utilisateur de la classe.

Je vous quitte par ce mot virgilien :  SAT PRATA BIBERUNT (troisième bucolique, 111).