Introduction à la Programmation Orientée Objet

25/07/2004

Par Hdd34 (Programmation générale)
 

Apprendre simplement la Programmation Orientée Objet

Attention ! Borland a longtemps employé le nom de Pascal Objet pour Delphi. Celui-ci a été récemment renommé langage Delphi. Nous n'aborderons pas dans ce tutoriel une approche spécifique à Delphi. Nous nous orienterons plus vers une approche générale du Pascal, tous compilateurs Pascal confondus sitôt que ceux-ci supportent la Programmation Orientée Objet, comme c'est le cas pour Turbo Pascal, FreePascal, GNU Pascal, ..., et bien sûr Delphi.

• Les champs :
  
  Les champs sont à l'objet ce que les variables sont à un programme : ce sont eux qui ont en charge les données à gérer. Tout comme n'importe quelle autre variable, un champ peut posséder un type quelconque défini au préalable : nombre, caractère, ..., ou même un type objet.
  
  
• Les méthodes :
  
  Les méthodes sont les éléments d'un objet qui servent d'interface entre les données et le programme. Sous ce nom obscur se cachent simplement des procédures ou fonctions destinées à traiter les données.

On notera souvent les membres d'un objet Objet.Membre de façon à lever toute ambiguïté quant au propriétaire du membre considéré.

• Les murs
• Le toit
• Une porte
• L'adresse
• La superficie

• Ouvrir le Bâtiment
• Fermer le Bâtiment
• Agrandir le Bâtiment

• Nombre de fenêtres
• Nombre d'étages
• Nombre de pièces
• Possède ou non un jardin
• Possède une cave

Attention ! Le concept de polymorphisme ne doit pas être confondu avec celui d'héritage multiple. En effet, l'héritage multiple - non supporté par le Pascal standard - permet à un objet d'hériter des membres (champs et méthodes) de plusieurs objets à la fois, alors que le polymorphisme réside dans la capacité d'un objet à modifier son comportement propre et celui de ses descendants au cours de l'exécution.

• Un objet peut ne pas avoir de constructeur explicite. Dans ce cas, c'est le compilateur qui se charge de créer de manière statique les liens entre champs et méthodes.
• Un objet peut avoir plusieurs constructeurs : c'est l'utilisateur qui décidera du constructeur à appeler. La présence de constructeurs multiples peut sembler saugrenue de prime abord, leur rôle étant identique. Cependant, comme pour toute méthode, un constructeur peut être surchargé, et donc effectuer diverses actions en plus de la construction même de l'objet. On utilise ainsi généralement les constructeurs pour initialiser les champs de l'objet. A différentes initialisations peuvent donc correspondre différents constructeurs.
• S'il n'est pas nécessaire de fournir un constructeur pour un objet statique, il devient obligatoire en cas de gestion dynamique, car le diagramme d'héritage ne peut être construit de manière correcte que lors de l'exécution, et non lors de la compilation.

• Tout comme pour les constructeurs, un objet peut ne pas avoir de destructeur. Une fois encore, c'est le compilateur qui se chargera de la destruction statique de l'objet.
• Un objet peut posséder plusieurs destructeurs. Leur rôle commun reste identique, mais peut s'y ajouter la destruction de certaines variables internes pouvant différer d'un destructeur à l'autre. La plupart du temps, à un constructeur distinct est associé un destructeur distinct.
• En cas d'utilisation dynamique, un destructeur s'impose pour détruire le diagramme créé par le constructeur.

Attention ! Les constructeurs des objets ne seront jamais déclarés comme virtuels, car c'est toujours le bon constructeur qui est appelé. Le caractère virtuel est donc inutile et sera même signalé comme une erreur par le compilateur. Par contre, les destructeurs seront toujours déclarés comme virtuels car souvent surchargés. Il n'en est pas de même pour les classes qui elles peuvent s'appuyer sur le principe de constructeur virtuel. C'est notamment le cas de Delphi avec les références de classes à propos desquelles la documentation donne plus de précisions. Vous pouvez aussi consulter les tutoriels suivants : * Cours sur la POO de Frédéric Beaulieu * Cours sur les métaclasses de Laurent Dardenne

Si jamais on utilise une méthode virtuelle sans avoir appelé au préalable un constructeur, le caractère virtuel ne sera pas pris en compte et les résultats seront imprévisibles.

