Auto Property Initializers – Day 4 – Visual Studio 2015

By October 4, 2015C#, C# 6, News, Visual Studio

C# 3 introduced support for Auto-Implemented Properties, which can be used to succinctly declare properties that have no additional logic. Without Auto-Implemented Properties, if you wanted simple properties on a C# class you would need to write code like this:

This is fairly verbose, and the introduction of Auto-Implemented Properties meant that this kind of repetitive code could be greatly simplified:

However, in both of the above examples, there are some problems. Namely, this class doesn’t initialize any of its properties, nor does it encapsulate any behavior. The former makes it prone to errors like null reference exceptions, and the latter means working with this class will tend to violate the Tell, Don’t Ask principle. In both cases, the lack of object oriented design principles followed in this class will result in more code having to be written everywhere this class is used.

In the first version, without auto-implemented properties, we can simply initialize the backing fields. However, let’s assume we don’t want to give up the convenience of auto properties just to be able to initialize property values. In that case, we would perform our initialization in the constructor, which also allows us to follow the Explicit Dependencies Principle, specifying in the constructor those values this object requires in order to be in a consistent state (in this case, we are saying that an Appointment requires a Date):

Now, this class still has a number of code smells that should be addressed, but in terms of initialization, it’s going to be in a valid state when it’s constructed (assuming it’s acceptable for ID to be 0, which is typically fine especially prior to the initial persistence of the entity). However, this is a very simple class with only a few properties, so it’s relatively straightforward to see that we are initializing all of them (or at least the ones we think we need to) in the constructor. But what happens if there are many more properties, and several different constructors? It can become very difficult to quickly determine at a glance whether the class’s properties are being set up properly, since the initialization is separated from the properties themselves. This is where the new C# 6 feature, Auto Property Initializers, comes into play. The syntax for this feature allows a value to be assigned on the same line as the auto-property, following the closing curly bracket. Thus, the above version of the Appointment class can be rewritten using Auto Property Initializers as follows:

Note that in this case I’ve chosen to add an initializer to Id, even though it’s just setting it to its default value, to make explicit the initial values of each property. The Date property does not have an initializer, since its value is still being set in the constructor. In this version, the total number of lines of code has been reduced, and the constructor has likewise been simplified. Initialization takes place with declaration, making it much easier to identify mistakes and omissions (a common source of bugs). This class still represents an Anemic Model and exhibits the Exposing Collection Properties code smell (see how to properly expose collection properties).

The following two tabs change content below.