10

I am fairly new to auto-implemented properties and for the most of it I find them pretty straight forward but in the Microsoft site it states:

In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects. When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.

-- Auto-Implemented Properties (MSDN)

Can anyone explain what the following statement actually means with regard to auto-implemented properties: "They also enable client code to create objects."?

I cannot figure out what this means.

Thanks.

Community
  • 1
  • 1
skeandu
  • 155
  • 1
  • 6

4 Answers4

6

I believe this refers to object initializer syntax, though why this would be the case is not clear. Auto implemented properties and object initializers are separate things and shouldn't be linked together this way.

So, with a class that looks like this:

public class Cat
{
    // Auto-implemented properties.
    public int Age { get; set; }
    public string Name { get; set; }
}

You can create objects like this:

Cat cat = new Cat { Age = 10, Name = "Fluffy" };

Note:

As the comments say (and the MSDN page on object initializers declares), you can use object initializer syntax with any accessible field or property. Again, the fact that the MSDN page on auto-implemented properties even mentions object creation appears to be a bad documentation decision.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 6
    You can do the same with public fields. – leppie Aug 02 '11 at 12:31
  • 3
    And regular properties too. Basically, anything that can be set with a `Foo.x = y;` line. – Matthew Scharley Aug 02 '11 at 12:33
  • @leppie - true. From MSDN: `Object initializers let you assign values to any accessible fields or properties`. – Oded Aug 02 '11 at 12:34
  • 2
    And with normal Properties (private field, public setters)... So while the statment is true it is also true for non-automatic properties. – Anders Forsgren Aug 02 '11 at 12:34
  • @Oded: Not me, but I am partially offended by `private class` ;P – leppie Aug 02 '11 at 12:36
  • 1
    @Oded: Downvote removed after your edit, while i believe as you and jon that they refer to initializer syntax they are incorrect and the answer was letting the OP believe that there really was a link between them (other that they are useful together to minimize code both during the declaration of a class and the creation of a new instance) – Julien Roncaglia Aug 02 '11 at 12:44
  • Thanks for all the replies. I thought I was missing something but the general consensus seems to be that it is simply bad documentation. I was aware of the object initializer syntax but I wasn't sure if this is what they were referring to. Cheers. – skeandu Aug 04 '11 at 12:09
4

That's a bad description on the MSDN page, unfortunately.

Object initializer syntax (new Foo { X = 10, Y = 20 }) is completely separable from automatically implemented properties.

Object initializers can be used with any settable properties or fields (and there's even syntax for mutating "subproperties" when the "main property" is read-only); you don't have to use an automatically implemented property for this.

While it's nice that all these features work together, I believe it's useful to at least learn about them separately. For example, automatically implemented properties could have been introduced in C# 2 without object initializers - or vice versa.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Didn't know about initialising properties of read-only properties. That's pretty nifty. – anton.burger Aug 02 '11 at 12:49
  • @Anton: I've mostly seen it for initializing collections: Foo f = new Foo { SomeCollection = { new Item(), new Item() };`. Here the `SomeCollection` property is read-only, but returns a `List` which can be added to. – Jon Skeet Aug 02 '11 at 12:50
  • True, I s'pose it's similar - but collections are special-cased, aren't they? (either `ICollection` or anything which has a public `Add`, I forget which :P) **EDIT** Make that `IEnumerable` *and* a public `Add`. – anton.burger Aug 02 '11 at 12:52
  • @Anton: Yup, IEnumerable and Add it is. My point is that it's the same syntax: `= { ... }` as opposed to `= value`. – Jon Skeet Aug 02 '11 at 13:01
1

I think what they mean by

"They also enable client code to create objects."

is that the client code can init a new ref type object or assign a value type object to the auto property without having to create a private field to hold onto the data.

Oded has the example for the value type, so lets expand upon his Cat class

private class Cat
{
    // Auto-implemented properties.
    public int Age { get; set; }
    public string Name { get; set; }

    public List<Cat> Kittens { get; set; }
}

Cat cat = new Cat { Age = 10, Name = "Fluffy" }; //borrowed fluffy for this example
cat.Kittens = new List<Cat>();

cat.Kittens.Add( new Cat() { Age = 0, Name = "Pinky" } );
cat.Kittens.Add( new Cat() { Age = 0, Name = "Blinky" } );
Brian Dishaw
  • 5,767
  • 34
  • 49
  • Again, there's nothing unique to auto-properties here. I think Jon Skeet's on the money here: It's just a very poorly worded document. – Matthew Scharley Aug 02 '11 at 12:42
-1

You can Add logic to getter function by accessing values of another property there by auto implementing property values

 public string Status
    {
        get { return DeactivateDate != null ? "InActive" : "Active"; }
        private set { }
    }
rajquest
  • 535
  • 1
  • 5
  • 10