• Avantage : Les méthodes dynamiques consomment moins de mémoire
• Inconvénient : La gestion interne des méthodes dynamiques est plus complexe, et donc plus lente

Les constructeurs et les destructeurs éventuels d'un objet devront bénéficier de la visibilité publique, sans quoi un programme externe ne pourrait pas les appeler !

Attention ! Un champ ne devra être public que si sa modification n'entraîne pas de changement dans le comportement de l'objet. Dans le cas contraire, il faut passer par une méthode. Modifier un champ "manuellement" et ensuite appeler une méthode pour informer de cette modification est une violation du principe d'encapsulation.

Cette visibilité est à bien considérer. En effet, si un descendant doit pouvoir accéder à un champ ou une méthode privé(e), alors ce descendant doit nécessairement être déclaré dans le même module que son ancêtre.

Cette visibilité est souvent à préférer à la visibilité privée, cependant elle n'est pas supportée par tous les compilateurs. Par exemple, Turbo Pascal ne la reconnaît pas.

type
  TObjetVide = object
  end;

Attention ! Sur les compilateurs de nouvelle génération, le mot réservé object sera remplacé par le mot réservé class.

type
  TObjetVide = class
  end;

type
  TParent = object
    Enfant: TEnfant;
  end;
  
  TEnfant = object
    Parent: TParent;
  end;

type
  { Déclaration des pointeurs }
  PParent = ^TParent;
  PEnfant = ^TEnfant;

  { Déclaration des objets utilisant les pointeurs }
  TParent = object
    Enfant: PEnfant;
  end;
  
  TEnfant = object
    Parent: PParent;
  end;

Sous Delphi, l'intanciation étant automatiquement dynamique, ce problème ne se pose pas, et pour résoudre le problème, on se contente d'annoncer la classe avec une déclaration partielle :

type
  { Déclarations partielles }
  TParent = class;
  TEnfant = class;

  { Déclaration des objets utilisant les classes }
  TParent = class
    Enfant: TEnfant;
  end;
  
  TEnfant = class
    Parent: TParent;
  end;

