Discussion :

[sandre]

Bonjour.
Je me pose une question existentielle, en C# (comme en d'autres langages d'ailleurs) sur les accesseurs Set/Get et les propriétés.

Lorsque, dans une classe, nous voulons protéger un membre, nous le définissons en private et déclarons un accesseur Get (ou une propriété n'ayant qu'un accès Get) pour récupérer sa valeur depuis une autre classe.

Ma question est la suivante :
je comprends tout à fait ce principe pour des variables de type valeur, car l'élément retourné via la méthode Get ne pourra en aucun cas affecter la variable private associée, quel que soit l'utilisation qui en est fait dans le code qui l'exploite.

Par contre pour des variables de type valeur j'ai beaucoup plus de mal à comprendre en quoi cela sécurise l'application. Je m'explique : dans une classe si je définie un membre privé, de type DataRow par exemple, puis un acesseur Get permettant de récupérer sa valeur, il suffit au code appellant d'appeller ce Get pour obtenir une référence sur ce Datarow et de faire un dispose dessus pour affecter également l'état du membre privé que le Get est censé protégé.

Qu'en pensez-vous ?

Je trouve que du coup l'utilisation de Get/Set ou la définition de propriétés pour des membres de types références n'apporte pas grand chose au niveau de la sécurisation du code.

Etes vous de mon avis ?

[shwin]

c'est pour cela que le keyword readonly existe!!

Si tu veux que ta propriété soit seulement en lecture il faut mettre readonly devant le get

[Sphax]

@shwin

Il me semble que le mot clée readonly ne s'applique qu'aux variables membres d'une classe, pas aux propriétés. De tte façon ça ne résoud pas le problème évoqué par sandre, une variable readonly ne peut pas être assignée, mais rien n'empêche d'accéder à ses méthodes qui elles même peuvent en modifier l'état.

@sandre: tu as partiellement raison, dans le cas d'une variable membre de type référence, l'exposer directement avec une propriété va à l'encontre de la notion d'encapsulation. Mais une propriété n'est pas obligée de renvoyer directement le membre correspondant (même s'il est conseillé que les traitements dans une proriété restent succincts). Ce qu'il faut faire dans ce cas ce n'est pas renvoyer directement la variable membre mais une copie explicite de celle-ci.

Concretement:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
private DataRow _MaRow;
 
public DataRow MaRow
{
   get
   {
      //ne pas faire : return _MaRow;
      //mais faire une copie explicite de _MaRow et la renvoyer
   }
}

Cela dit, vu que tu évoques ce problème, s'il y a qque chose que je regrette du C++ en .Net c'est le mot clée "const". Ce mot clée permet en C++ de résoudre élégemment ton problème sans avoir à faire de copie d'un objet, puisque ce mot clée garantie qu'aucune méthode modifiant l'état interne d'un objet ne pourra être appelée.

[sandre]

Merci pour vos réponse.

Je vois que je ne suis pas le seul à penser que des accesseurs sur un membre par référence est une sacrée faille.

La copie est effectivement une solution mais pas simple à mettre en oeuvre et elle va parfois à l'encontre de la logique par référence de C#.

Une des solutions serait de pouvoir filtrer les méthodes exposées d'un objet.

[SaumonAgile]

L'intérêt des accesseurs n'est pas uniquement de protéger les variables. Le principal avantage est de simplifier la syntaxe pour le créateur de la classe et pour son utilisateur.

[lutecefalco]

Faut faire une copie comme expliqué plus haut
C'est pas non plus qqchose de compliqué