94 votes

Meilleures pratiques pour les accesseurs, les setters et les propriétés. Java vs. C #

Je vais prendre une classe C#, et je suis en train de trouver la meilleure façon de faire les choses. Je viens d'une Java d'arrière-plan et donc je ne suis familier avec Java meilleures pratiques; je suis un C# débutant!

En Java, si j'ai une propriété privée, je le fais;

private String name;

public void setName(String name) {
   this.name = name;
}

public String getName() {
   return this.name;
}

En C#, je vois qu'il y a de nombreuses façons de le faire.

Je peux le faire comme Java:

private string name;

public void setName(string name) {
   this.name = name;
}

public string getName() {
   return this.name;
}

Ou je peux le faire de cette façon:

private string name;

public string Name {
   get { return name; }
   set { name = value; }
}

Ou:

public string Name { get; set; }

Qui dois-je utiliser, et quelles sont les mises en garde ou des subtilités de chaque approche? Lors de la création de classes, je suis en général les meilleures pratiques que je sais de Java (en particulier la lecture Efficace Java). Ainsi, par exemple, je suis en favorisant l'immutabilité (en fournissant des setters seulement quand c'est nécessaire). Je suis juste curieux de voir comment ces pratiques s'inscrivent dans les différentes façons de fournir les setters et getters en C#, pour l'essentiel, comment pourrais-je traduire les meilleures pratiques du monde Java en C#?

MODIFIER

J'ai été poster cela dans un commentaire de Jon Skeet réponse mais cela a longtemps:

Que penser d'un non-trivial de la propriété (c'est à dire, avec un traitement important et de validation peut-être)? Pourrais-je encore exposer via une propriété publique, mais avec la logique encapsulé en get et set? Pourquoi/je ferais ça plus le fait d'avoir un setter et getter méthodes (avec des associés de traitement et de validation de la logique).

89voto

Jon Skeet Points 692016

J'utilise la dernière de ces, pour une propriété triviale. Notez que j'appellerais cela un public à la propriété comme à la fois les getters et les setters sont publiques.

L'immuabilité est un peu de douleur avec des propriétés implémentées automatiquement - vous ne pouvez pas écrire une auto-propriété qui n'a qu'un getter; le plus proche, vous pouvez venir est:

public string Foo { get; private set; }

ce qui n'est pas vraiment immuable... juste immuable à l'extérieur de votre classe. Si vous souhaitez utiliser un véritable propriété en lecture seule à la place:

private readonly string foo;
public string Foo { get { return foo; } }

Vous ne voulez certainement pas à écrire getName() et setName(). Dans certains cas, il est logique d'écrire des méthodes Get/Set plutôt que d'utiliser les propriétés, en particulier si elles peuvent être coûteux, et vous souhaitez mettre en valeur. Cependant, vous voulez suivre les .NET convention de nommage de PascalCase pour les méthodes, et vous ne voudriez pas une propriété triviale de ce type à être mis en œuvre avec des méthodes normales de toute façon - une propriété est beaucoup plus idiomatiques ici.

17voto

jeremyalan Points 1775

Si vous avez besoin d'une variable pour stocker des données:

public string Name { get; set; }

Voulez qu'il soit immuable?

public string Name { get; private set; }

Envie de faire quelques vérifications de valeurs avant de l'affecter à la propriété?

public string Name 
{
   get { return m_name; }
   set
   {
      if (value == null)
         throw new ArgumentNullException("value");

      m_name = value;
   }
}

En général, la GetXyz() et SetXyz() ne sont utilisés que dans certains cas, et vous avez juste à utiliser votre instinct quand il se sent le droit. En général, je dirais que je m'attends à la plupart des get/set propriétés contiennent pas beaucoup de logique et n'ont que très peu, le cas échéant, des effets secondaires inattendus. Si la lecture de la valeur d'une propriété nécessite l'invocation d'un service ou d'obtenir les commentaires d'un utilisateur dans le but de construire l'objet que je me suis demander, alors je l'enveloppent dans une méthode, et de l'appeler quelque chose comme BuildXyz(), plutôt que d' GetXyz().

12voto

Ed S. Points 70246

Utilisez les propriétés en C #, pas les méthodes get / set. Ils sont là pour votre commodité et c’est idiomatique.

En ce qui concerne vos deux exemples C #, l’un est simplement un sucre syntaxique pour l’autre. Utilisez la propriété auto si tout ce dont vous avez besoin est un simple wrapper autour d'une variable d'instance, utilisez la version complète lorsque vous devez ajouter une logique dans le getter et / ou le setter.

5voto

Steven Jeuris Points 4850
public string Name { get; set; }

C'est tout simplement une auto-mise en œuvre de la propriété, et est techniquement le même comme une propriété classique. Un champ de stockage sera créé lors de la compilation.

Toutes les propriétés sont finalement convertis à des fonctions, de sorte que le réel compilé mise en œuvre à la fin est la même que vous êtes habitué à en Java.

Utiliser les propriétés implémentées automatiquement lorsque vous n'avez pas à faire des opérations spécifiques sur le champ de stockage. Utiliser une propriété normale autrement. Utiliser les fonctions get et set lorsque l'opération a des effets secondaires ou est gourmand en ressources, utiliser les propriétés autrement.

4voto

Paul Sasik Points 37766

Quelle que soit la méthode choisie en C #, le résultat final est identique. Vous obtiendrez une variable backinng avec des méthodes getter et setter distinctes. En utilisant les propriétés, vous suivez les meilleures pratiques et vous devez donc savoir comment vous voulez en parler.

Personnellement, je choisirais les propriétés automatiques, la dernière version: public string Name { get; set; } , car elles occupent le moins d’espace possible. Et vous pouvez toujours les développer ultérieurement si vous avez besoin d’ajouter quelque chose comme la validation.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X