Discussion :

[peter27x]

Bonjour,

étant habitué aux getter/setter propre à Java, fonctions permettant la gestion des variables privées d'une classe, je me trouve confronté à la logique Delphi, dans une appli existante que je remanie, qui consiste à définir une variable de type property, avec un read et un write qui indiquent la variable privée directement : autant la mettre en public alors !

Je trouve plus logique le système getter/setter, dans lesquels on peut aller mettre du code garde fou préservant l'intégrité des variables privées, plutot que ce système du property.

Evidemment, on peut transformer la destination des read et write du property vers des procédures de type get() et set(), mais alors dans ce cas à quoi bon ajouter une notion de property dans tout ça, ça fait une étape et une variable de plus pour chaque variable privée...

Vos avis de Delphistes endurcis m'intéressent !

Merci.


EDIT: vous l'aurez compris, je code donc mon appli Delphi avec des getter et setter Javanais.

[chaplin]

D'un point de vue lisibilité, je préfère property à Get/Set, car je lis la propriété comme une variable et non "deux" variables disctinctes au sens de Get pour renvoyer une valeur et Set pour modifier la valeur, alors qu'au fond on travaille avec la même "variable".

Ce que tu décris, c'est la notion d'encapsulation, c'est à dire de voir une objet comme une boîte noire et que les variables (private) en internes sont accedés par des méthodes (fonction ou procédure).

En fait, tu peux avoir la même representation en Java avec Delphi, mais ce dernier est plus riche avec l'emploi de property.

Si une propriété est déclarée en interne et accéder simplement par une property publiée, t'as pas besoin d'implémenter les get et les set.
Ces derniers deviennent interessant quand tu dois rajouté des traitements.

C'est plus souple, mais rien n'empêche d'écrire à la façon Java.

[peter27x]

Ce que tu décris, c'est la notion d'encapsulation, c'est à dire de voir une objet comme une boîte noire et que les variables (private) en internes sont accedés par des méthodes (fonction ou procédure).

En fait, tu peux avoir la même representation en Java avec Delphi, mais ce dernier est plus riche avec l'emploi de property.

Si une propriété est déclarée en interne et accéder simplement par une property publiée, t'as pas besoin d'implémenter les get et les set.

Oui mais dans ce cas cette variable doit être publique puisque on peut y "entrer" comme dans un moulin... non ? Et du coup exit l'utilité du property... non ?

Enfin, je chipotte, je chipotte, je sais...

[Aka Guymelef]

L'avantage d'une propriété est que tu peux changer simplement sa portée d'une classe à l'autre alors que pour un champ ben ça ne me semble pas possible => le compilateur interpréterais comme une redéclaration du champ dans la classe.

En outre les propriété déclarée "publiée" génèrent des RTTI, chose nécessaire pour faire de la réflexion.

C'est aussi indispensable pour faire apparaître des propriétés (c'est le cas de le dire) dans l'inspecteur d'objet en mode conception pour les composants visuels.

[peter27x]

L'avantage d'une propriété est que tu peux changer simplement sa portée d'une classe à l'autre alors que pour un champ ben ça ne me semble pas possible => le compilateur interpréterais comme une redéclaration du champ dans la classe.

En outre les propriété déclarée "publiée" génèrent des RTTI, chose nécessaire pour faire de la réflexion.

C'est aussi indispensable pour faire apparaître des propriétés (c'est le cas de le dire) dans l'inspecteur d'objet en mode conception pour les composants visuels.

Ha ok, ça induit des fonctionnalités supplémentaires... merci de l'info.

[Aka Guymelef]

En outre, dans les versions récentes de Delphi, on peut aussi déclarer des propriétés (avec des Get-Set obligatoire) au niveau des interface ce qui revient quasiment à forcer l'obligation d'avoir le champ correspondant pour toute classe implémentant l'interface.

[ShaiLeTroll]

EDIT: vous l'aurez compris, je code donc mon appli Delphi avec des getter et setter Javanais.

Pour avoir fait du Java, cela ne met choque pas,

en gros tu ne mets jamais

Code :

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

1
2
3
4
private
  FChamp: string;
public
  property Champ: string read FChamp write FChamp

Moi, je le fais systématiquement, je desteste ça

Code :

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

1
2
public
  Champ: string;

je trouve ça tellement pauvre, cela n'entrevoit pas d'éventuel modification (sérialization, héritage, ...), je trouve le property tellement plus visuel et proprement objet


Donc, si tu es Javanais, tu dois toujours écrire ça

Code :

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

1
2
3
4
5
6
7
8
private
  FChamp: string;
protected
  function Getchamp: String;
  procedure SetChamp(Value: string);
public
  property Champ: string reag GetChamp write SetChamp;
end;

Encore plus verbeux mais ça me va aussi !

mais tu peux imaginer plein de variante, comme la lecture, comme le setters avec "garde fou" mais la lecture libre

