Search
Thursday, March 01, 2001 ..:: Home ::.. Register  Login
   Calendar  
     
  
   Search  
     
  
   Disclosure  
     
  
   TechTidBits (Blog)  

Automatic Properties? Heard of'em? They're great for whipping up demo/test stuff!

Nov 14

Written by:
Saturday, November 14, 2009 1:29 PM  RssIcon

Do you use Properties?  COOL!  Then you might want to check out Automatic Properties to help save a bit of typing.

First off, do you use Properties in your code?  If you don't, thanks for reading so far, but you can go now.

Still here? COOL!  Hey, it's not such a dumb question, eight years ago, I worked at one java-shop, and they had a massive distaste for properties.  Mind you, to be fair, properties in Java 2 was just a concept since you implemented them as methods.  It was the extra/additional method calls the sr devs had problems with.  To be completely fair and open, under the covers, that's all they are in C# too, method calls.  Yup, properties eventually equate to method calls, the "looks cool in Visual Studio" part is just syntactical sugar.

AAAAAAAaaaaaaaaaaaaaanyways!  Back to today's topic.  Automatic Properties.  Since you're using properties, you're used to stuff like this.

    private Uri rssUri;
    public Uri RssUri
    {
      get { return rssUri; }
      set { rssUri = value; }
    }

Exciting eh?  LOL  But seriously, this is bread'n'butter kind of stuff/code you've probably typed out hundreds of times in your C#/VB.NET life?!  You have a private backing member/variable that's publically exposed by a property that has an accessor (get) and mutator (set).  Basic stuff right? 

But have you tried doing other things in the get/set methods?  Are you a web coder and add/remove these properties from the Session/Application?  Have you ever created a property that retrieved some private variable, say returned a URI as a string?  What about hiding the set/accessor by not providing one?  Ya, if you remove the set "method" from the property, you effectively make the property "read only" since you publically have no way to change it (the set's gone remember).  Those are just some of the benefits of using the ol'fashioned way of doing Properties.

But what if you're just whipping up some demo code?  Prototyping something?  Making a blog about something and just want to get a property into your code and you just don't care about the backing variable?  Or if you're just not interested in doing anything fancy with that backing store, why not try a C# 3.0 addition officially called Auto-Implemented Properties or more commonly known as Automatic Properties.

To contrast from the above example, it would look like this.

    public Uri RssUri { get; set; }

DOH!  Anticlimactic eh?  The real story here is what you don't see!  You don't see the private backing variable/variable.  You don't even see any code in the get or set methods, cause well, they're only keywords, no methods there.  And this is why I say using these are great for prototyping or if you don't care about the backing store.

And there in lies the rub with using Automatic Properties, you have to not care about the backing store.  As soon as you want/need to manipulate the accessor OR mutator, you need to do thing the old way.  Also, you HAVE to want to have a get AND set cause otherwise you'd never get to set or get the value.  Think of it, if you only provided a get, you'd never be able to put something into it.  Also, what good is setting a value if you can never retrieve it again (ala /dev/null).  Doing things the old way affords you the ability to create "read-only" properties, or even properties you can set but never get, cause you always have the private backing variables you can access.  This is so important that it's enforced in the C# compiler.  The compiler is trying to protect you (or me in the case above) from ourselves since the above code would create something I could never set.  DOH!

Compile error without a mutator/set keyword

Tangent.....hhhmmmm if BOTH the get and set are required/mandatory/compulsive/you can't get away without BOTH of them......makes you wonder why MS didn't just skip over them and just find a faster/better way to declare the automatic properties without having to type out something extraneous. 

Aaaaaaaaaaaannd we're back. LOL

Another difference in what you don't see is the ability to initialize the Automatic Property.  In the old fashioned way, you can easily initialize the private variable but you aren't allowed to do that with Automatic properties.

About that "backing store" variable?  Well, since the above code is just "syntactical sugar", what's going on behind the scenes you might ask?  Good question!  The compiler can make some correct assumptions, it will create the backing field and two additional methods, remember above when I said properties are just more methods?  Check out the intermediate language below and you'll see the private variable and the get, set methods which the compiler creates for you.

IL Code

 Oh, and if you're thinking you access those private variables the compiler creates for you?  DOH!  Think again, nope, you can't, sorry!  You now know they're there, but they're not to be used.  Check out what happens if/when you try.

 Trying to get value from backing store

 So now that you know a bit more about Automatic Properties, I hope you will use them appropriately to help save some typing, as well as use the old way with the knowledge you're doing it the right way!  Now it's time to grab a coffee and get coding.

  

References:

MSDN: Auto-Implemented Properties (C# Programming Guide)

Stephen Fuqua: Automatic Properties in C# 3.0

Bart De Smet: C# 3.0 Automatic Properties Explained

 

Tags:
Categories:
Location: Blogs Parent Separator TechTidBits

Your name:
Gravatar Preview
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel 
     
  
Copyright 1999-2012 by PCHenry.com   Terms Of Use  Privacy Statement