none
setters privés RRS feed

  • Question

  • A quoi cela sert-t'il d'avoir dans une propriété un setter privé (j'ai lu ça dans un bouquin). Pour ma part, je pense que déjà comme la variable concernée est privée, toute modification se ferait à l'intérieur de la classe, tout comme son setter. Si je n'ai rien compris, pouvez-vous me donner un exemple de créer un setter privé ?

    Merci d'avance,
    Fred  
    dimanche 31 août 2008 11:41

Réponses

  •  

    Bonjour,

     

    L'intérêt peut semblé limité si le setter ne fait qu'affecter la valeur et rien d'autre, mais en se projetant dans le futur ça peut avoir son intérêt si des traitements doivent être effectué au changement de valeur.

    Certes le refactoring (réglé pour agir sur les références internes et non pas seulement les références externes) peut aider dans ces cas là en transformant assez rapidement les accès directs au champ par un accès à la propriété, mais ça agira sur toutes les références au champ.

    Partir dès le début sur un setter private permettra au moins déjà de ne faire les accès directs au champ que sur les opérations où l'affectation de valeur ne doit réellement pas être entravée par un autre traitement. Ces accès ne seront donc pas impactés par les modifications futures, sauf changement explicite par la personne qui effectue les modifications.

    Enfin, après c'est un point de vue, il doit y en avoir d'autre valables en faveur (ou en défaveur) de cette pratique.

     

    dimanche 31 août 2008 15:56
  • Bonjour,

     

    Je partage le même avis que Gaël, il faut juste noter que les propriétés sont considérées comme des méthodes et donc il y a tout un mécanisme d'appel qui mis en place. Cela a un coût supplémentaire contrairement à un accès direct à une variable membre.

    Dans le cas où votre variable membre est appelée très souvent, il est préférable de ne pas mettre de propriété. 

     

    Un petit article que j'ai écrit dessus :

    http://gilles.tourreau.fr/dotnet/dotnet_framework_en_general/dotnet_attention_aux_performances_dacces_a_une_propriete_dune_classe.html

     

    Cordialement

     

    lundi 1 septembre 2008 20:01
    Modérateur
  • Je crois que oui, mais tu peux mettre du code dans ton getter avant de retourner une valeur.

     

    mardi 2 septembre 2008 19:41
    Modérateur

Toutes les réponses

  •  

    Bonjour,

     

    L'intérêt peut semblé limité si le setter ne fait qu'affecter la valeur et rien d'autre, mais en se projetant dans le futur ça peut avoir son intérêt si des traitements doivent être effectué au changement de valeur.

    Certes le refactoring (réglé pour agir sur les références internes et non pas seulement les références externes) peut aider dans ces cas là en transformant assez rapidement les accès directs au champ par un accès à la propriété, mais ça agira sur toutes les références au champ.

    Partir dès le début sur un setter private permettra au moins déjà de ne faire les accès directs au champ que sur les opérations où l'affectation de valeur ne doit réellement pas être entravée par un autre traitement. Ces accès ne seront donc pas impactés par les modifications futures, sauf changement explicite par la personne qui effectue les modifications.

    Enfin, après c'est un point de vue, il doit y en avoir d'autre valables en faveur (ou en défaveur) de cette pratique.

     

    dimanche 31 août 2008 15:56
  • Bonjour,

     

    Je partage le même avis que Gaël, il faut juste noter que les propriétés sont considérées comme des méthodes et donc il y a tout un mécanisme d'appel qui mis en place. Cela a un coût supplémentaire contrairement à un accès direct à une variable membre.

    Dans le cas où votre variable membre est appelée très souvent, il est préférable de ne pas mettre de propriété. 

     

    Un petit article que j'ai écrit dessus :

    http://gilles.tourreau.fr/dotnet/dotnet_framework_en_general/dotnet_attention_aux_performances_dacces_a_une_propriete_dune_classe.html

     

    Cordialement

     

    lundi 1 septembre 2008 20:01
    Modérateur
  • Merci Mr Tourreau, votre article m'a beaucoup intéressé.
    En posant la question, je voulais bien comprendre l'intérêt des propriétés. De ce que j'ai compris, elles protègent bien les variables privées et permettent de ne pas trop écrire de soubroutines de validation et d'action.
    J'ai une autre question :
    Une propriété qui n'a qu'un getter, c'est pareil qu'une variable publique en readonly, non ?

    Merci d'avance,

    Fred
    mardi 2 septembre 2008 18:38
  • Je crois que oui, mais tu peux mettre du code dans ton getter avant de retourner une valeur.

     

    mardi 2 septembre 2008 19:41
    Modérateur
  • Après avoir écrit ma réponse, j'avais tout de suite pensé à cet avantage du getter, mais c'était trop tard...
    Merci quand même pour ta réponse.

    Fred
    mercredi 3 septembre 2008 10:23
  • Bonjour,

     

    Je n'ai pas pas de certiture sur le sujet, mais je trouverais étonnant que les propriétés ne faisant qu'un accès direct à un champ ne soient pas inlinées à la compilation JIT (si l'assembly est produit avec un build autorisant les optimisations de code, comme le build Release de base par exemple).

     

    samedi 6 septembre 2008 14:41