Property ou Function ?

Hello,

j'utilise un certain nombre de classes qui ont des propriétés (Readonly) de portée Public.

Je me pose la question de savoir si
- les Property d'une classe sont générées dès la création d'une instance ou pas ?
- l'utilisation de Function au lieu de ReadOnly Property est une optimisation du code ou pas ?

Merci d'avance :)

Salut,

Les propriétés sont des encapsulations de champs privés avec deux méthodes Get_NomPropriété et Set_NomPropriété.

C'est généré lors de la compilation.


Bref, cela ne sert à rien de se battre dessus jp.

Peut-être la lecture de cet article te permettra d'en apprendre un peu plus sur l'utilité des propriétés. Bonne lecture :ccool:

Citation:

---

Envoyé par jpcheck

- les Property d'une classe sont générées dès la création d'une instance ou pas ?

---

Ca n'a pas vraiment de sens... une propriété est juste une paire de méthodes (voire une seule méthode pour une propriété ReadOnly), elle est générée à la compilation. Le fait de créer une instance ne "génère" pas de propriété.

Citation:

---

Envoyé par jpcheck

- l'utilisation de Function au lieu de ReadOnly Property est une optimisation du code ou pas ?

---

Non, ça ne change rien en termes de performances. Un appel à une propriété est un appel de méthodes. D'ailleurs si tu regardes le code IL généré, tu verras que quand tu récupères la valeur d'une propriété Toto, ça appelle en fait une méthode (cachée) get_Toto.

D'une manière générale, choisis une propriété si la récupération de la valeur est peu couteuse et n'a pas d'effet de bord. Si la valeur doit être calculée par un traitement complexe, il vaut mieux utiliser une fonction.

OK,

et donc dans le cas où le retour est une list de classes, mieux vaut faire appel à une fonction donc ?

Merci pour la lecture (mermich :coucou:)

Citation:

---

Envoyé par jpcheck

et donc dans le cas où le retour est une list de classes, mieux vaut faire appel à une fonction donc ?

---

"Ca dépend" :aie:

De manière générale, je considère qu'il y un cas où le choix doit faire pencher la balance de manière absolue : une propriété doit être idempotente en lecture; dit autrement, la lecture n fois de ta propriété ne doit pas changer l'état du système.

Si c'est le cas, il est aberrant d'un point de vue conceptuel d'utiliser une propriété. (même si techniquement rien ne s'y oppose).

Pour le coup j'ai l'exemple ou le getter d'une propriété faisait de nombreux accès à la base de données...

Dans ton cas je ferai une méthode à part plutôt qu'une liste car tu semble faire du traitement lors de la construction de la liste.

De plus, on a vite fait d'essayer de modifier une liste directement avec des .add, même si la propriété est en readonly:


Imaginons:

Code:

---

1 2 3 4 5 6 7 8

public List<int> Plop { get { return new List<int>(); } }

---

Même si la propriété est en readonly (il n'y a pas de setter) tu pourra faire:

Code:

---

1 2	MonInstance.Plop.Add(3);

---

Et je peux te garantir que lorsque le voisin verra ce code pour la première fois il comprendra pas/rigolera/fera les gros yeux.

@mermich,
C'est cool ton exemple. Sauf que le hic (un peu hors sujet :aie:) est que ta propriété Plop renverra toujours une liste avec zéro élément quoi.
Il faut faire comme ça :ccool: :

Code:

---

1 2 3 4 5 6 7 8 9 10

private List<int> list = null; public List<int> Plop { get { if(this.list == null) this.list = new List<int>(); return list; } }

---

Citation:

---

Envoyé par mermich

De plus, on a vite fait d'essayer de modifier une liste directement avec des .add, même si la propriété est en readonly:
.

---

La logique dans ce cas veut qu'on expose des ReadOnlyCollection (méthode "AsReadOnly"), ou éventuellement des listes en readonly (obtenue par héritage de List<T> et overwrite des méthodes "Add" pour lever une exception).

Citation:

---

Envoyé par Bluedeep

ou éventuellement des listes en readonly (obtenue par héritage de List<T> et overwrite des méthodes "Add" pour lever une exception).

---

Sauf que les méthodes de List<T> ne sont pas virtuelles ;)
Mais de toutes façons ReadOnlyCollection<T> fait déjà à peu près ça : elle implémente IList<T> mais les méthodes qui modifient la liste déclenchent une exception.

Citation:

---

Envoyé par tomlev

Sauf que les méthodes de List<T> ne sont pas virtuelles ;)

---

Damned .... :aie: