Revenir au sommaire Tutoriaux

 

TUTORIAL DelphiX N°2 - La notion d'objet - sur LioCity http://Liocity.free.fr

Un objet c'est quoi ??
 

Un objet est une partie d'un programme qui dispose de ses propres Procédures, Fonctions (ou méthodes)... par exemple le plus connu est l'objet Form1 qui est généré automatiquement par Delphi lorsqu'on créer un nouveau projet. Sans le savoir nous utilisons déjà des objets...tous les objets commencent par : MonObjet=class(xxxx), et finissent par : end; Les objets sont définis dans la partie TYPE du programme. Un objet est une bulle à l'interieur de mon programme qui posséde ses propres fonctions, mais aussi celles d'autres objets...hein...comprend pas...!!....Pas de panique, lorsqu'on déclare (on crée) un nouvel objet, on le fait toujours en prenant appuis sur un autre (Dérivation). Je m'explique :si dans l'exemple MonObjet=class(xxxx), Monobjet et le nom de l'objet que je veux créer, xxxx est l'objet sur lequel je vais m'appuyer pour le créer...en d'autres termes mon nouvel objet Monobjet aura toutes les propriétés (méthodes) de l'objet xxxx. Cette particularité se nomme Héritage...logique non ? (Pour mémo : un objet a bien d'autres particularités, encapsulage, polymorphisme....)

TYPE  
  MonObjet=CLASS(TimageSpriteTDXFORM);
  Procedure DoMove(movecount:integer);
  END;
   
Un objet à quoi ça sert ??
 

Quel interet ?? à première vue pas à grand chose...il n'y a qu'à voir tout ce que j'ai réalisé sans utiliser la création d'objets dans la partie de mon site consacrée à Delphi sans les composants de DelphiX...Mais voilà DelphiX change quelque peu ma façon de voir les choses, surtout avec le moteur de Sprites (TDXSpriteEngine)...Alors quel interet ?? eh, bien cette technique permet de mieux structurer ses Sprites...et de faire une économie importante de lignes à écrire. Plus besoin de gérer des dizaines de variables pour quelques Sprites, ni de reinventer la poudre à chaque nouveau Sprite que l'on ajoute ou que l'on veut attribuer de nouvelles fonctions (trajectoire, image...) à un nouveau Sprite...Mais bien sur cela marche avec tout, pas seulement avec les Sprites. Je ne suis pas partisant de programmer en Objet partout, c'est normal quand il s'agit d'une société qui veut rentabiliser le temps qu'elle a passé à développer certaines parties de code, mais quand il s'agit de programmes personnels, dont on aura pas forcement le besoin de réutiliser certaines parties, cela ne s'impose pas...je sais les pros de l'Objet vont m'en vouloir et dire que je n'ai rien compris, mais...c'est mon avis..voilà! Tout dépend de son niveau et de l'utilisation de ses programmes.

Un objet comment on s'en sert ??
 

..Comment ??? Tout simplement en créant un Sprite de base (qui par exemple ne peut se déplacer que vers la droite ou la gauche)...Pour créer un Sprite qui peut aller vers la droite et vers la gauche et qui saute il suffit de faire réference à mon Sprite de base MonSprite=class(SpriteDeBase) pour ne pas avoir à réécrire une bonne partie de la gestion de MonSprite, il faudra juste Surcharger la méthode qui permet de faire bouger MonSprite...Surcharger ?, c'est quoi ce truc ? et bien, lorsque on crée un Sprite avec l'aide d'un autre, on récupere tout ce qui va avec (l'Héritage)...donc pour modifier une méthode (procédure) il suffit de réécrire la définition de la méthode (procédure) que l'on veut changer dans l'objet que l'on vient de créer en ajoutant à la fin OVERRIDE. Cela indique que la méthode existe dans les 2 objets et qu' il faudra exécuter le code de MonSprite au lieu d'utiliser le code Herité (de SpriteDeBase)... Dans la méthode (procédure) à modifier il faut obligatoirement commencer (juste aprés le BEGIN) par la ligne : INHERITED + nom_de_la_procedure+parametres

TYPE  
  SPRITE1=CLASS(TimageSpriteTDXFORM);
  Procedure DoMove(movecount:integer);
  END;
   
 

MonObjet=CLASS(SPRITE1);

  Procedure DoMove(movecount:integer);OVERRIDE;
  END;
   
INTERFACE  
 
PROCEDURE SPRITE1.DoMove(MoveCount:integer);
BEGIN  
// ecrire le code de deplacement de SPRITE1
END;  
 
PROCEDURE MonObjet.DoMove(MoveCount:integer);
BEGIN  
INHERITED=DoMove(MoveCount);
  // ecrire le code qui va remplacer celui de SPRITE1
END;  

Chaque objet doit être conçu comme un individu qui doit se gérer tout seul face à toutes les situations...! C'est dans ce but qu'en règle générale un objet posséde par défaut 2 méthodes: CONSTRUCTOR (qui va permettre de réserver la place mémoire de l'objet en déclarent les diverses variables utiles) et DESTRUCTOR (qui va à l'inverse libérer la place mémoire tenue par l'objet). L'objet est autonome et peut s'allouer ou se déallouer en fonction d'évènements spécifiques. L'exemple d'un Sprite reprend se mode de fonctionnement (dans le cas d'une collision, tant que les 2 sprites ne se sont pas rencontrés ils continuent d'exister et à bouger en fonction de leurs programmation. Dés qu'ils se touches ils disparaissent (le cas d'un tir qui rencontre un ennemi). On peut faire disparaitre un Sprite de l'écran, mais cela n'empêchera pas l'ordinateur de le garder en mémoire tant qu'il ne sera pas détruit pas le DESTRUCTOR. C'est trés important car la mémoire n'est pas illimitée , et pour éviter tout débordement il faut faire proprement le ménage. Avec DelphiX, il est si facile de créer des Sprites qu'il ne faut jamais oublier de les supprimer quand ils ne servent plus....

Revenir au sommaire Tutoriaux

Hit-Parade