[Débutant]Différence Delphi. / Java

Version imprimable

13/08/2005, 15h42
Pill_S

[Débutant]Différence Delphi. / Java
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 :D

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:

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 :wink:

BIG :merci: d'avance :wink:

Séb
13/08/2005, 17h16
Reisubar
Citation:

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é.

Citation:

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.

Citation:

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.

Citation:

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:

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.

Citation:

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.

Citation:

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 !
14/08/2005, 00h11
skywaukers

bonjour,

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

@++
Dany

Citation:

Envoyé par Reisubar

Citation:

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é.

Citation:

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 ?
Citation:
Envoyé par Reisubar
Citation:

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:

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 ?

Citation:

Envoyé par Reisubar

Citation:

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:

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;
Citation:

Envoyé par Reisubar

Citation:

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.

Citation:

Envoyé par Reisubar

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:

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.... :koi: 'comprend pô !

Citation:

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:

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:

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;

Citation:

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 :mrgreen:

Citation:

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

Voilà son prototype :

Code:

constructor Create(AOwner: TComponent); virtual;

Citation:

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:

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

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.

Citation:

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.

Citation:

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:

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;

14/08/2005, 14h45
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 :wink:

@++!

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

Code:

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:

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.

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

ex:
Code:

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 :wink:

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:

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:

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:

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;

14/08/2005, 16h57
Pill_S

Citation:

Envoyé par Reisubar

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 ?

Citation:

Envoyé par Reisubar

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

ça, c'était avant que tu ne me prouves le contraire :wink: !
14/08/2005, 17h33
tourlourou

dans un post récent, Clorish (je crois) rappelais les plus courantes
14/08/2005, 17h34
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 :-)
16/08/2005, 13h25
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 :wink: promis, après j'arrête de vous embêter !
16/08/2005, 20h17
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.
16/08/2005, 21h43
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.

@++ !