CodeFeed

Somebody was kind enough to add a link in comments to Ted Neward’s response to my earlier blog on C# properties. I appreciate Ted’s insights, although I think he missed my point a little. As I said it is good to have properties as a first-class concept. No question there.

I guess what I really was getting at was that it would be nice to use a simple public field as the implementation of a property, even if that property is declared in an interface implemented by the class. This could be changed to the method style property definition, if required, without changing the type’s interface. Maybe that is a little too much syntactic sugar.

With regard to Ted’s position on components v objects, I don’t take such an extreme position as Ted:

First of all, we need to stop thinking about classes and objects–that’s the 90′s way, and it failed. Simply put, thinking in objects is a terrible idea, and it’s only becoming more and more obvious as time goes on.

I remember Betrand Meyer’s description of component software in his 1999 IEEE Software column:

The phrase “objects are dead, long live components,”although a good attention-getter, does not make much sense technically. All the evidence
suggests that successful component technology must build on object orientation. For one thing, no one knows how to build complex, mission-critical software today without the help of OO techniques. But even more importantly, most of the fundamental ideas that define object technology are just as fundamental to any successful component development

Maybe I’ll have to do a bit more reading …

Since I’m doing some C# programming recently, I thought I’d create a new category (C#) and explore some issues in that area. Many of these issues are probably due to my recent history as a Java programmer coupled with a certain unfamiliarity with C# idioms. I’m not sure how well established C# idioms are at this time, nor do I necessarily like the ones that are.

Let ms start with C# properties. I quite like the idea of properties especially as they group the set and get operations. In other words, the concept of a property is a first class feature rather than something which emerges from the presence of related setter and getter methods.

Now, the question I have is whether you should start with a simple public field and move to a property if more complex behaviour needs to be encapsulated or should you start with a private field and trivial property definitions. The problem is that property access remains distinct from field access at the bytecode level if I understand correctly. That means properties are good for source evolution but not so good for binary evolution. If you do start with a simple field and replace that later with a property, it means recompiling all users of the code. On the other hand, coding trivial property accessors is not terribly exciting either.