Discussion :

[Pill_S]

Bonjour tout le monde,

je viens du monde java, et récemment on m'a confié un projet delphi (je n'avais jamais tapé 1 seule ligne de pascal avant).

Je connais bien les concepts de POO et les ai souvent mis en application avec Java. J'aimerais juste quelques précisions au sujet de delphi, et si possible des comparaisons et équivalences par rapport à java. Merci d'avance

1ère question: quel est le niveau d'accès des variables et méthodes déclarées juste sous la définition d'une classe ? Pourquoi ne puis-je pas déclarer privés les boutons et autres composants de ma fiche principale ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
  TPoint=class(TObject)
      procedure t1; // <-- this one
    private
      ...
    public
      ..
  end;

2è: comment déclare-t-on des constantes internes à une classe ? (équi. de "private final static int I = 0;")

3: si on tente de redéfinir une méthode non virtuelle, c'est le code de la classe parente qui est exécuté lors de l'appel ? Et si on redéfinit une méthode virtuelle en omettant de la déclarer virtuelle, empêche-t-on la redéfinition pour tous les descendants ?

4: retrouve-t-on la notion de "static" (au sens java du terme, c-à-d déclaration de champs et méthodes de classe et non d'instance) avec delphi ? et pour les interfaces (contrat générique sans implémentation à respecter par une classe afin d'appartenir à un type) ?

5: euh... j'en ai encore pleins, mais j'ai pas envie de vous décourager


BIG d'avance

Séb

[Reisubar]

quel est le niveau d'accès des variables et méthodes déclarées juste sous la définition d'une classe ?

Public. Mais attention, la visibilté de composants dans une même unité est toujours publique. Les qualificateurs de visibilité sont réellement actif lorsqu'on "sors" de l'unité.

Pourquoi ne puis-je pas déclarer privés les boutons et autres composants de ma fiche principale ?

Parce que sinon Delphi ne pourra pas les instancier à la création de la fenêtre.

comment déclare-t-on des constantes internes à une classe ? (équi. de "private final static int I = 0;")

Ca ne se fait pas trop... Tout dépend la version du langage, à partir de Delphi 8 on peut définir des variables de classe (statiques) avec le mot clé class var.

si on tente de redéfinir une méthode non virtuelle, c'est le code de la classe parente qui est exécuté lors de l'appel ?

C'est le code de la classe actuelle et non de la classe construite qui est utilisée, comme dans tous les langages je crois. Dans l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
TCar = class
     procedure Roule;
 end;
 
TRover = class (TCar)
     procedure Roule;
end;
 
procedure Foo(ACar: TCar);
begin
  ACar.Roule;
end;

... Même si je crée un objet TRover et que je le passe à Foo, TCar.Roule sera toujours appellé par Foo.

Et si on redéfinit une méthode virtuelle en omettant de la déclarer virtuelle, empêche-t-on la redéfinition pour tous les descendants ?

Oui, puisque Delphi te dira qu'il est impossible de surcharger une méthode statique.

