Automatic Properties in C# 3.0…Why?
One of the new features in C# 3.0 makes absolutely no sense to me: automatic properties.
I have two issues with this approach. First, Wouldn’t it make more sense to just have VS ask: “Do you want to generate a public property” when a user creates a field (like when VS detects the user adding an event handler)? From the description, it seems like the private field doesn’t get generated until compile time, meaning the class writer is working against the public property as well. This seems odd since one of the main scenarios for using public properties and private fields is so that the class writer can manipulate the internal data representation without affecting the external interface. Scott himself mentions:
The benefit of this is that from a type-contract perspective, the class looks exactly like it did with our first (more verbose) implementation above. This means that — unlike public fields — I can in the future add validation logic within my property setter implementation without having to change any external component that references my class.
Which leads me to wonder why the developer would not just write the private field declaration and auto-generate the get/set methods instead, a much more logical approach to class design which leads to more legible code.
I can appreciate that it saves space in the code view by omitting otherwise “useless” lines, but don’t code regions already accomplish the same thing?
Seems like a pretty useless feature to me that ultimately leads to more abstract code (less readable, in my opinion).
Aside from that, the code usage itself looks suprisingly similar to an abstract class. From a design standpoint, if it’s not clear what the validation logic or some other property masked logic is at the moment, if it’s not clear how the internals of the class should function, wouldn’t it make sense to program against an abstract class and put the actual logic into concrete classes at a later time when that logic is available? It seems to me that what the automatic property is saying about the class is that: “I know what my external interface looks like, but I don’t know what my internal representation and logic should be”, which is one of the reasons we have abstract classes, right? So that we can substitute the actual representation of the internal logic of the class at any time down the line while maintaining the external interface contract. I dunno, just seems like a useless and otherwise bad feature to me.
One of the other main features, LINQ, already has me shuddering in anticipation of the nasty code that I’ll inevitably have to face down the line. Can you imagine the horror of code mixed with complex data queries in any application of significance? For the same reasons that one would put a public property as a facade to a private field, it only makes sense to use a stored procedure, view, or table valued function as a facade to the underlying data (now I could see a case being made for it with a framework that allowed the queries to be loaded and cached dynamically at runtime from external files with a cache refresh callback on file change).