Code :

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

1
2
3
4
5
6
7
private
  FChamp: string;
protected
  procedure SetChamp(Value: string);
public
  property Champ: string reag FChamp write SetChamp; // Lecture Libre, Setter controlé 
end;

Code :

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

1
2
3
4
5
private
  FChamp: string;
public
  property Champ: string reag FChamp; // Lecture Seule 
end;

Pour ma part, je trouve que mettre toujours tout en property est plus propre pour d'éventuelle modifcation que des vulgaires variables mises en public, ce que je ne fais JAMAIS, je préfère écrire ma petite property Champ et FChamp même si c'est verbeux !

[peter27x]

Pour avoir fait du Java, cela ne met choque pas,

Code :

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

1
2
3
4
5
6
7
8
private
  FChamp: string;
protected
  function Getchamp: String;
  procedure SetChamp(Value: string);
public
  property Champ: string reag GetChamp write SetChamp;
end;

Mais non ! je ne mets pas de property !

[Franck SORIANO]

En fait l'intérêt de la property, c'est que ce n'est pas une variable !

C'est exactement la même chose que les Getter/Setter explicites en Java, sauf que le compilateur les génèrent automatiquement pour toi lorsque leur implémentation est triviale.
Personnellement, je trouve que les propriétés sont quand même plus lisibles que des tartines de getter et setter. Même si parfois, on tombe sur du code où on lit une porpriété, on croit que ce n'est qu'une bête lecture, mais en réalité il y a une usine à gaz qui s'exécute derrière...

Après, dans Delphi il y a des raisons techniques qui ont nécessité la mise en oeuvre des propriétés (sans propriété tu configures quoi dans l'inspecteur d'objet ? C'est une nécessité pour le RAD).

La notion de property n'est pas propre à Delphi. Tu l'as retrouve déjà dans les objets COM, donc pour les composants ActiveX et finalement les composants visuels de VB.

Microsoft l'a ajouté dans .NET avec C# et VB.NET.
Dans VS 2008, M$ est même allé encore plus loin dans les déclarations implicites. Tu peux déclarer une propriété en disans que tu veux qu'elle soit en Lecture/ecriture, et le compilo génèrera automatiquement le getter, le setter... et la variable privée associée... (qui n'apparait donc jamais dans les sources)

[ShaiLeTroll]

Mais non ! je ne mets pas de property !

Ah, tu utilise en directement le GetChamp et SetChamp !!! Ah oki, effectivement c'est moche, la property est là pour simplifier cela !

[peter27x]

Ah, tu utilise en directement le GetChamp et SetChamp !!! Ah oki, effectivement c'est moche, la property est là pour simplifier cela !

En quoi elle le simplifie, je comprends pas ?

Je viens de voir un bout de code avec une property, en gros ça donne:

Code :

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

1
2
3
4
5
6
7
8
 
private:
i:integer;
procedure setI(val:integer);
function getI:integer;
 
public:
property prop_i:integer read getI write setI;

Je vois pas trop en quoi c'est moins moche et plus simplifié que ça:

Code :

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

1
2
3
4
5
6
7
 
private:
i:integer;
 
public:
procedure setI(val:integer);
function getI:integer;

EDIT : tu veux peut être dire que c'est plus moche à l'utilisation ? (=> utiliser la property plutôt que les get/set).

[anapurna]

salut

a utilisation tu utilise la property presque comme une variable
and ton cas tu pourra ecrire

Code :

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

1
2
3
4
 
MonObj.prop_i := x;
ou 
x := MonObj.prop_i

selon le cas qui t'interesse

[peter27x]

salut

a utilisation tu utilise la property presque comme une variable
and ton cas tu pourra ecrire

Code :

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

1
2
3
4
 
MonObj.prop_i := x;
ou 
x := MonObj.prop_i

selon le cas qui t'interesse

Effectivement, c'est un peu plus simple à ce niveau d'écriture là.

[anapurna]

salut

je ne te parle même pas des property indexer

Code :

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

1
2
3
4
5
6
Property datas[index : integer] : integer read GetDatas write setDatas ;
 
Utilisation 
   x :=  MonObjet.datas[i]
 
   MonObjet.datas[i] :=  x;

[ShaiLeTroll]

Bien vu Anapurna, je dirais qu'avec Cells d'un TStringGrid c'est encore plus impressionnant

Code :

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

1
2
Cells[Col, Row] := Value;
Value := Cells[Col, Row];

contre

Code :

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

1
2
SetCells(Col, Row, Value);
Value := GetCells(Col, Row);

Cela n'est pas montreux mais avec Delphi on y prend vraiement gout !
Surtout pour le Set qui ressemble où l'on voit bien l'affectation par rapport à l'appel de méthode ...

[Aka Guymelef]

