Saturday, 19 July 2008

Automatic properties; a great idea?

A little while ago I had a conversation with another guy about coding standards and the subject of member variable prefixing came up. I'm a real fan of underscore prefixes like private string _firstName; and suggested that this be included in the coding standard so as to avoid problems stemming from sloppy coding and member names varying by case only.

I've come across many a class where the coder intended to access the property FirstName but - possibly because of IntelliSense or other code-completion shenanigans - ended up accessing the member variable firstName instead. If member variables are consistently prefixed then this isn't a problem. I like the underscore because it stands out, it's just one character, and it kind of anchors the variable to the class or scope.

Anyway, the chap I was speaking to said "sure, we can use prefixes but it really isn't so necessary because we'll just use automatic properties instead."

Hmmmm..... Simpson, hey?

Today in C# you've the ability to declare typed properties which hide the underlying variable. In other words, there's no longer the need to declare a private member variable and expose it explicitly through a public property. Now all you have to do is create the property itself, like this:

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

It is a pretty cool feature. But it's really limited as well. If you want to do anything but expose a variable on your class' interface, you can't use automatic properties. You can define the setter as private but that's about the flexibility you have.

Once you start to tamper with either the getter or setter your property is no longer considered automatic, so you're back to good old normal properties. It seems to me there's not a whole lot to be gained from automatic properties because in my experience and, more often than not, you typically want to do something other than access a member variable (at least in the setter) when the property is called.

Oh, and another thing: Automatic properties aren't debuggable. You can set a breakpoint on an automatic property but it will never be hit. Boo.

I reckon that in the future we'll be able to have another kind of automatic property where you actually can access the get/set variable, validate, or do whatever you like.

For now the automatic property is nothing but a bit of syntactic sugar. I'm on a diet (ha-ha!) so I'm likely to stay clear.


Unknown said...

Hi Øyvind!

Again, another fine blog post :)

Here are some comments on why automatic properties matter.

1) You can't databind against public fields. Alot of times you have really dumb data transfer objects, for instance the one automaticly generated by the web service proxy tools. This tool now generates classes with automatic properties so that you can bind against them.

2) The "alternative" to a automatic property (a property with no backing set or get logic) is a public field. You might expose a public field, and lather when needed wrap it in a property. The problem with this is that changing from a field to a property changes the public interface of your class, so anything that is compiled against that class has to be rebuilt.

If you're using an auotmatic property with no set or get logic, you can change this class later on, recompile, and not have changed the public interface of your class.

3) It's just handy.. It saves time and keeps your code compact. There is no underlaying changes in the CLR, and if you dissasemble your code you will find a set_Name and a get_Name method, and a _name backing property.

Personally I allways use automatic properties unless I know I'm going to change it, if so I use one of the properties code snippes to have a property with a get and set set up for my real quickly. Would also be cool if you could add some aspect oriented programming behaviour to automatic properties. Like saying this property should trigger the INotifyPropertyChanged.PropertyChanged event... :)

Jonas Follesø

Øyvind Valland said...

Hello Jonas,

Thanks for commenting!

I concede that automatic properties have their place when it comes to dumb DTOs. In a previous life I had two libraries of DTOs (one for services, one for the DAL) that had to be kept in sync with each other. E.g. there was an Address DTO in one library (exposed as a DataContract) and an Address DTO in another library used with an Object-Relational Mapper (iBatis). Both classes would implement IAddress which defined all the properties on the interface. Without automatic properties maintaining and building these classes were a real pain.

As for the alternative to automatic properties (which you've appropriately wrapped in double quotes), I think it isn't an alternative unless you have a very good reason to expose a field directly - which isn't often.

A lot of developers like to use properties for more than simple member variable access. Not that it's an example of good practice, perhaps, but having the ability to add some validation on a setter can be useful and it's a shame that this isn't supported with automatic properties. I like your idea of using events for this, and I can only hope that MS gives us a dual solution where you can use events or create an automatic property where you can inject some code and work on the "value" parameter.