CODEWITHSUNDEEP
c#.net
SNag
SNag

Reputation: 18141

Why create public wrappers to private members in a class?

I've always had this question, but I've blindly followed on so far.

This is from a piece of example code:

Why do this:

public class EmployeeInfo
{
    int _EmpNo;
    public virtual int EmpNo
    {
        get { return _EmpNo; }
        set { _EmpNo = value; }
    }

    string _EmpName;
    public virtual string EmpName
    {
        get { return _EmpName; }
        set { _EmpName = value; }
    }
}

when there's nothing additional, such as calculations or validations, being done during getting/setting?

Will this suffice?

public class EmployeeInfo
{
    public int EmpNo { get; set; }
    public string EmpName { get; set; }
}

Also, why virtual for the public member wrappers?

Upvotes: 2

Views: 433

Answers (5)

MikeT
MikeT

Reputation: 5500

Depends if you want to see the field publicly or not,

if your only going to use the field inside the declaring class then you don't need to wrap it in a property, its only if you need to expose it publicly or down the inheritance tree that you should have the property

public string EmpName { get; set; }

is just a compiler short cut to 

private string _EmpName;
public string EmpName { 
    get{ return _EmpName;}
    set(_EmpName = value; }
}

they are functionally identical. However there are things that the short cut wont let you do, for example you want to raise an event when the property changes.

there there is also your use of Virtual which is an inheritance modifier Virtual instructs the code that it needs to look DOWN the inheritance tree for a newer implementation. so in

class A
{
    public string Data
    {
        get{return "A";}
    }
    public virtual string VData
    {
        get{return "A";}
    }
}
class B:A
{
    public new string Data
    {
        get{return "B";}
    }

    public override string VData
    {
        get{return "B";}
    }
}

then if you do 

A obj = new B();
obj.Data; //return A
obj.VData; //return B

Upvotes: 2

A.Konzel
A.Konzel

Reputation: 1980

The expanded form is the traditional way to do it:

public class MyClass
{
    int _myInt;

    virtual public int MyProperty
    {
        get
        {
            return _myInt;
        }
        set
        {
            _myInt = value;
        }
    }
}

However, the shorter form is called "auto properties", introduced in C# 3.0.

public class MyClass
{
    virtual public int MyProperty { get; set; }
}

These code blocks are equivalent. This is a good practice for keeping your code concise.

One thing to consider: You aren't able to make the internal variable protected with auto properties, so if you create a derived class and override your property, you'll need to use base.MyProperty to access it, or use the expanded form.

Upvotes: 0

D Stanley
D Stanley

Reputation: 152566

Why do this?

There's really no reason to since the addition of auto-implemented properties in C# 3.0. It could be legacy code that hasn't been changed, old habits, or keeping consistency with pre-C# 3 code.

Will this suffice?

No - you've converted the virtual properties to non-virtual. So they are not completely equivalent.

The equivalent would be

public class EmployeeInfo
{
    public virtual int EmpNo { get; set; }
    public virtual string EmpName { get; set; }
}

Also, why virtual for the public member wrappers?

So that a derived class can override the logic for the properties - to add validation, change notification, etc.

When does the shortened form actually have an impact?

When the backing fields are referenced by the internal code of the class (which can be detected at compile-time), or when they're accessed by reflection (which cannot be detected until run-time, or via static code analysis).

An "auto-implemented" property actually gets a backing field created by the compiler, so in that sense they're equivalent if the only place the backing field is referenced is within the property code.

Upvotes: 5

Habib
Habib

Reputation: 223267

You have two questions. First is changing properties to auto implemented properties, they should be equal, but you removed virtual keyword, that makes them different.

So, what is virtual. That keyword will allow derived classes to override the get/set for the said property.

See: virtual C#

The virtual keyword is used to modify a method, property, indexer, or event declaration and allow for it to be overridden in a derived class.

Your class with auto-implemented properties would be equal if you have:

public class EmployeeInfo
{
    public virtual int EmpNo { get; set; }
    public virtual string EmpName { get; set; }
}

Later you can override a property and leave the other to maintain the parent behaviour, like:

public class ManagerInfo : EmployeeInfo
{
    private int _EmpNo;

    public override int EmpNo
    {
        get { return _EmpNo; }
        set
        {
            if (value < 100) throw new Exception("EmpNo for manager must be greater than 100");

            _EmpNo = value;
        }
    }
}

Upvotes: 3

CodeCaster
CodeCaster

Reputation: 151594

It looks like the code in this form:

$type _$var;
public virtual $type $var
{
    get { return _$var; }
    set { _$var = value; }
}

Was generated using a tool, template or snippet. As habits hardly ever change and tools, templates and snippets hardly ever get updated, I guess they were created before auto-implemented properties (public $type $var { get; set; }) were introduced to the C# language.

For the code you show, it's perfectly valid to have the equivalent:

public virtual $type $var { get; set; }

As you can override the auto-implemented property and add a backing field, validation and whatever when required.

Upvotes: 1

Related Questions