81

Till now, I was under the impression that Properties & Methods are two different things in C#. But then I did something like below.

enter image description here

and this was an "Eye Opener" to me. I was expecting one property stringProp and one method stringProp but instead I got this.

Why this happened? can someone explain please.

yogi
  • 19,175
  • 13
  • 62
  • 92
  • 4
    It's not really clear what you're looking for as an answer. But [Properties](http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx) says: "... they are actually special methods called accessors." – Damien_The_Unbeliever Apr 16 '14 at 07:26
  • 3
    http://en.wikipedia.org/wiki/Syntactic_sugar – Darius Apr 16 '14 at 07:27
  • 30
    It's not legal to have a property and method with the same name, so I'm not surprised Intellisense is confused. – Mike Zboray Apr 16 '14 at 07:27
  • That's not legal *and* attempting `stringProp = stringProp();` won't compile (`stringProp is a 'property' but is used like a 'method'`) – Alex Apr 16 '14 at 07:28
  • Note that what made your eyes "open" is - in my opinion - an issue in the tooling, which shows the two members as "overloads"; where the names of the methods are unrelated. The accessor method does not have the same name with the property. – Iravanchi May 03 '14 at 06:02

4 Answers4

118

Yes, the compiler generates a pair of get and set methods for a property, plus a private backing field for an auto-implemented property.

public int Age {get; set;}

becomes the equivalent of:

private int <Age>k__BackingField;

public int get_Age()
{
     return <Age>k__BackingField;
}

public void set_Age(int age)
{
    <Age>k__BackingField = age;
}

Code that accesses your property will be compiled to call one of these two methods. This is exactly one of the reasons why changing a public field to be a public property is a breaking change.

See Jon Skeet's Why Properties Matter.

dcastro
  • 66,540
  • 21
  • 145
  • 155
  • 30
    @dc7a9163d9 Actually, `k__BackingField` is the field's name. Even though that's an illegal name in C#, it's a perfectly valid name in IL (Intermediate Language). This is the IL generated for declaring that field: `.field private int32 'k__BackingField'`. Most compiler-generated types, such as lambda closures and enumerators contain `<>` in their names. – dcastro Apr 16 '14 at 17:06
  • I have one Method that does both SET and GET. It would be great if I could call that like a property, without () – Herman Van Der Blom Feb 22 '19 at 11:33
24

Strictly speaking, properties are not methods, although they are indeed supported by getter and setter methods (also called accessors). When you write code like this (provided you modify the code to remove the compile error mentioned below)

myFoo.stringProp = "bar";

The compiler actually generates IL code like this:

ldstr       "bar"
callvirt    foo.set_stringProp

Where set_stringProp is the setter method for that property. In fact, if you so desired, you can invoke these methods directly via reflection.

However, the code sample you posted may look okay in Visual Studio's intellisense, but it will not compile. Try building the project and you will see an error like:

The type 'foo' already contains a definition for 'stringProp'

p.s.w.g
  • 146,324
  • 30
  • 291
  • 331
  • 2
    The biggest difference is that properties can have additional associated metadata via attributes which may not apply to methods. – Dan Bryant Apr 16 '14 at 14:36
18

This is visual studio intelicence issue, that picks by name. By the way your code will not compile even, due the name collision in the same type.

But you are right, that properties are methods at the end:

public class A {

   public string Name  {get;set;}  
}

here Name property is converted into 2 methods: get_Name() and set_Name().

In fact, if you define class like this:

public class A {

   public string Name  {get;set;}  

   public string get_Name() {
       return "aaa"; 
   }
}

you will get compilation error, as there is already defined get_Name (property)

Tigran
  • 61,654
  • 8
  • 86
  • 123
-2

Yes. Properties are mutator methods.

In computer science, a mutator method is a method used to control changes to a variable. They are also widely known as setter methods. Often a setter is accompanied by a getter (also known as an accessor), which returns the value of the private member variable.

The mutator method is most often used in object-oriented programming, in keeping with the principle of encapsulation. According to this principle, member variables of a class are made private to hide and protect them from other code, and can only be modified by a public member function (the mutator method), which takes the desired new value as a parameter, optionally validates it, and modifies the private member variable.

Mutator methods may also be used in non-object-oriented environments. In this case, a reference to the variable to be modified is passed to the mutator, along with the new value. In this scenario, the compiler cannot restrict code from bypassing the mutator method and changing the variable directly. The onus falls to the developers to ensure the variable is only modified through the mutator method and not modified directly.

In programming languages that support them, properties offer a convenient alternative without giving up the utility of encapsulation.

Reference: http://en.wikipedia.org/wiki/Mutator_method

Amir Saniyan
  • 13,014
  • 20
  • 92
  • 137