0

This question may look silly for some but I want to understand the concept behind, I have a single property(i.e TestNumber) within a TestClass.

 public class TestClass
 {
    private uint testNumber=0;
    public uint TestNumber
    {
        get { return testNumber; }
        set { testNumber = value; }
    }

    public TestClass ()
    {
        TestNumber = 0;
        // or
        testNumber = 0;
    }
}

Now, if I want to set or get the value of the property outside the class, I can simply do the following,

TestClass tc = new TestClass ();
tc.TestNumber = 10;

but my question is if I want to access this property within the same class, I have two options either I can use

testNumber = 0;

or

TestNumber = 0;, so which one is correct & why?

Thanks!

SanVEE
  • 2,009
  • 5
  • 34
  • 55
  • 2
    Both are legit. But if you use property, then *setter* code will get executed. This question (or similar) was already [asked](http://stackoverflow.com/q/295104/1997232). – Sinatr Oct 07 '14 at 12:28

3 Answers3

2

Depends on what you want to do...

  • Do you want to directly set the variable?
  • Do you want to invoke the setter logic?

The current setter doesn't do anything special:

set { testNumber = value; }

But someday it might. And if the class has any significant amount of logic in it then that logic may need to be updated to use the setter instead of the variable when that time comes. Conversely, however, some of the logic internal to the class may explicitly not want to use the setter's logic and may want to continue to set the variable directly.

Encapsulation is funny like that, since anything within the class has the option to do both and different logic therein may be trying to achieve very different things.

As a matter of personal preference I often like to use naming conventions which hint at a variable being something I wouldn't want to set directly. The most common convention I've seen is to prefix with an underscore:

private uint _testNumber = 0;

By convention on the team we treat it as an indicator that this variable isn't meant to be set directly, so anything which does need to set it directly is explicitly and obviously doing so even just from a casual glance at the code. (It also helps with the intellisense, because if one is trying to set the "test number" then when one types that name the intellisense will default to the property, not the variable.)

David
  • 208,112
  • 36
  • 198
  • 279
1

Although both are valid the latter is better because you may use the setters/getters logic (if its more then simply return/set the value of the back-field). Thus you have one single point of access for your members rather then many possible ones.

MakePeaceGreatAgain
  • 35,491
  • 6
  • 60
  • 111
1

Almost 99% of the times you'd want to use the properties. Why?
Its simple, properties let you add logic behind the scene while your code continues to work just like before.
By using the property you save yourself the headache of missing out some parts while updating the others, propagating the logic everywhere you used the field in you class.
Have you ever wondered why automatic properties are introduced in c#?
One of the reasons is that it lets you use the property, expose it as you like, and continue on coding the rest of the application, and then if you need to put some logic into it, you can do it effectively without breaking existing code! this just feels like ordinary fields. you just write the property in the first place, and then do as you wish.

Have a look at here too.it might be of help.

Community
  • 1
  • 1
Hossein
  • 24,202
  • 35
  • 119
  • 224