Pourquoi dois-je utiliser get et set?

J'ai un segment de code:

public class MyClass
{
    private string _myProperty;

    public string MyProperty
    {
        get
        {
            return _myProperty;
        }

        set
        {
            _myProperty = value;
        }
    }
}

Quel est le point ici? Je pourrais avoir déclaré la _myProperty chaîne publique et aucun de mes objets de classe serez en mesure d'accéder directement et d'obtenir ou de définir la valeur.

Au lieu de cela, nous faisons _myProperty privé et l'utilisation de get et set pour accéder, à l'aide de la classe de l'objet.

Dans les deux cas, l'objet de classe est en mesure d'y accéder et le résultat est toujours le même.

Alors pourquoi utiliser cette approche? C'est que seulement parce que je peux mettre en œuvre quelques contraintes dans setter?

À part ça quoi de mal à faire des variables de membre de cause publique? Dans cet exemple, j'ai pu exposer _myProperty publique au lieu de le restreindre à cette classe qu'en privé, comme la programmation orientée objet ne le suggèrent.

source d'informationauteur Simsons

.net c#encapsulation oop

16

Non, le résultat n'est pas toujours le même.
- Essayer de liaison à un champ public (ou faire autre chose qui utilise la réflexion et attend de propriétés)
- Essayer de passer une propriété par référence (vous ne pouvez pas)
- Essayer plus tard de décider que vous voulez de journalisation etc et de trouver que lorsque vous la changez pour une propriété, vous perdez à la fois la source et la compatibilité binaire.
Lire la l'article que j'ai écrit sur ce il y a un moment...

Noter qu'en C# 2 votre code peut être un beaucoup plus courte:
```
public class MyClass
{
    public string MyProperty { get; set; }
}
```
1

Le domaine _myProperty est un détail d'implémentation—il dit au compilateur que vous voulez de stockage à une chaîne de référence et à lui donner ce nom. Les méthodes get/set font partie de la propriété de l'objet, qui résumés comment la MyProperty propriété est mise en œuvre. Donc, disons, si vous voulez changer la façon dont la chaîne est stockée/(extrait, 3e partie des personnes à charge n'ont pas à re-compiler.

Vous pouvez également utiliser automatique des propriétés de le faire pour vous:
```
public string MyProperty {get; set;}
```
1

Si vous venez de déclarer les variables en tant que Public , celles-ci ne sont pas réellement Properies. De nombreuses fonctionnalités qui utilisent la réflexion ne sera pas de travail, en particulier de la liaison de données Sérialisation et ainsi de suite.

Parfois je reçois des paresseux et cela, en particulier lorsque vous travaillez dans VB.Net pré v4 comme il n'y a pas d'auto propriétés, et toujours le regretter et revenir à écrire les propriétés correctement.

Il est particulièrement important d'utiliser les propriétés si votre classe est consommé par le code écrit par les développeurs d'autre que vous-même, comme ils peuvent très bien avoir des problèmes avec les limites imposées par pas de codage des propriétés complètes.
0

Comme vous l'avez dit la raison principale de propriétés est la validation. Chaque classe a cette responsabilité de garder leurs cadres sécuritaires et _myProperty est un membre de MyClass. L' .Net pour la mise en œuvre de cette responsabilité est propety. en Java, vous devez définir deux méthodes: SetMyPropety et GetMyProperty.
0

Il est important de noter que, même s'il est souvent utile pour les classes d'envelopper les champs, dans les propriétés, il est souvent contre-productif pour les structures à le faire. De nombreux qu'il est recommandé de limitations sur l'utilisation des structures de souches à partir d'une présomption que tous les struct champs seront enveloppés dans des propriétés. Si la sémantique d'une struct:
1. Son état est complètement défini par un nombre fixe de paramètres, qui sont exposées publiquement pour la lecture.
2. Ces paramètres peuvent être librement affectées toute combinaison de valeurs juridiques pour leurs types respectifs.
3. L'instance par défaut de la structure est indiquée comme ayant tous les paramètres initialisés avec les valeurs par défaut de leurs types.
puis exposer les champs exposer les "rouages" du type de données, mais une telle exposition ne serait pas obstacle à l'efficacité de toute modification future du type de données qui ne serait pas déjà être exclu par l'spec. Tous les champs de toutes les structures qui sont stockés dans des emplacements modifiables sont toujours exposés pour la mutation, même si le seul moyen de mutation est une copie en bloc de tous les publics et privés champs d'une instance à l'autre. Si la sémantique d'une struct exiger que du code soit en mesure de créer une instance dont les paramètres de définition de toute combinaison de valeurs, sans restriction, l'exposition d'une structure de champs directement ne permettent pas de single-threaded code pour faire ce qu'il ne pouvait pas faire plus lentement, sans un tel accès. Les seules choses que d'exposer les champs permettra de code pour faire ce qu'il ne serait pas capable de faire autrement:
1. l'exécution est plus rapide
2. exprimer plus clairement son intention
3. ont une sémantique définie dans le multi-threading les scénarios où la sémantique serait autrement glauque
Je ne vois pas vraiment beaucoup d'avantages pour exiger les consommateurs d'un type à l'exécution plus lente, être écrit maladroitement, et ont trouble le multi-threading sémantique.

Noter que si il y avait une politique contre le fait d'avoir des structures dont les propriétés muter "il", plutôt que d'une politique de l'encapsulation de tous les struct champs, puis une instruction comme:
```
myListOfPoint[4].X = 5;
```
seraient rejetées, même si la langue a permis accesseurs de propriété pour être appelé sur les structures (en partant de l'hypothèse que le but serait pour des choses comme
```
myArraySegment[3] = 9;
```
qui serait compris que l'accès à l'ensemble auquel myArraySegment contient une référence).

Vous devez vous connecter pour publier un commentaire.