Discussion :

[cosmoff]

bonjour,

voila j'ai parfois vu dans des codes, comme par exemple Qt, l'utilisation de property :

Code :

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

1
2
union type myValue = 6; // ou QVariant pour Qt
myObject.setProperty("myValue", myValue)

et pour récupérer la valeur :

Code :

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

int value = myObject.property("myValue");

j'ai meme parfois vue

Code :

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

myObject::setProperty(char*, void*)

avec un type générique qui permet de mettre ce que l'on veut et c'est à l'utilisateur de cast le type en fonction de la variable qu'il récupere.

Est-ce un design patern cette facon de faire? est ce mieux de faire des property ou des accesseurs ?

Merci d'avance pour vos éclaircissements

[LittleWhite]

Bonjour,

Il n'y a rien de particulier. La classe QObject définie deux fonctions property() et setProperty() permettant d'accéder et de définir des propriétés (qui seront, par exemple, stockées dans une table de hachage).
Le property peut être considéré comme un accesseur. Après, contrairement aux accesseurs définis à la main dans une classe, le système de propriétés de Qt, permet de faire quelque chose de dynamique où l'utilisateur pourra définir une propriété "toto" lorsqu'il le veut.

[Bktero]

Il ne pas perdre de vue qu'une telle table de correspondance n'est pas gratuite : il faut de la place pour stocker les clés et il faut comparer des chaines de caractères pour lire / écrire des valeurs. Le compilateur ne pourra faire que très peu d'optimisations sur tout ça.

A priori, ce n'est pas une bonne idée d'utiliser une telle mécanique pour remplacer get/set dans une classe comme :

Code :

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

1
2
3
4
5
6
struct Foo {
  int get() { return value_m; }
  void set(int v) { value_m = v; }
private:
  int value_m;
};

[koala01]

Salut,

Il ne pas perdre de vue qu'une telle table de correspondance n'est pas gratuite : il faut de la place pour stocker les clés et il faut comparer des chaines de caractères pour lire / écrire des valeurs. Le compilateur ne pourra faire que très peu d'optimisations sur tout ça.

A priori, ce n'est pas une bonne idée d'utiliser une telle mécanique pour remplacer get/set dans une classe comme :

Code :

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

1
2
3
4
5
6
struct Foo {
  int get() { return value_m; }
  void set(int v) { value_m = v; }
private:
  int value_m;
};

C'est d'autant plus vrai que, si un accesseur (getXXX) peut ** éventuellement ** s'avérer utile, un mutateur ( setXXX) fait perdre tous les avantages que l'on peut gagner avec une encapsulation correcte, étant donné qu'ils imposent à l'utilisateur de calculer eux-même la nouvelle valeur à assigner à la donnée.

En gros, si un accesseur s'avère utile / nécessaire, c'est sans doute que la donnée modifiée aurait très bien pu être placée dans l'accessibilité publique.

[jo_link_noir]

À savoir que les properties de Qt font plein de chose derrière pour être utilisés à travers le système de signals/slots ou exposées à l'extérieur pour les scripts (QtScript) ou DBus (un programme externe peut directement taper dessus en utilisant le protocole dbus ou via un programme qui l'implémente (ex: qdbus)).