Un langage associé au procédural qui a intégré l'objet depuis longtemps
Pascal reste souvent identifié à l'enseignement de la programmation structurée : algorithmes, boucles, procédures, tableaux. Cette réputation occulte une réalité plus ancienne. Les compilateurs Pascal majeurs ont intégré des extensions orientées objet dès les années 1980 et 1990, notamment sous l'impulsion de Borland avec Turbo Pascal puis Delphi, et plus tard avec Free Pascal et Lazarus.
Le résultat est un objet qui ne ressemble pas tout à fait à celui de Java ou de Python. Le Pascal objet s'est construit par couches successives, en conservant la compatibilité avec le code procédural existant. Cette généalogie explique plusieurs choix de conception qui déroutent parfois les développeurs venus d'autres écosystèmes.
Il faut distinguer deux variantes. La première, héritée de Turbo Pascal, repose sur le mot-clé object et reste très proche des enregistrements. La seconde, popularisée par Delphi et reprise par Free Pascal, utilise le mot-clé class et se rapproche davantage des modèles objet courants. Les deux coexistent dans un même compilateur, ce qui n'aide pas toujours à la clarté.
Classes, objets et méthodes : la mécanique de base
Une classe Pascal se déclare dans une section type, avec une partie interface et une partie implémentation. Les champs décrivent l'état, les méthodes décrivent le comportement. La syntaxe impose de séparer la déclaration de la méthode et son corps, ce qui produit un code plus verbeux que dans d'autres langages mais rend la structure visible d'un coup d'œil.
Un point mérite attention : la gestion mémoire diffère selon la variante. Les instances de type object sont généralement allouées sur la pile ou dans des variables statiques, sans libération automatique. Les instances de type class sont allouées sur le tas et doivent être libérées explicitement, sauf usage de mécanismes de propriété offerts par les bibliothèques de composants.
Cette distinction a des conséquences pratiques. Un objet alloué sur la pile disparaît à la fin de la portée, ce qui simplifie certains cas et en complique d'autres, notamment lorsqu'une référence doit survivre à la fonction qui l'a créée. Le développeur doit donc savoir quel type d'objet il manipule avant d'écrire du code de gestion de ressources.
Les constructeurs et destructeurs sont nommés Create et Destroy par convention, sans que le langage impose ces noms. La convention est si répandue qu'elle fonctionne comme une règle implicite dans la plupart des bases de code.
Héritage, encapsulation et polymorphisme dans la pratique
L'héritage simple est supporté nativement : une classe dérive d'une seule classe parente. Le Pascal objet ne propose pas d'héritage multiple de classes, ce qui évite le problème du diamant mais oblige à recourir à d'autres mécanismes, comme les interfaces, lorsque plusieurs contrats doivent être satisfaits simultanément.
Le polymorphisme repose sur le mot-clé virtual dans la déclaration de la méthode parente, et sur override dans la classe fille. Une méthode non marquée virtuelle est résolue statiquement : la redéfinir dans une sous-classe ne change rien au comportement lorsqu'elle est appelée via une référence parente. Cette règle, explicite, évite les surprises mais surprend les développeurs habitués à un polymorphisme implicite.
L'encapsulation s'appuie sur des sections private, protected et public. La visibilité par défaut varie selon la variante et le compilateur, ce qui constitue une source classique d'erreurs de conception. En pratique, les équipes précisent systématiquement la visibilité plutôt que de compter sur la valeur par défaut.
Les propriétés, introduites avec Delphi, offrent une syntaxe d'accès aux champs via des méthodes de lecture et d'écriture. Elles permettent de modifier l'implémentation interne sans casser l'interface publique, ce qui reste l'un des apports les plus durables de cette variante.
Ce que l'objet pascalien apporte encore, et ce qu'il coûte
La coexistence du procédural et de l'objet dans un même fichier constitue un avantage concret pour les bases de code anciennes. Une application peut migrer progressivement, module par module, sans réécriture complète. Peu de langages offrent cette continuité avec autant de stabilité dans le temps.
Le prix à payer tient à la verbosité et à la dispersion. La séparation entre déclaration et implémentation, la gestion manuelle de la mémoire dans le modèle class, et la présence de deux variantes d'objet dans un même compilateur alourdissent l'apprentissage. Les outils modernes compensent partiellement ces frictions, mais la courbe reste plus raide que dans les langages à garbage collector intégré.
- Le modèle object convient aux structures légères et aux contextes où l'allocation dynamique n'est pas souhaitable.
- Le modèle class convient aux hiérarchies riches, aux propriétés et aux composants réutilisables.
- Les interfaces permettent de contourner l'absence d'héritage multiple de classes.
Le Pascal objet ne se prête pas à tous les usages. Pour des scripts courts ou des prototypes jetables, la mise en place d'une hiérarchie de classes représente un investissement difficile à justifier. De même, les projets nécessitant une forte concurrence native trouvent souvent des réponses plus directes dans d'autres écosystèmes.
L'orientation objet en Pascal reste however un sujet vivant, porté par des communautés actives autour de Free Pascal et de Delphi. Les évolutions récentes portent davantage sur l'outillage, la compatibilité multiplateforme et les bibliothèques que sur le langage lui-même, dont les fondations objet n'ont que peu bougé. Cette stabilité est à la fois une force pour la maintenance et une limite pour l'adoption de paradigmes plus récents.
