3

Well I am learning properties and I am not sure about the following:

class X
{
  private int y;

  public X(int number)
  {
    this.Y=number; // assign to property
    OR
   this.y=number //?
  }

  public int Y;
  {
    get; set;  
  }

}
user
  • 6,897
  • 8
  • 43
  • 79
Mocco
  • 1,183
  • 2
  • 12
  • 25
  • 1
    possible duplicate of [Method Calling Public/Private Members or Methods Best Practice - C#.NET](http://stackoverflow.com/questions/2911945/method-calling-public-private-members-or-methods-best-practice-c-net) – Fredrik Mörk Feb 25 '11 at 10:39
  • Your code is buggy. private int y has nothing to do with public int Y. And this is a best practice question, so have a look at the link suggested by @Fredrik Mörk. – Tedd Hansen Feb 25 '11 at 10:56

7 Answers7

1

When you use auto-properties (get; set; or a variant thereof), the backing variable is not accessible. Those can, for the most part, be treated as simple variables, especially internally.

If you need to perform custom validation or mutation logic in the mutator, or otherwise have the need for an explicit backing variable, you cannot use auto-properties but have to write stub get and set methods yourself.

user
  • 6,897
  • 8
  • 43
  • 79
  • So what is the advantage of using them when I do not want to expose the "backing" variable? I canno access it now – Mocco Feb 25 '11 at 10:39
  • The advantage of auto-properties is that when you don't need to perform any property logic (particularly the case in the mutator), you save a fair bit of boilerplate code. – user Feb 25 '11 at 10:41
  • @Cocodrilo you can - via `Y`, which should be inlined automatically in most cases. – Marc Gravell Feb 25 '11 at 10:42
  • @Marc Gravell: well but any other class can change value of Y so its like public field – Mocco Feb 25 '11 at 10:50
  • @Cocodrilo it can be {get;private set;} if you want it readonly on th epublic API – Marc Gravell Feb 25 '11 at 11:03
1

They do different things; I would do Y = number; and remove the (unused) field y. In an automatically implemented property, the compiler creates it's own field (with a horrible name that you can't see in C#) - you don't need to provide your own field. So:

class X
{
  public X(int y)
  {
    Y = y;
  }
  public int Y { get; set; }    
}

Other points: changed number to y to be clearer to the caller, and also you don't need this. since it isn't ambiguous (field vs parameter, etc).

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
1

Only assign to a field (private int y) inside the property representing that field (public int Y {get;set}). No where else in the class should the backing field be assigned to directly. Always do it through the property... yes even in the constructor. It follows from the do not repeat yourself (DRY) principle.

This is recommended because whenever in future you want to associate some behavior to be triggered by that assignment you only have a single place (the set accessor) to write code into.... not all the places where the field is assigned to !!

   class X   
   {   
    private int y; //not strictly necessary but good for documentation

    public X(int number)
    {
        Y = number;
    }

    public int Y { get; set; }


    }
explorer
  • 11,710
  • 5
  • 32
  • 39
0

When you use autoproperties like:

  public int Y;
  {
    get; set;  
  }

You don"t need a private property because it's autogenerated. so you class will be:

class X
{   
  public X(int number)
  {
    Y = number;
  }

  public int Y // no semicolon here, comment added for edit length
  {
    get; set;  
  }
}

Hope this helps

user
  • 6,897
  • 8
  • 43
  • 79
alexl
  • 6,841
  • 3
  • 24
  • 29
0

You have two choices :

class X
{
    private int y;

    public int Y
    {
        get { return y; }
        set { y = value; }
    }

    public X(int number)
    {
        Y = number;
        //equivalent to 
        y = number;
        // but you should use the public property setter instead of the private field
    }
}

or with auto-properties , it's even simpler :

class X
{
    private int y;

    public int Y
    {
        get; set;
    }

    public X(int number)
    {
        Y = number;
    }
}
oleveau
  • 200
  • 1
  • 13
0

When not using auto-properties I always use the Property setter because there can or will be code in the setter that I need to be executed. This code could be a domain check or the raising of an event such as PropertyChanged.

Emond
  • 50,210
  • 11
  • 84
  • 115
0

A point I usually try to make about accessing backing variables:

Sometimes the public getter might contain complicated data validation,raising property changed events or some other complex code that is triggered when some external code changes it's value.

When changing that value internally (from inside the class), it might be a valid point to use the backing variable directly if your intention is to skip all the validation and events from the public setter. It's like saying "i'm the class instance, I know what I'm doing". This way the public setter is acting like a guard-dog, sanitizing external input, while I can still set the property internally to whatever I need.

class X   
   {   
     private int y; //not strictly necessary but good for documentation

    public X(int number)
    {
        y = GetYValueFromDB();  //we assume the value from DB is already valid

    }

    public int Y { 
       get{ return y}; 
       set { 
       if (ComplexValidation(value)
         {
           RaiseOnYPropertyChanged();
           y = value;
         }
        }


    }
Radu094
  • 28,068
  • 16
  • 63
  • 80