retrouve-t-on la notion de "static" (au sens java du terme, c-à-d déclaration de champs et méthodes de classe et non d'instance) avec delphi

Oui, avec class function, class procedure, et class var.
Comme dit récemment, class var apparait dans les versions récentes de Delphi... Pour les interfaces, je n'en sais rien.

Bon courage !

[skywaukers]

bonjour,

les interfaces existent aussi (interface à la place de Class) et permettent un héritage multiple (comme dans Java aussi je crois).

@++
Dany

[Pill_S]

quel est le niveau d'accès des variables et méthodes déclarées juste sous la définition d'une classe ?

Public. Mais attention, la visibilté de composants dans une même unité est toujours publique. Les qualificateurs de visibilité sont réellement actif lorsqu'on "sors" de l'unité.

Pourquoi ne puis-je pas déclarer privés les boutons et autres composants de ma fiche principale ?

Parce que sinon Delphi ne pourra pas les instancier à la création de la fenêtre.

OK, je comprend mieux, l'instanciation de la fiche principale est faite à partir d'une autre classe. En java, j'avais l'habitude de faire en sorte que chaque composant instancie lui-même ses sous-composants... Puis-je reproduire le même comportement avec delphi (pour mieux respecter l'encapsulation) ? Quel est le constructeur utilisé par delphi pour instancier la fiche ? Puis-je le redéfinir afin d'exécuter du code dès la création ?

si on tente de redéfinir une méthode non virtuelle, c'est le code de la classe parente qui est exécuté lors de l'appel ?

C'est le code de la classe actuelle et non de la classe construite qui est utilisée, comme dans tous les langages je crois. Dans l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
TCar = class
     procedure Roule;
 end;
 
TRover = class (TCar)
     procedure Roule;
end;
 
procedure Foo(ACar: TCar);
begin
  ACar.Roule;
end;

... Même si je crée un objet TRover et que je le passe à Foo, TCar.Roule sera toujours appellé par Foo.

ah! là je crois qu'on est tombé sur une différence fondamentale. En java, si je passe une instance de TRover à une méthode qui accepte un TCar, c'est le code de TRover qui sera exécuté (liaison dynamique automatique). En delphi, pour reproduire ce comportement, il faut passer par le mot-clé virtual c'est bien ça ?

Et si on redéfinit une méthode virtuelle en omettant de la déclarer virtuelle, empêche-t-on la redéfinition pour tous les descendants ?

Oui, puisque Delphi te dira qu'il est impossible de surcharger une méthode statique.

donc, si je comprend bien, ceci est impossible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
type
  TCar = class(TObject)
    procedure roule; virtual;
  end;
 
  TRover = class(TCar)
    procedure roule; // <- erreur compile, car méthode pas virtuelle ?
  end;

retrouve-t-on la notion de "static" (au sens java du terme, c-à-d déclaration de champs et méthodes de classe et non d'instance) avec delphi

Oui, avec class function, class procedure, et class var.
Comme dit récemment, class var apparait dans les versions récentes de Delphi... Pour les interfaces, je n'en sais rien.

Ok, je tourne en delphi 6 donc je vais laisser tomber les variables de class.

Bon courage !

merci, j'en aurai bien besoin ! Mais grâce à vous, je commence un peu à cerner les différences... Merci !

Encore une question: je ne comprend pas pourquoi je ne peux pas invoquer les méthodes publics getX et getY depuis une autre unit dans cet exemple ? "public" autorise l'accès de n'importe quelle class et unit non ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
  { Classe Point }
  TPoint = class(TObject)
      constructor Create(); overload;
      constructor Create(px:Integer); overload;
      constructor Create(px, py:Integer); overload;
      procedure setX(px:Integer);
      procedure setY(py:Integer);
      procedure setXY(px,py:Integer);
      function getX():Integer;
      function getY():Integer;
      destructor Destroy(); override;
    private
      x, y : Integer;
    public
  end;

.... par contre, j'arrive à accéder à x et y (privés !) depuis d'autres unit.... 'comprend pô !

[tourlourou]

Quel est le constructeur utilisé par delphi pour instancier la fiche ? Puis-je le redéfinir afin d'exécuter du code dès la création ?

c'est TForm1.Create, que tu peux bien sûr surcharger pour tes propres traitements :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
constructor Create(AOwner : TComponent); override;
 
constructor TForm1.Create(AOwner : TComponent);
begin
 inherited; // pour l'appel à TForm.Create(AOwner);
// ici tes propres traitements spécifiques
end;

pout la classe Point tu peux définir une propriété :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
type TMyPoint=class
Private
 Fx, Fy : integer;
Public
 procedure SetX(Ax : integer);
 function GetX : integer;
 property X : integer read GetX write SetX; // définit les méthodes accesseurs qui seront seules habilitées par le concepteur à manipuler les champs privés Fx et Fy
end;

[Reisubar]

Puis-je reproduire le même comportement avec delphi (pour mieux respecter l'encapsulation) ?

C'est possible, à condition de ne plus utiliser l'IDE pour créer tes interfaces... Il faudra alors créer, placer, manipuler, et détruire tes composants par code. C'est relativement lourd, et c'est pour éviter ça que Delphi te propose justement un joli éditeur de fenêtres

Quel est le constructeur utilisé par delphi pour instancier la fiche ?

Voilà son prototype :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

constructor Create(AOwner: TComponent); virtual;

Puis-je le redéfinir afin d'exécuter du code dès la création ?

Bien sûr. Cela donnerait un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
constructor Create(AOwner: TComponent); override;
begin
  inherited; //Appel du constructeur parent
  //Code à toi ici
end;

En java, si je passe une instance de TRover à une méthode qui accepte un TCar, c'est le code de TRover qui sera exécuté (liaison dynamique automatique)

Je me suis peut être mal exprimé avant, désolé. Ici, c'est bien le cas, mais comme la méthode n'est pas virtuelle (ou dynamique), c'est le code de la classe TCar qui est exécuté. Effectivement, en Delphi, les méthodes ne sont pas "automatiquement" virtuelle. Comme tu le dis, l'utilisation de virtual modifie ce comportement pour que le code de TRover soit appelé à l'exécution.

donc, si je comprend bien, ceci est impossible:

Si c'est possible, mais c'est mal et pas souhaitable. Delphi te dira quelque chose du style : "La méthode 'Roule' cache la méthode virtuelle du type de base 'TCar'". En gros cela fera comme si TCar.Roule n'était pas déclarée virtuelle.

je ne comprend pas pourquoi je ne peux pas invoquer les méthodes publics getX et getY depuis une autre unit dans cet exemple ?

Hum, ca devrait marcher, si tu "inclues" bien via Uses ton unité dans l'unité appellante. Tu devrais cependant explicitement utiliser public pour tes méthodes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  { Classe Point }
  TPoint = class(TObject)
  private
      x, y : Integer;
   public
      constructor Create(); overload;
      constructor Create(px:Integer); overload;
      constructor Create(px, py:Integer); overload;
      procedure setX(px:Integer);
      procedure setY(py:Integer);
      procedure setXY(px,py:Integer);
      function getX():Integer;
      function getY():Integer;
      destructor Destroy(); override;
  end;

[Pill_S]

OK, merci à tous pour vos précisions !

Je commence à trouver mes repères maintenant, grâce à vous !

J'aurais encore quelques extraits de code à vous soumettre (pour critiques), si ça ne dérange pas. Je les posterai dès qu'ils seront prêts

@++!

[Pascal Jankowski]

Avec Delphi on peut utiliser la notion de propriétés (je ne sais pas si c'est possible avec Java)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
{ Classe Point } 
  TPoint = class(TObject) 
  private 
      x, y : Integer; 
   public 
      ... 
      procedure setX(px:Integer); 
      procedure setY(py:Integer); 
      procedure setXY(px,py:Integer); 
      function getX():Integer; 
      function getY():Integer; 
      ... 
  end;

Peut encore s'écrire de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
TPoint = class(TObject)
    private
      FX,FY: integer;
 
      procedure setX(Value: integer);
      function getX:integer;
 
      procedure setY(Value: integer);
      function getY:integer;
      ...
    public
 
      property X: integer read getX write setX default 0;
 
      property Y: integer read getY write setY default 0;
 
  end;
 
implementation
 
procedure TPoint.setX(Value: integer);
begin
  FX := Value;
  //autres actions devant être produites
  //lors de l'assignation de Value à la propriété X
end;
 
function TPoint.getX:integer;
begin
  result := FX;
  //autres actions devant être produites
  //lors de la lectrure de la propriété X
end;
...

Cela simplifie le code quand on utilise la classe TPoint.

[Pill_S]

ah oui, les propriétés...... ça sert à utiliser des identificateurs de variables au lieu des fonctions ?

ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
type
  TPoint = class
    private 
      x,y:integer;
      procedure setX(value:integer);
      function getX:Integer;
 
    public
      property PX:Integer read getX write setX;
  end;

maintenant, si j'écris "aPoint.PX", en arrière plan ça va invoquer "aPoint.getX()" ? c'est bien ça ?

et si j'écris "aPoint.PX := 0;", cela va exécuter "aPoint.setX(0);" ?


je ne remarque certainement pas toutes les subtilités que ça amène, mais je trouve que le gain en lisibilité est assez faible, non ?

PS: non, on ne retrouve pas ce concept en java

[Reisubar]

Quelques remarques.

Premièrement, tu n'est pas obligé d'associer à des propriétés des getters et des setters, tu peux aussi associer pour read, write ou les deux directement une variable privée. Cf. l'exemple de code ci-dessous.

Ensuite, pour écrire tes propriétés, si tu ne connais pas encore très bien Delphi, tu peux procéder ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

property Height : Integer read FHeight; [Maj+Ctrl+C]

Après avoir pressé Maj+Ctrl+C, Delphi t'insérera le prototype des getters/setters, les variables correspondantes et l'implémentation du code.

De même, par convention, les variables accédées via des propriétés commençent par un F". Tu n'est évidemment pas obligé de procéder ainsi, mais cela peut standardiser le style de ton code.

Ensuite, quelques intérêts des propriétés (tu semble douter que cela serve vraiment à quelque chose ;-)

1. Limiter l'écriture d'une variable avec les accesseurs read et write. Tu peu rendre ainsi une propriété en lecture seule ou écriture seule (peu d'intérêt ?)

2. Effectuer un contrôle lors de l'affectation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

property Carburant: Integer read FCarburant write SetCarburant;

En lecture pas de problème : la valeur de la variable privée est renvoyée.
En écriture, une fonction peut contrôler la validité de l'affectation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
procedure SetCarburant(const AValue: Integer);
begin
  if FCarburant <> AValue then
  begin
     if AValue<= 0 then
       raise ECarburantError.Create('Pas assez de carburant !');
     if FCarburant + AValue > FTailleReservoir then
       raise ECarburantError.Create('Trop d''essence mon garçon !');
     FCarburant = AValue; //Sinon, on assigne.
  end; 
end;

[Pill_S]

De même, par convention, les variables accédées via des propriétés commençent par un F". Tu n'est évidemment pas obligé de procéder ainsi, mais cela peut standardiser le style de ton code.

intéressant, j'ai toujours essayé de respecter les conventions de nommage dans mon code....
auriez-vous une adresse qui en fait le listing ?

tu semble douter que cela serve vraiment à quelque chose ;-)

ça, c'était avant que tu ne me prouves le contraire !

[tourlourou]

dans un post récent, Clorish (je crois) rappelais les plus courantes

[Reisubar]

Pour les conventions, voilà celles énoncées par Borland :

http://community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.html

Si tu as les sources de la VCL, tu peux constater qu'elles sont en grandes parties respectées. Ceci dit cela ne reste pas un dogme d'écriture absolu :-)

[Pill_S]

Re-Bonjour tout le monde,

(merci pour les conventions ; - ) )

j'aimerais savoir si quelqu'un peut me corriger (et critiquer) le code suivant:

• http://www.hmcrecord.ch/ProjetPoints.zip (333Ko)

Je n'ai pas voulu poster directement le code ici, je pense que cela n'est pas utile.

Le code n'est pas commenté (sorry!) mais il n'est pas bien compliqué (vous aurez peut-être remarqué la petite pointe de java dans le style...):
une classe TDot (symbolise un point), la fiche principale qui gère un "array of TDot" et permet de le manipuler grossièrement, et une deuxième fiche qui permet d'éditer les champs des points.

Ce qui m'intéresse, c'est de savoir si tout vous semble bon, de la gestion mémoire à celle des exceptions, etc... Merci beaucoup promis, après j'arrête de vous embêter !

[Pascal Jankowski]

Pour commencer, tu ne nous embètes aucunement et bien au contraire.

Effectivement, on sent comme un petit accent étranger à delphi dans l'écriture, mais cela ne me dérange pas. L'influence Java cela doit être certainement cela.
En ce qui me concerne, je ne vois rien d'étrange dans ton code. Sauf peut-être l'unit QControl à retirer si l'on ne possède pas QT.

Sinon tout est parfait et correct.

[Pill_S]

extra 8)

maintenant je peux me lancer dans mon projet l'esprit tranquil. Finalement c'est pas si différent de java (peut-être un chouilla moins puissant côté algo, mais tellement plus pratique pour les GUI !)

Merci encore, surtout à Reisubar et Pascal. Si un jour vous migrez sur le langage de Sun, je me ferais un plaisir de vous aider à mon tour.

@++ !