fields/properties/object Initilisation

mp3909

Well-known member
Joined
Apr 22, 2018
Messages
61
Location
UK
Programming Experience
3-5
C#:
public class Cat
{
    // Auto-implemented properties.
    public int Age { get; set; }
    public string Name { get; set; }

    public Cat()
    {
    }

    public Cat(string name)
    {
        this.Name = name;       //I do not see a field called Name declared
    }
}


C#:
Cat cat = new Cat { Age = 10, Name = "Fluffy" };
Cat sameCat = new Cat("Fluffy"){ Age = 10 };


I was just re-visiting some C# material over the Internet and found the code above which is meant to explain the concept of object initialisation.
The above code is confusing me because a parameterized constructor is declared that supposedly meant to set the field "Name".
But I don't see a field "Name" declared anywhere.
I do however see a property "Name" but this is not a field.
Does anyone else agree with what I am saying?
 
You can use a property also from within the class.
 
Before the days of auto-implemented properties, might have been written like so:
C#:
public class Cat
{
    public int _age;
    public string _name;
        
    public int Age
    {
        get
        {
            return _age;
        }
        set
        {
            _age = value;
        }
    }
    
    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }

    public Cat()
    {
    }

    public Cat(string name)
    {
        this._name = name;
    }
}
Is that what's confusing you? That extra code is basically added implicitly by the compiler. In fact. if I'm not mistaken, you can see those implicit fields in Intellisense.
 
It was not the field the constructor set, it was the property.
 
It was not the field the constructor set, it was the property.
Yeah, I wasn't suggesting that that was not the case. I was just pointing out that, in the old days, we probably would have set the field in the constructor but, with auto-properties, we generally set the property because the field is hidden, even though we could do the other in both cases. Either way, the property and the field still get set because they share the same value.
 
@jmcilhinney, the old way of it being written is the only way I am familiar with and it makes sense.
I have never seen the new way. The new way does not make explicit declaration of the fields _age, _name so I was confused on what was being set a value inside the constructor.
 
Auto-properties were added because the majority of properties followed the same pattern and it was a waste of time writing out full implementations with backing fields and fully-implemented getters and setters all the time. For such a property, there's no effective difference between setting the backing field and setting the property because both change the value of both. Auto-properties save a lot of tedium. The only reason to create full implementation of a property is if you need to add extra code into the getter or setter, e.g. validation or raising an event. In those cases, you would still need to declare the backing field yourself and you may also want to set that field in preference to the property in certain cases, e.g. if a property is initialised in the constructor and that property raises an event when it changes, you would want to set the field in the constructor rather than the property, in order to avoid that event being raised.
 
Back
Top Bottom