Refactoring C# Series: Use Automatic Property
Name
Use Automatic Property
Summary
You have a property in a class which just wraps a field of the same type, and simply returns or sets that field.
private string _field1; public string Field1 { get { return _field1; } set { _field1 = value; } }
Becomes:
public string Field1 { get; set; }
C# Version
3.0
Motivation
Encapsulation is quite possibly the key principle of object-oriented design. It is common practice in C# to encapsulate fields by wrapping them in a property.
When a class has many properties, much of the class is taken up by the same coding pattern for a property:
private string _field1; public string Field1 { get { return _field1; } set { _field1 = value; } }
In C# 3.0 this block of code can be removed by using automatic properties. The compiler will do the same thing that you would have done before if you just define the property name and the getter and setter.
public string Field1 { get; set; }
Reducing the property code like this makes it much easier to understand the code later, as only the necessary details are defined. Even if you use a terse syntax formatting, as in the previous example, you are saving 5 lines of code per property. The way I usually format my code with extra linefeeds, I save 9 lines for each one. When there are a lot of properties in a class, that is a large amount of code which can be removed.
Removing code isn’t just good for making it easier to understand; it makes it easier to test too. You wouldn’t have to test properties to see if they are simply setting and getting the correct values with this syntax, as the compiler is doing the work for you. So if you have unit tests, you might be able to remove lots of property testing code.
Of course, if the property does not just simply set or get a field value, you must use the previous C# 1.0 syntax for properties. In addition, you cannot specify get or set alone, but you can include scope identifiers to make a set private, for example:
// The following are not valid: // Automatically implemented properties must define both get and set accessors public string GetOnly { get; } // Not valid public string SetOnly { set; } // Not valid either // But this is okay public string GetWithPrivateSet { get; private set; }
Mechanics
- Remove the body of the property, replacing the code between the get and set blocks with a semicolon “;” .
- Compile.
- If there is a compiler warning that the field is no longer being used, you can now simply remove the field which the property was wrapping.
- If there is no compiler warning, other methods or properties are using the field directly. You can remove the field and recompile anyway, which will give you the location in the code where the field is being used. Replace each reference with a reference to the property instead.
- Compile.
Repeat for each property.
If the field was a protected field, not private, then you might have subclasses which access the field. They will have to be changed to access the property instead of directly accessing the field.
Tip: For new code, you can simply use the code snippet “prop” in Visual Studio 2008 to get an automatic property.
Examples
I’ll just do an example with one property, even though it looks a lot better with a longer class.
class Account { private long _id; public long ID { get { return _id; } set { _id = value; } } }
First, remove the body of the property getter and setter (and apply a bit of reformatting too, if you like):
class Account { private long _id; public long ID { get ; set ; } }
Compile, to make sure the code is happy, then remove the field:
class Account { public long ID { get ; set ; } }
This is my personal blog, where I express my thoughts and thinking about programming and software development.
Mohamed Abdeen
26 Feb, 2008
That’s a good feature
Laughing John
15 Aug, 2008
This is NOT a good feature.
It is made useless because you cannot initialize the properties. Strings and objects will always default to null which is often not the required behaviour.
Additionally you can no longer use the prop snippet to generate a standard property.
So these are often only of use for a reference type and it now takes longer to create a standard property. Where’s the sense in that?
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361647
Richard Bushnell
18 Aug, 2008
Hi John,
I just set the initial value of the properties in my constructor. I’ve got used to doing this now, and find that it makes the initial values of my properties much easier to find when coming to read the code later.
Using the code snippets for properties in Visual Studio (“prop” and “propg”), I can write my properties really fast, with really compact code. Then I pop up to my constructor(s) and set the initial values of the properties there.
HTH.
Richard
dave
11 Nov, 2008
The problem isn’t that the automatic properties are initialized to null. That can be taken care of in the constructor. The problem is that there is no way to enforce that the setters cannot be called with null. There needs to be an annotation or a keyword to indicate that null is not an acceptable value and should generate an exception.
dm
3 Apr, 2009
john, dave: if you need guarantees like that then use regular properties.
auto properties are only there to save you time if they can save you time. no one is making you use them. in about 75% of cases in my code, i can get away with auto properties. the places where they don’t work–it’s not a big deal. seriously.