quand et pourquoi utiliser C# méthodes accesseurs

Question

Possible en double:
C# - When to use properties instead of functions

Je suis en train de comprendre quand et pourquoi utiliser "getter" et "faiseurs"

quelqu'un s'il vous plaît fournir des conseils.

Quelle est la différence entre les constructions suivantes - veuillez regarder en termes de méthodes d'accès uniquement.

//EXAMPLE 1: simple accessor method 
private static bool _isInitialEditMapPageLoad; 
public static bool isInitialEditMapPageLoad 
{ 
    get {return _isInitialEditMapPageLoad;} 
    set {_isInitialEditMapPageLoad = value;} 
} 

//EXAMPLE 2: accessor method with a conditional test 
private static bool _isInitialEditMapPageLoad; 
public static bool isInitialEditMapPageLoad 
{ 
    get 
    { 
     if (currentSession[isAuthorizedUseder] == null) 
      return false; 
     else 
      return _isInitialEditMapPageLoad;  
    } 
    set {isInitialEditMapPageLoad = value;} 
} 


//EXAMPLE 3: just a get accessor method - is this the same as EXAMPLE 4? 
private static bool _isInitialEditMapPageLoad = false; 
public static bool isInitialEditMapPageLoad 
{ 
    get {return _isInitialEditMapPageLoad;} 
} 


//EXAMPLE 4: simple method 
private static bool _isInitialEditMapPageLoad = false; 
public static bool isInitialEditMapPageLoad 
{ 
    return _isInitialEditMapPageLoad;  
} 

Answer 1

1: Ceci est une propriété simple, et peut être utilisé de la même manière qu'un champ public. Si vous avez une raison d'exposer les opérations get et set à d'autres utilisateurs (c'est-à-dire, d'autres classes) et que vous n'avez besoin de rien d'extraordinaire, c'est tout. Cela peut aussi être écrit avec « auto-propriétés »,

public static bool isInitialEditMapPageLoad {get;set;} // behaves just like example 1 

accessoires automobiles sont beaucoup plus rapides à écrire et à mon avis, sont beaucoup plus lisible que la déclaration complète (si je vois une déclaration complète avec un champ de support, Je m'attends à trouver de la complexité). 2: Ceci montre l'une des raisons des propriétés: utiliser une logique pour retourner une valeur plutôt que de toujours retourner une valeur directement. Quelqu'un peut définir cette valeur comme ils le feraient un champ public quand ils le veulent. Ils peuvent obtenir la valeur quand ils veulent, avec l'avertissement que false signifie que ce n'est pas la charge initiale OU que l'utilisateur n'est pas autorisé - c'est-à-dire qu'une certaine (simple) logique est effectuée avant de renvoyer une valeur. 3: Ceci se comporte comme un champ public UNIQUEMENT pour la lecture - quelqu'un peut récupérer la valeur, mais ne pas la définir. Ceci est essentiellement une valeur qui est en lecture seulement pour le code externe (à ne pas confondre avec le mot-clé readonly)

4: Résultat dans une erreur de compilation pour moi. En supposant que ce soit supposé être une déclaration de méthode, définir manuellement un getter comme on le ferait en Java, alors il est similaire à l'exemple 3.Je crois qu'il y a d'autres problèmes qui font que ce n'est pas tout à fait la même chose, comme si vous vouliez transformer cela en une propriété de dépendance, etc. Malheureusement, mes connaissances dans ce domaine sont insuffisantes.

==========

En règle générale, les propriétés de l'utilisateur pour limiter l'accès à vos données de classe. En principe, tout ce que vous pouvez empêcher d'autoriser un autre code à toucher devrait être conservé de cette façon. En pratique, vous voudrez pouvoir définir des valeurs sur les classes pour changer leur affichage, modifier les données représentées, et cetera. Utilisez les propriétés pour maintenir un contrôle maximal de cette interaction.

Si d'autres classes doivent afficher quelque chose dans votre classe, vous devrez exposer un getter, mais pas un setter. Cela n'est pas possible avec les champs, sauf si vous utilisez la méthode Java d'écriture d'une méthode getter personnalisée. Ils vous permettent également d'effectuer des calculs ou des validations avant de retourner ou de définir des données. Par exemple, si vous avez une valeur entière qui doit se situer dans une certaine plage (une plage qui peut changer en fonction de l'état de votre objet, même), vous pouvez vérifier dans setter que cette condition est remplie avant de mettre à jour votre valeur . Essayez d'éviter le piège consistant simplement à tout paramétrer comme un autoprop - ce n'est pas différent que de tout faire un domaine public. Gardez tout aussi privé que possible. Pas de getters sauf si nécessaire, pas de setters sauf si nécessaire, et les setters doivent effectuer toute petite logique nécessaire pour vérifier l'entrée avant de l'accepter, le cas échéant. Cela dit, évitez l'autre piège: mettre beaucoup de code dans les getters/setters. Si cela prend plus d'une poignée de lignes, vous devriez probablement faire une méthode plutôt qu'une propriété, simplement parce qu'elle donne un meilleur indice aux autres en utilisant votre code que quelque chose de grand va arriver.

Answer 2

Vos getters/setters devraient être votre interface publique avec votre classe.

En règle générale, devrait être privé tous vos membres, sauf pour ce que vous voulez que les gens d'avoir accès à l'extérieur de votre classe et vous ne voulez que vos variables privées soient directement accessibles à l'extérieur si votre classe

Voici un exemple simple. disons que vous aviez une classe pour laquelle vous aviez besoin d'une variable age. Dans ce cas, vous pouvez effectuer une validation directement dans le setter sans que vos classes externes aient besoin de savoir que la valeur est validée.

class Person { 
    int age = 0; 

    public int Age { 
    get { return age; } 
    set { 
     //do validation 
     if (valid) { 
     age = value; 
     } 
     //Error conditions if you want them. 
    } 
    } 

    //More getters/setters 
} 

Answer 3

Le raisonnement derrière Getters/Setters est de protéger la classe d'être brisée lorsqu'un utilisateur modifie un champ d'une manière non valide, et ils vous permettent de changer la mise en œuvre de votre classe tout en laissant les propriétés exposées publiquement inchangées .

Sauf si vous avez besoin d'une sorte de validation ou de propriétés de chargement paresseux, vous pouvez généralement utiliser les propriétés auto.

public string Name { get; set; } 

Answer 4

Comme d'autres mentionnés, utilisez des accesseurs/setters lorsque vous souhaitez que les membres de l'objet soient disponibles pour d'autres objets. De plus, la lisibilité du code yoru pourrait être améliorée (si vous êtes sur .NET 2.0 ou supérieur) en utilisant des autoproperties. Les exemples que vous avez serait alors comme ceci:

// example 1 
public static bool IsInitialEditMapPageLoad { get; set; } 

// example 3/4 - note that false is the default for bools 
public static bool IsInitialEditMapPageLoad { get; private set; } 

Exemple 3 aurait probablement rester le même, en raison de la logique de validation d'être là.