1

difference between property with empty accessor or without accessor?

// Property with empty accessors
public string Name { get; set; }

// Property without accessor
public int Counter;

edit:

what implications beyond the compiler's statement implies such

Cœur
  • 37,241
  • 25
  • 195
  • 267
rkmax
  • 17,633
  • 23
  • 91
  • 176

3 Answers3

4

Actually second one is not property it is public field.

Properties in C# is just shortcut for two type of methods - accessors and mutator (or get and set). So, when you write some property like

private string _name;

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

Compiler will actually create two methods 

public string get_Name() { return _name; }
public void set_Name(string value) { _name = value; }

When you write 

public string Name { get; set; }

then compiler will generate those two methods and generate backing storage (field _name) for you.

When you do not use get and set, then it is simple field (like _name) and no methods will be generated by compiler.

For your second question: What is the difference between a field and a property in C#

Because property is actually a method(s), they could be abstract or virtual, could be overridden. Properties could be part of interface. Properties could be used in data binding. You can add any logic to property (e.g. raising some event, lazy-loading, or performing validation). You can define different access level for setting and getting property (e.g. private and public). This all is not true for public fields.

Community
  • 1
  • 1
Sergey Berezovskiy
  • 232,247
  • 41
  • 429
  • 459
  • this behavior have some impact on performance or has special effect on multiple objects? – rkmax Apr 18 '12 at 07:14
  • Not necessary, during execution this code could be inlined. And even if it will not, I don't think performance loss will be big. What public fields impact is encapsulation of your class. Also you can't use public properties for data binding. – Sergey Berezovskiy Apr 18 '12 at 07:17
  • its important to note that when you refactor a field to a property you need to re-compile all other code which references this field/property. When you have a property and you alter the implementation this is not needed. – Mark van Straten Apr 18 '12 at 07:48
  • @Mark yes, and also properties are treated differently when you use reflection. – Sergey Berezovskiy Apr 18 '12 at 09:23
3

for first one compiler will generate private field, for example:

private string _name;
public string Name { get {return _name;} set { _name = value; } }

second one is just a public field.

In addition you can override properies in derived class (in case of field you can't).

there is good explanation of the implication on SO: Why are public fields faster than properties?

Community
  • 1
  • 1
Kamil Lach
  • 4,519
  • 2
  • 19
  • 20
0
public string Name { get; set; }

This syntax will create an auto-property. It's a shorthand, equivalent to this:

private string _name;

public string Name
{
    get
    {
        return this._name;
    }

    set
    {
        this._name = value;
    }
}

This is different from this syntax:

public string Name;

This creates a public field.

The difference is that where a field is a block of memory, properties are actually shorthand for methods to get or set a value on an instance. While the two appear to have the same behaviour, they're subtly different.

Generally-speaking, you want to go with properties for all public-facing values, because they're an abstraction around your own internal implementation. If you wanted to change your property's internal getter implementation to something more complicated later, there's no change to the public interface of your class and the change is invisible to anything using your class.

Generally-speaking, you will always want to use properties for your public members. There's no real cost to doing so and it makes your objects easier to maintain.

Paul Turner
  • 38,949
  • 15
  • 102
  • 166