Et parmi les trucs cools avec les propriétés on peut aussi citer la directive index qui permet de pouvoir réutiliser une même méthode de GET-SET pour plusieurs propriétés tout en sachant quelle propriété est demandé.

Exemple provenant de l'aide :

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
type
  TRectangle = class
  private
    FCoordonnees: array[0..3] of Longint;
    function LitCoordonnees(Indice: Integer): Longint;
    procedure EcritCoordonnees(Indice: Integer; Valeur: Longint);
  public
    property Gauche: Longint index 0 read LitCoordonnees write EcritCoordonnees;
    property Haut: Longint index 1 read LitCoordonnees write EcritCoordonnees;
 
    property Droite: Longint index 2 read LitCoordonnees write EcritCoordonnees;
    property Bas: Longint index 3 read LitCoordonnees write EcritCoordonnees;
    property Coordonnees [Indice: Integer] : Longint read LitCoordonnees write EcritCoordonnees;
    ...
  end;

Bon évidemment il faut trouver un cas d'utilisation où c'est vraiment utile, généralement c'est surtout un travail de factorisation pour éviter d'avoir une démultiplication de méthode qui font toutes la même chose à indice près par exemple.
N'empêche je trouves ça sympa

[peter27x]

Et parmi les trucs cools avec les propriétés on peut aussi citer la directive index qui permet de pouvoir réutiliser une même méthode de GET-SET pour plusieurs propriétés tout en sachant quelle propriété est demandé.

Exemple provenant de l'aide :

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
type
  TRectangle = class
  private
    FCoordonnees: array[0..3] of Longint;
    function LitCoordonnees(Indice: Integer): Longint;
    procedure EcritCoordonnees(Indice: Integer; Valeur: Longint);
  public
    property Gauche: Longint index 0 read LitCoordonnees write EcritCoordonnees;
    property Haut: Longint index 1 read LitCoordonnees write EcritCoordonnees;
 
    property Droite: Longint index 2 read LitCoordonnees write EcritCoordonnees;
    property Bas: Longint index 3 read LitCoordonnees write EcritCoordonnees;
    property Coordonnees [Indice: Integer] : Longint read LitCoordonnees write EcritCoordonnees;
    ...
  end;

Bon évidemment il faut trouver un cas d'utilisation où c'est vraiment utile, généralement c'est surtout un travail de factorisation pour éviter d'avoir une démultiplication de méthode qui font toutes la même chose à indice près par exemple.
N'empêche je trouves ça sympa

Mais dites donc, ça devient de plus en plus ludique ce property !

[gb_68]

Bonjour,
un autre aspect que j'apprécie personnellement avec les property, c'est l'aspect uniforme que cela donne au code pour l'accès à une variable ou des getter/setter.

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
TObj = class(TObject)
public
   A : Integer;
end;
 
TObj = class(TObject)
{strict} private
  FA : Integer; 
public
   property A : Integer read FA write FA;
end;
 
TObj = class(TObject)
{strict} private
  {FA : Integer; selon l'implémentation de GetA/SetA}
  function GetA : Integer;
  procedure SetA( AValue : Integer);
public
   property A : Integer read GetA write SetA;
end;

Quelle que soit la version choisie, le code utilisant cette classe accèdera au champ A de la même manière.

Code :

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

1
2
3
var Obj : TObj;
{...}
 Obj.A := Obj.A + ...

Ce qui permet un refactoring très facile. Du peu de Java que j'ai fait, je me souviens d'une fois où j'ai du changer une variable public en une privée accompagnée de getter/setter, ... avec tous les appels à modifier . Faisant toujours du C++ (ou le même cas peut apparaître), je privilégie donc (en C++) l'accès systématique par getter/setter mais cela fait débats (souvent interminables - voir internet ) et après c'est une question de goût

Code :

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

1
2
3
Obj1.SetA( Obj2.GetA() + Obj3.GetA() );
//contre
Obj1.A := Obj2.A + Obj3.A;

De même avec un champ en lecture seul, rapide à écrire avec les propriétés.

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
TObj = class(TObject)
{strict} private
  FA : Integer; 
public
   property A : Integer read FA;
end;
 
TObj = class(TObject)
{strict} private
  {FA : Integer; selon l'implémentation de GetA}
  function GetA : Integer;
public
   property A : Integer read GetA;
end;
 
// et même
TObj = class(TObject)
{strict} private
  {FA : Integer; selon l'implémentation de A}
public
   function A : Integer;
end;

avec comme code "utilisateur"

Code :

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

 Val := Obj.A;

dans tous les cas.

Remarque :

Code :

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

1
2
3
4
5
6
TObj = class(TObject)
{strict} private
  FA : Integer; 
public
   property A : Integer read FA write FA;
end;

modifie quand même un peu l'accès à la variable FA par rapport à un membre public ; en tant que propriété, on ne peut plus la passer par référence à un procédure (var), ni prendre son adresse.