codethinked (kōdthĭngked) adj. To be consumed by or obsessed with code.

Using Accessibility Modifiers on Auto Properties

I know that this post is going to be old hat for the vast majority of you, and if this is the case, then please just ignore this post. More than likely though, you’ve come across someone that needs to read this post, and if so please pass it on!

If you’ve been using C# 3.0 for long enough then you have probably started using a neat little piece of syntactic sugar called automatic properties.

For the uninitiated, instead of writing this:

public class Person
{
    private string firstName;
    public string FirstName
    {
        get { return firstName; }
        set { firstName = value; }
    }

    private string lastName;
    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

You get to write this:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

And yes, we aren’t performing magic, it is just shorthand for the properties above, and you can clearly see that if you reflect it. I won’t show you the IL here, but you can just trust me. :-)

Unfortunately, for most developers, the above use of automatic properties is where the fun stops. Once they get to the point where they need to have a read-only property, they fall back to their old tricks and write this:

public class Person
{
    private string firstName;
    public string FirstName
    {
        get { return firstName; }            
    }

    private string lastName;
    public string LastName
    {
        get { return lastName; }            
    }
}

Boooooooo! You don’t need to do that silly developer. You just need to do this:

public class Person
{        
    public string FirstName { get; private set; }
    public string LastName { get; private set; }
}

See, now how hard was that? Now you have a public property with a private setter. You can also use protected or internal, so that you can set it from inherited classes and within the same assembly:

public class Person
{        
    public string FirstName { get; protected set; }
    public string LastName { get; internal set; }
}

And yep, you can even create a write-only property, although this has less usefulness:

public class Person
{        
    public string FirstName { private get; set; }
    public string LastName { private get; set; }
}

So you have all of the functionality you need, unless you require some custom logic be inside of your getters or setters. If you haven’t been aware of these features of automatic properties then first get out from under your rock, and second, go out there and delete some code! Hope you enjoyed!

Comments

Mike Borozdin

Wow, didn't know about that.

Mike Borozdin

August 25. 2009 04:02

Russia
Andrey Titov

I considered auto properties incomplete feature. They missed functionality that readonly keyword provides for fields. And in case of struct I need call empty ctor first, that switches off validation of field initialization completeness.

So all my read only properties are backed with readonly fields.

I think it will be better to eliminate fields from language at all. Let all be property and let fields be implementation details. I mean that field declaration should create auto property and there should be no way to create pure field from C#. This should not have performance impact because I'm sure all simple properties are inlined by JIT/ngen. This can only change something in native interop but no more than adding one additional attribute.

Eliminating properties, I think, will simplify the language a bit. It will be unnecessary to explain why fields should not be public or protected over and over again.

Andrey Titov

August 25. 2009 05:35

Russia
Andrey Titov

*Eliminating fields (in last sentence)

Andrey Titov

August 25. 2009 05:39

Russia
Perry

Or use the Visual Studio shortcut "propg".  This inserts the template for an automatic property with a public getter and a private setter.

Perry

August 25. 2009 10:33

United States
trackback

Using Accessibility Modifiers on Auto Properties - Justin Etheredge

Thank you for submitting this cool story - Trackback from DotNetShoutout

DotNetShoutout

August 25. 2009 11:36

trackback

Using Accessibility Modifiers on Auto Properties

You've been kicked (a good thing) - Trackback from DotNetKicks.com

DotNetKicks.com

August 25. 2009 12:10

Troy DeMonbreun

Now we just need Auto Implemented Properties "null default value" settings. For instance, for a string property that is null, default to String.Empty. Something like:

public string FirstName { get default String.Empty; set; }

To do this otherwise you have to revert to a backing store.

Troy DeMonbreun

August 25. 2009 12:18

United States
trackback

Using Accessibility Modifiers on Auto Properties

DotNetBurner - burning hot .net content

DotNetBurner - C#

September 12. 2009 17:55

pingback

Pingback from facility9.com

Links for the Week of 2009.09.12 | Jeremiah Peschka, SQL Server Developer

facility9.com

September 12. 2009 19:17

Add Comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading