Should You Use Properties Internally in a Class?

I participated in a discussion recently on the microsoft.public.dotnet.framework.performance newsgroup entitled “Accessing Property values vs private variables”. It was interesting on two fronts.

First, the original poster’s question (the subject line would have been more clearly titled, “Accessing Property Values vs Private Class Fields”) was concerned with the performance of properties vs. fields — which is why it was posted on the performance newsgroup.

One often sees performance questions of this kind, and in the context of line-of-business applications, the concern is usually misplaced. What performance difference there may be between a property and a field are usually so minor as to be completely irrelevant in the real world. An extra microsecond here or there does not add up to anything a user would actually notice in most cases. It is usually best not to fret over implementation details like this unless a real-world performance issue crops up, and via testing you track the bottleneck down and address it specifically.

The second lesson appeared when the conversation drifted to the issue of how and whether properties should be addressed by code internal to the class. It was argued by one poster that using the private fields is better form; another argued that it’s better to always use the property accessors for “easier debugging and refactoring down the line.”

I suggested that for the sake of consistency I only use private fields from internal class code unless there is some accessor functionality, like lazy evaluation management, that is needed. When I use the property accessor, it’s an exception for which there is a decent reason.

A final posting today by “WellBrewed” raised an issue I hadn’t considered:

If you’re the only one who’s changing the class internals, then you can probably remember to always use the property accessor, but using the member itself is not protected against by the compiler (can’t be).

If I have a situation like this, I will usually create a class within a class. This will encapsulate the “Always execute this code” rule. If this approach is troublesome because you have to call functions on the parent class, then I usually have to rethink my class design.”

That makes a lot of sense. The issue this poster raises has bothered me at a subconscious level, especially in C# where the semantic difference between a field and a property is often the case of the first letter of the name (e.g., field = city, property = City). This might easily be overlooked, especially months later, or by a different developer unfamiliar with the code.

A nested class would be one solution; in some cases a separate class with a private reference to it would be appropriate. Either way, the private field goes away so you can’t “accidentally” use it in future code, and the nature of the value becomes more obvious by looking something like customerAddress.City.

If the same value needs to be accessed publicly, you could either make a public property for accessing customerAddress, or create a City property that flattens that view out … although then you are back to a situation where internal code could either call City or customerAddress.City.  But, at least this is a way to permit a consistent pratice (never addressing a public property from internal code).