Posted on March 1, 2008 07:57 by mcollins

In this post, I wanted to introduce you to a new feature that is definitely more than welcome in .NET 3.5: auto-implemented properties.  Auto-implemented properties are a shorthand notation for declaring simple properties in classes.

Let's say that I'm developing a class representing a student for an educational software package.  In the past, I would have defined the class using the following code:

   1: public enum Gender {
   2:     Female,
   3:     Male
   4: }
   5:  
   6: public class Student {
   7:     private DateTime birthDate;
   8:     private string firstName;
   9:     private Gender gender;
  10:     private string lastName;
  11:  
  12:     public DateTime BirthDate {
  13:         get { return birthDate; }
  14:         set { birthDate = value; }
  15:     }
  16:  
  17:     public string FirstName {
  18:         get { return firstName; }
  19:         set { firstName = value; }
  20:     }
  21:  
  22:     public Gender Gender {
  23:         get { return gender; }
  24:         set { gender = value; }
  25:     }
  26:  
  27:     public string LastName {
  28:         get { return lastName; }
  29:         set { lastName = value; }
  30:     }
  31: }

This is a lot of code for a simple class.  Fortunately, in .NET 3.5, we can reduce this amount of code and make it even simpler:

   1: public enum Gender {
   2:     Female,
   3:     Male
   4: }
   5:  
   6: public class Student {
   7:     public DateTime BirthDate { get; set; }
   8:     public string FirstName { get; set; }
   9:     public Gender Gender { get; set; }
  10:     public string LastName { get; set; }
  11: }

Using auto-implemented properties, the .NET language compiler will automatically generate the simple data fields for the class and implement the getter and setter methods for each property.

The only thing to consider when using auto-implemented properties is that, in the past, inside the methods of my objects I would use the fields instead of the properties when I needed to access the object instance data.  When using auto-implemented properties, you will only be able to use the properties in order to get to your object's data, but that shouldn't be any more inefficient because the compiler will most likely optimize the property access.

Technorati tags: ,


Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Related posts

Comments

March 3. 2008 11:38

The only thing I wish you could do with auto properties is override the getter. For example, if I have:

public MyObject CoolThing { get; set; }

And want to do something to the object before it's returned, I have to convert it to an old "boring" property. What I'd love to be able to do is something like:

public MyObject CoolThing { get { this.counter++; return; } set; }
|

Scott Williams us

March 3. 2008 12:45

@ Scott Williams:

I'd argue that your example would be a bad use of a property getter. A getter shouldn't have any side-effects, so that two consecutive calls to the getter should return the same result. If it's a side effect, then it should be part of a method if it's going to change the state of the object.

The only case that I can think of where you'd want to specify code in a getter would be for a calculated property. In that case, you most likely wouldn't have a setter to go along with it, and the calculation would be based on the values of other properties.
|

Michael Collins

March 4. 2008 17:24

@ Jeremy Pager:

Ok...got me there. Lazy loading is what I'd consider an acceptable side-effect to have in a getter, but my original point is valid, I think. While a lazy load will modify the state of the object, when the getter returns, and on each subsequent call, the getter will return the same value. So it's almost like a half-side-effect. There's a side effect, but the callers don't know about it.
|

Michael Collins

March 4. 2008 17:56

@ Michael Collins:

What about the case where you implement, for example, lazy loading? I've seen Data Access Layers implemented such that an object's sub-properties aren't loaded until the getter is called in order to minimize hits to the database. For example, you might have:

public MyDataObject Property1 {
get {
if(_property1 == null) _property1 = new MyDataAccess().GetByID(_property1ID);
return _property1;
}
}

I suppose, however, that auto-implemented properties aren't meant for these types of elaborate solutions. If you add enough to the getter, the work involved in actually setting up the fields and properties would become lesser by comparison.
|

Jeremy Pager

Add comment


 

[b][/b] - [i][/i] - [u][/u]- [quote][/quote]



Live preview

November 20. 2008 20:16

|