IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi les propriétés sont importantes
En C#, article de Jon Skeet, traduit par Thomas Levesque

Le , par tomlev
8 commentaires

89PARTAGES

2  0 
Cette discussion est destinée à recueillir vos commentaires sur l'article Pourquoi les propriétés sont importantes (traduction de l'article Why Properties Matter de Jon Skeet)

Dans le chapitre 8 (NdT : du livre C# in Depth), je suppose sans trop me poser de questions que les lecteurs considèrent comme une bonne pratique l'utilisation de propriétés plutôt que de champs. Eric m'a suggéré de mentionner pourquoi c'est une bonne pratique. Je trouvais que ça ne rentrait pas vraiment dans le chapitre, mais c'est un sujet qui revient souvent dans les groupes de discussions et listes de diffusions, donc je me suis dit que je pourrais en faire un article.
Vous avez lu gratuitement 22 909 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

8 commentaires
Commenter Signaler un problème
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 19/03/2012 à 9:49
Citation Envoyé par Bobby McGee Voir le message
Ce que je comprends moins, c'est ce qui a poussé les créateurs du C# à inventer le concept de propriété plutôt que d'utiliser de simples méthodes get/set comme accesseurs. Est-ce uniquement pour pouvoir utiliser une syntaxe monObjet.MaPropriete = uneValeur ?
A moins de poser la question directement à Anders Hejlsberg, on ne peut faire que des suppositions... Je pense que c'est tout simplement parce que c'est plus "naturel" à utiliser que des méthodes. Ça permet aussi de mieux formaliser le lien entre les accesseurs get et set, pour bien montrer que la propriété est une entité à part entière et non seulement une paire de méthode.
2  0 
Bobby McGee
Avatar de Bobby McGee
Membre à l'essai https://www.developpez.com
Le 19/03/2012 à 9:37
Bonjour,

Merci pour cette traduction intéressante. Favoriser l'utilisation de propriétés plutôt que d'exposer les champs paraît assez logique.

Ce que je comprends moins, c'est ce qui a poussé les créateurs du C# à inventer le concept de propriété plutôt que d'utiliser de simples méthodes get/set comme accesseurs. Est-ce uniquement pour pouvoir utiliser une syntaxe monObjet.MaPropriete = uneValeur ?

Si quelqu'un pouvait méclairer sur ce point... Merci d'avance.
0  0 
BenoitM
Avatar de BenoitM
Expert confirmé https://www.developpez.com
Le 19/03/2012 à 10:05
j'aurai dit que le champ peut-être aussi protected si la propriété est en lecture seule
0  0 
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 19/03/2012 à 10:21
Citation Envoyé par BenoitM Voir le message
j'aurai dit que le champ peut-être aussi protected si la propriété est en lecture seule
Ce n'est pas une très bonne idée à mon avis... Si tu veux permettre aux classes dérivées de modifier la valeur, il vaut mieux mettre l'accesseur set en protected. Comme ça, tu peux détecter/valider la modification (ce qui n'est pas possible avec un champ)
0  0 
BenoitM
Avatar de BenoitM
Expert confirmé https://www.developpez.com
Le 19/03/2012 à 13:07
J'ai un peu honte, je ne savais pas qu'on pouvait mettre des acces different pour le getter et setter
0  0 
Bluedeep
Avatar de Bluedeep
Inactif https://www.developpez.com
Le 19/03/2012 à 15:36
Citation Envoyé par BenoitM Voir le message
J'ai un peu honte, je ne savais pas qu'on pouvait mettre des acces different pour le getter et setter
Il faut reconnaitre, à ta décharge, que la syntaxe "de base" (même niveau d'accès pour le getter et le setter) n'y invite pas, car dans ce cas le modificateur d'accessibilité ne se met pas au même endroit.

Le modificateur doit toujours être plus contraignant que le "principal".

Exemples :

Exemple :

Code : Sélectionner tout 
1
2
3
4
5
        public int MyProp
        {
            protected set;
            get;
        }
est valide.

Mais :

Code : Sélectionner tout 
1
2
3
4
5
      protected int MyProp
        {
            set;
            public get;
        }
ne compile pas.
0  0 
Noze_
Avatar de Noze_
Futur Membre du Club https://www.developpez.com
Le 11/04/2012 à 9:23
Donc d'après ce que vous indiquez, la méthode en tant que telle est accessible partout, mais la modification de valeur n'est possible que dans la classe.

Il est vrai que la syntaxe n'est pas habituelle. Elle n'en est pas moins très utile, merci du tuyau
0  0 
Bluedeep
Avatar de Bluedeep
Inactif https://www.developpez.com
Le 11/04/2012 à 10:07
Citation Envoyé par Noze_ Voir le message
Donc d'après ce que vous indiquez, la méthode en tant que telle est accessible partout, mais la modification de valeur n'est possible que dans la classe.
Il ne s'agit pas de méthodes mais de propriétés : donc la propriété est visible partout ("public" mais la valeur ne peut être affecté que par les classes héritées (protected).

Bien sur, on pourrait aussi mettre "private" (limité à la classe) mais ce n'est pas très utile, sauf à avoir un traitement déclenché à l'affectation (raising d'event par exemple) ou un controle de valeur (fréquent en public ou protected, plus rare en "private" ou "internal" puisque on a la main sur le code qui affecte la valeur).

On peut aussi utiliser les modificateurs "internal" (modification limitée à l'assembly) ou "internal protected" (attention "internal protected" s'interprête "internal OR protected", donc moins contraignant que "internal" ou "protected".
0  0 
Commenter Signaler un problème