Quand une classe devrait-elle utiliser ses propres getters/setters plutôt que d'accéder directement aux membres?

Question

Lors de la génération de setters et de getters dans Eclipse, l'une des options consiste à utiliser les getters et les setters dans la classe plutôt que d'accéder directement aux membres de la classe. Ce niveau d'encapsulation interne de classe est-il utile ou est-ce que cela prend une bonne idée d'aller un peu trop loin?

DUPE: Should you use accessor properties from within the class, or just from outside of the class?

Answer 1

Je pense qu'il est une bonne idée si vous voulez que les effets secondaires potentiels de se produire - la validation, l'exploitation forestière, etc. (en C# Je voudrais pouvoir déclarer une variable et la propriété et dire que le ne accès à la variable est par la propriété.)

de temps en temps vous pourriez bien vous trouver besoin de définir la variable directement précisément parce que vous ne faites pas veulent les effets secondaires. Par exemple, vous devrez peut-être définir deux variables ensemble, et les deux états "avant" et "après" sont valides, mais la définition de chaque propriété individuellement ferait sauter la validation.

Answer 2

Cela peut être utile si vous permettez aux classes dérivées de redéfinir vos getters. Donc, en utilisant des getters même à l'intérieur de la classe, votre design sera extensible. À mon avis, c'est quelque chose qui doit être défini dans les lignes directrices de codage.

Answer 3

Ceci est utile par exemple lorsque vous avez des setters qui effectuent des actions supplémentaires comme la définition d'un drapeau sale ou la notification d'observateurs.

Pour les getters, vous pouvez au lieu d'accéder à un champ calculer une valeur lorsque vous changez de représentation.

Answer 4

Je trouve que je le fais parfois - en particulier lorsque j'ai besoin, ou que je prévois fortement que je vais avoir besoin, d'une connexion pour obtenir ou définir (et la validation autour d'eux) des membres.

Je trouve que les propriétés privées/internes aident dans ces cas.

Mais je ne le fais certainement pas pour n'importe quel memeber.

Dernières .NET/VS aide vraiment ici que vous pouvez déclarer une propriété en tant que tel:

public string SomeProperty 
{ 
get; 
set; 
} 

et il crée effectivement la memebr derrière la scène. Je sais que cela ne vous aide pas, mais je pensais que cela pourrait être intéressant :-)

Answer 5

Si vous voulez que ce membre soit databindable par Winform ou WPF, je crois que vous devez le déclarer comme propriété. Je suis environ 95 pour cent positif que la liaison de données nécessite une propriété (getter/syntaxe de réglage). J'ai une petite solution wpf qui le démontre, mais je ne vois pas un moyen de l'attacher ici.

Voici le code: (construit avec VS 2008 SP1, ciblant .net 3.5 - J'ai utilisé un projet WPF). Le projet WPF contient deux éléments, la fenêtre principale (window1) et l'objet que nous testons (DataObject) Il existe une étiquette sur la fenêtre qui est databound à la propriété Name dans une instance d'objet de données. Si vous convertissez la propriété Name en champ (supprimez le getter/setter), la liaison de données cessera de fonctionner.

Fenêtre1.XAML:

<Window x:Class="WpfDatabinding.Window1" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Title="Window1" Height="300" Width="300"> 
<Grid> 
    <Label Name ="Label1" Height="28" Margin="12,24,37,0" VerticalAlignment="Top" Content="{Binding Name}"></Label> 
</Grid> 

Window1.xaml.cs

using System; 
using System.Windows; 

namespace WpfDatabinding 
{ 
    /// <summary> 
    /// Interaction logic for Window1.xaml 
    /// </summary> 
    public partial class Window1 : Window 
    { 
     private DataObject ADataObject; 

     public Window1() 
     { 
      InitializeComponent(); 
      this.ADataObject = new DataObject(); 
      this.ADataObject.Name = "Hello!"; 
      this.DataContext = this.ADataObject; 
     } 
    } 
} 

namespace WpfDatabinding 
{ 
    /// <summary> 
    /// Interaction logic for Window1.xaml 
    /// </summary> 
    public partial class Window1 : Window 
    { 
     private DataObject ADataObject; 

     public Window1() 
     { 
      InitializeComponent(); 
      this.ADataObject = new DataObject(); 
      this.ADataObject.Name = "Hello!"; 
      this.DataContext = this.ADataObject; 
     } 
    } 
} 

DataObject.cs:

namespace WpfDatabinding 
{ 
    public class DataObject 
    { 
     // convert this to a field, and databinding will stop working 
     public string Name 
     { 
      get; 
      set; 
     } 
    } 
} 

Answer 6

La réponse courte est "ça dépend" :)

Eric Lippert a un excellent article sur Automatic vs. Explicit properties qui traite de ce problème, quoique d'un angle légèrement différent.

Essentiellement, la question que vous devez poser est la suivante:

« à partir de la classe, [sont] la sémantique souhaitées d'accès à cette propriété ... différente de la sémantique souhaitées d'accès à la propriété de la à l'extérieur?"

Si la sémantique est la même, votre classe doit utiliser ses propres propriétés. Si la sémantique est différente, votre classe devra manipuler directement les champs de sauvegarde.

Answer 7

Lorsque vous devez étendre le comportement getter/setter d'une classe, il est utile d'avoir des champs encapsulés (getters/setters au lieu d'un accès direct aux membres). Pourtant, en héritage, il est conceptuellement intéressant de préserver les inners de votre classe, si ses sous-classes ne doivent pas être conscientes de son caractère privé. Ainsi, parfois le champ est privé à l'implémentation d'une classe, de sorte que même les sous-classes n'en sont pas conscientes.