Attention ! Dans un objet, il convient de toujours déclarer les champs AVANT les méthodes. Si jamais un champ était déclaré après une méthode, alors le compilateur générerait une erreur (généralement, le compilateur indique qu'il attend un end au niveau du champ mal placé).

type
  TChose = object
    Entier: Integer;
    Chaine: string;
    Fichier: file;
  end;

type
  TBidule = object
    Enr: record
           A, B: Integer;
         end;
    Entier: Integer;
  end;

type
  TTruc = object
    Obj1: TChose;
    Obj2: object
            Champ: Char;
          end;
  end;

var
  Bidule: TBidule;
  Truc: TTruc;
  
begin
  ...
  Bidule.Enr.A := ...;
  ...
  Truc.Obj1.Entier := 0;
  Truc.Obj2.Champ := 'X';
  ...
end.

type
  TObjet = object
    Champ;
     ...
    Champ;
    Methode;
    ...
    Methode;
  end;

type
  TObjet = object
    Champs;
    ....
    procedure Methode1(Params: ParamType);
    function  Methode2(Params: ParamType): RetType;
  end;

type
  TObjet = object
    procedure Methode1(Param: ParamType);
  end;
  
  
procedure TObjet.Methode1(Param: ParamType);
begin
  ...
end;

type
  TObjet = object
    procedure Methode1(Param: ParamType);
  end;
  
  
procedure TObjet.Methode1;
begin
  ...
end;

type
  TObjet = object
    constructor Init(Param: ParamType);
  end;
  
  
constructor TObjet.Init;
begin
  ...
end;

Turbo Pascal utilise pour tous les objets standard la "convention Init", et Delphi pour sa part utilise la "convention Create".

type
  TObjet = object
    constructor Init;
   end;

constructor TObjet.Init;
begin
  ...
  { Fait échouer le constructeur }
  if ... then Fail;
end;

type
  TObjet = object
    destructor Done;
  end;
  
  
destructor TObjet.Done;
begin
  ...
end;

Turbo Pascal utilise pour tous les objets standard la "convention Done", et Delphi pour sa part utilise la "convention Destroy".

type
  TObjet = object
    procedure Methode(Param: ParamType); virtual;
  end;
  
procedure Methode(Param: ParamType);
begin
  ...
end;

type
  TObjet = object
    procedure Methode(Param: ParamType); virtual IndexUnique;
  end;
  
procedure Methode(Param: ParamType);
begin
  ...
end;

Sur les compilateurs plus récents, l'index est géré automatiquement, et il suffit pour déclarer une méthode dynamique de remplacer le mot réservé virtual par le mot réservé dynamic :

type
  TObjet = class
    procedure Methode(Param: ParamType); dynamic;
  end;
  
procedure TObjet.Methode(Param: ParamType);
begin
  ...
end;

Attention ! Si votre compilateur utilise le mot réservé object (comme Turbo Pascal), et si une méthode est déclarée avec le mot réservé virtual alors toutes les méthodes surchargées devront aussi être déclarées avec virtual. Il en sera de même avec les méthodes dynamiques. Si par contre votre compilateur utilise le mot réservé class, les méthodes surchargées devront être déclarées avec le mot réservé override. Consultez la documentation de votre compilateur pour plus de détails.

type
  TObjet = object
    procedure MethodeAbs;
  end;
  
procedure TObjet.MethodeAbs;  
begin
  { C'est une méthode abstraite }
  Abstract;
end;

Les nouveaux compilateurs utilisent le mot réservé abstract, et suppriment logiquement le corps de la méthode :

type
  TObjet = class
    { C'est une méthode abstraite }
    procedure MethodeAbs; abstract;
  end;

procedure TObjet.Methode;
begin
  Toto := 1;
end;

procedure TObjet.Methode;
begin
  Self.Toto := 1;
end;

type
  TObjet = object
    constructor Init;
  end;

var
  Instance: TObjet;

constructor TObjet.Init;
begin
  if Instance <> Self then Fail;
  ...
end;

begin
  Instance.Init;
  ...
end.

Le paramètre Self est toujours transmis en premier à la méthode. Ceci peut avoir son importance lors de l'utilisation de l'assembleur.

• Visibilité publique : public
• Visibilité privée : private
• Visibilité protégée : protected

type
  TObjet = object
  private
    ChampPriv;
    ...
    MethodePriv;
    ...
  public
    ChampPub;
    ...
    MethodePub;
    ...
  end;

Rappel La visibilité protégée n'est pas disponible sous Turbo Pascal.

type
  TObjet = object(TAncetre)
    ...
  end;

Attention ! Si vous désirez surcharger une méthode virtuelle, alors vous devez la redéclarer exactement comme elle était déclarée dans l'ancêtre. Notamment, vous ne pourrez pas ajouter ou supprimer de paramètres à sa déclaration. Par contre, si vous redéfinissez une méthode, alors vous pourrez très bien modifier ses paramètres comme vous le désirez si celle-ci n'est pas virtuelle.

type
  TAncetre = object
    Champ: Integer;
    procedure ModifChamp(Valeur: Integer); virtual;
    procedure ARedefinir;
  end;
  
procedure TAncetre.ModifChamp(Valeur: Integer);
begin
  Champ := Valeur;
end;

procedure TAncetre.ARedefinir;
begin
  ...
end;


type
  TDescendant = object(TAncetre)
    procedure ModifChamp(Valeur: Integer); virtual;
    procedure ARedefinir(ParamSup: Integer);
  end;
  
{ On surcharge la méthode virtuelle ModifChamp en la remplaçant par une autre }
procedure TDescendant.ModifChamp(Valeur: Integer);
begin
  { On accède au champ sans le redéclarer dans TDescendant }
  Champ := Valeur + 1;
end;

{ La méthode a été redéfinie avec de nouveaux paramètres }
procedure TDescendant.ARedefinir(ParamSup: Integer);
begin
  ...
end;

Il n'est pas nécessaire de surcharger ou de redéfinir une méthode ! Ainsi, si un objet ne surcharge pas une méthode, c'est celle du premier ancêtre la définissant ou la surchargeant qui sera appelée. De fait, il n'est pas nécessaire pour un objet de réécrire un constructeur (ou un destructeur) si celui de son ancêtre suffit à son initialisation.

type
  TAncetre = object
    Champ: Integer;
    procedure ModifChamp(Valeur: Integer); virtual;
  end;
  
procedure TAncetre.ModifChamp(Valeur: Integer);
begin
  Champ := Valeur;
end;


type
  TDescendant = object(TAncetre)
    Temp: Integer;
    procedure ModifChamp(Valeur: Integer); virtual;
  end;
  
procedure TDescendant.ModifChamp(Valeur: Integer);
begin
  { On effectue diverses actions }
  Inc(Valeur);
  { On appelle l'ancêtre }
  inherited ModifChamp(Valeur);
  { On peut effectuer d'autres actions }
  Temp := Champ;
end;

type
  TPremier = object
    ...
    procedure Methode; virtual;
  end;
  
procedure TPremier.Methode;
begin
  ...
end;


type
  TSecond = object(TPremier)
    ...
    procedure Methode; virtual;
  end;

procedure TSecond.Methode;
begin
  ...
end;

  
type
  TDernier = object(TSecond)
    ...
    procedure Methode; virtual;
  end;
  
procedure TDernier.Methode;
begin
  ...
  { On appelle TPremier.Methode : TSecond.Methode est ignorée }
  TPremier.Methode;
end;

constructor TDescendant.Init(...);
begin
  if not inherited Init(...) then Fail;
  ...
end;

• Constructeurs :
  D'une manière générale, le constructeur ancêtre devra être appelé en premier lieu, aucune autre instruction ne devant précéder cet appel.
  Cependant, il est possible d'effectuer diverses opérations en vue, par exemple, de transmettre une valeur en paramètre au constructeur ancêtre. Néanmoins, on s'abstiendra de toute modification de la valeur d'un champ avant l'appel à l'ancêtre, car cette valeur serait sujette à modification.
  
  

constructor TDescendant.Init(...);
begin
  { Première opération du constructeur : l'appel de l'ancêtre }
  if not inherited Init(...) then Fail;
  ...
end;

• Destructeur :
  De façon logique, l'appel au destructeur ancêtre devra se faire en dernier, une fois tous les champs du descendant nécessitant un traitement particulier désalloués proprement. En effet, une fois un destructeur appelé, il est impossible de prévoir la valeur d'un champ.

destructor TDescendant.Done;
begin
  ...
  { Dernière opération du destructeur : l'appel de l'ancêtre }
  inherited Done;
end;

type
  TObjet = object
    ...
  end;

var
  MonObjet: TObjet;

type
  TObjet = object
    ...
    constructor Init(...);
    destructor Done;
  end;

constructor TObjet.Init(...);
begin
  ...
end;

destructor TObjet.Done;
begin
  ...
end;


var
  MonObjet: TObjet;

begin
  ...
  MonObjet.Init(...);
  ...
  MonObjet.Methode;
  ...
  MonObjet.Done;
  ...
end.

L'instanciation statique présente plusieurs inconvénients, le principal concernant la mémoire. En effet, en mode réel sous DOS, seul 64 Ko de mémoire sont disponibles pour les variables statiques. Il en résulte donc une limitation drastique concernant le nombre d'objets en mémoire et leur taille.

L'instanciation statique a été supprimée sur les compilateurs récents comme Delphi, où la gestion est obligatoirement dynamique, mais en gardant une syntaxe équivalente à la syntaxe statique (suppression notamment de l'utilisation explicite des pointeurs).

type
  PObjet = ^TObjet;
  TObjet = object
    ...
  end;

• New(VarObjet, Constructeur);
  Avec cette syntaxe, on utilise New en tant que procédure en faisant apparaître en tant que deuxième paramètre le constructeur avec ses éventuels paramètres.

var
  Objet: PObjet;

begin
  New(Objet, Init(...));
  ...
end.

• VarObjet := New(PointeurTypeObjet, Constructeur);
  Cette syntaxe utilise la syntaxe étendue de New en l'utilisant en tant que fonction. On fait toujours apparaître en deuxième le constructeur affecté de ses divers paramètres. La différence vient du fait que l'on spécifie clairement de quel type l'objet doit être. Cette syntaxe permet plus de liberté en ce que l'on peut très bien affecter à un pointeur quelconque (un type descendant par exemple) un autre type objet.
  De plus, cette syntaxe se rapproche beaucoup de celle adoptée par les compilateurs plus récents comme Delphi. On pourra donc légitimement la préférer.

var
  Objet: PObjet;

begin
  Objet := New(PObjet, Init(...));
  ...
end.

Il est tout à fait possible d'allouer dans un premier temps l'objet comme n'importe quel pointeur avec New(Objet); et ensuite d'appeler le constructeur. Néanmoins, cette pratique est obsolète et on l'évitera au possible.

On n'oubliera pas lors de l'appel aux méthodes que l'on utilise dorénavant un pointeur. Le symbole ^ est donc de mise :

var
  Objet: PObjet;

begin
  ...
  Objet^.Methode(...);
  ...
end.

Attention ! Comme on travaille à présent avec des pointeurs, il faut vérifier que l'objet est bien alloué. On peut ainsi tester l'égalité avec nil ou bien utiliser la fonction interne Assigned :

var
  Objet: PObjet;

begin
  Objet := New(PObjet, Init(...));
  if Objet <> nil then
  begin
    ...
    Dispose(Objet, Done);
  end;
end.

var
  Objet: PObjet;

begin
  Objet := New(PObjet, Init(...));
  if Assigned(Objet) then
  begin
    ...
    Dispose(Objet, Done);
  end;
end.

Les compilateurs récents comme Delphi utilisent la syntaxe VarObjet := TypeObjet.Constructeur;, les pointeurs étant intégrés directement à la déclaration de la classe. Ils sont donc implicites. De plus, on se servira de blocs try...finally pour protéger son code :

type
  TObjet = class
    constructor Create(...);
  end;


var
  Objet: TObjet;

begin
  Objet := TObjet.Create(...);
  try
    ...
  finally
    ...
  end;
end;

var
  Objet: PObjet;

begin
  ...
  Dispose(Objet, Done(...));
end.

Tout comme pour les constructeurs, il est possible d'appeler le destructeur pour n'appeler que par la suite Dispose séparément. Cette pratique devra toutefois être évitée car obsolète et parfois source d'erreurs.

Delphi n'appelle pas directement le destructeur mais fait appel à la procédure Free :

var
  Objet: TObjet;

begin
  Objet := TObjet.Create(...);
  try
    ...
  finally
    TObjet.Free;
  end;
end.

type
  PObject = ^TObject;
  TObject = object
    constructor Init;
    destructor Done; virtual;
    procedure Free;
  end;

• Init :
  Le constructeur de TObject, en plus d'effectuer son rôle habituel (mise en place du diagramme d'héritage, VMT, ...), met à zéro tous les champs . Cette opération n'est en effet pas automatique pour un objet quelconque, et, par conséquent, tous les objets ne dérivant pas de TObject voient le contenu de leurs champs indéfini au moment de l'initialisation.
• Done :
  Le destructeur Done n'effectue rien ! Son seul intérêt réside dans le fait qu'il est déclaré comme virtuel. Par conséquent, tous les descendants devront implémenter un destructeur virtuel, ce qui permet d'éviter toute erreur due à l'oubli de la sorte.
• Free :
  La méthode Free permet de se dispenser de l'appel à Dispose. En effet, en appelant Free, l'objet se libère tout seul.

uses
  Objects;

type
  PChose = ^TChose;
  TChose = object(TObject)
  private
    ...
  public
    ...
    constructor Init(...);
    destructor Done; virtual;
  end;

constructor TChose.Init(...);
begin
  if not inherited Init then Fail;
  ...
end;

destructor TChose.Done;
begin
  ...
  inherited Done;
end;

...


var
  Chose: PChose;
  
begin
  Chose := New(PChose, Init(...));
  if Assigned(Chose) then
  begin
    ...
    Chose^.Free;
  end;
end.

Delphi impose par défaut TObject comme ancêtre si aucun ancêtre n'est spécifié lors de la déclaration d'une classe. Ainsi, les deux exemples suivants sont équivalents :

type
  TObjet = class
    ...
  end;

type
  TObjet = class(TObject)
    ...
  end;

Liens à consulter en complément : * Cours sur la POO de Frédéric Beaulieu * Cours sur les métaclasses de Laurent Dardenne * Les exemples de code illustrant le livre de John Colibri