I'm not a Microsoft guy. But at my latest job, I've had to use some of the Microsoft .net programming tools. Specifically, Visual Basic.NET and C#. One interesting feature of both is properties.

Properties are a language construct to suppose getters and setters (aka, "accessors" and "mutators"). For example, in java, I'd do:

       private int vendorCount;
       public int getVendorCount() { return               this.vendorCount; }
       public int setVendorCount() { this.vendorCount = vendorCount; }

This allows the underlying data structure that encodes the vendor count to change independently of the code that needs the vendor count. E.g., We might want to compute vendor count instead of just store it,

       public int getVendorCount() { return this.vendors.length(); }

There's no special support in java for this particular programming idiom. But VB.NET and C# do have properties for doing just this. E.g., in C#,

       private int _vendorCount;
       public int vendorCount {
         get { return this._vendorCount; }
         set { this._vendorCount = value; // "value" is an implicit parameter of the same datatype as the property }

You can then use vendorCount in C# essentially as if it were a field in the class; e.g.,

       vendorCount += 2;

This seems nicer than:

       setVendorCount(getVendorCount() + 2);

Properties aren't amazingly wonderful, they're just nice. But properties are being badly abused by the Microsoft class writers and those who follow MS coding standards.

The problematic use occurs when the class provides support for multiple 'input' types to the property. For example, an ADO.NET SqlCommand has a collection of SqlParameter objects; these would be used to specify parameters for a stored procedure. Only certain types can be assigned to the "value" property of a SqlParameter -- e.g., string, int, DbNull. But the type defined for a SqlParameter is just Object.

The problem is that I can't know -- without just trying and failing -- exactly which types can be assigned to the Value property to get a useful result. Only certain types will work there -- but just saying that you can assign any Object doesn't help. If I pass in a ServiceProvider object (a class I wrote), will that work? Certainly not.

Likewise, I don't know what I'm going to get when I get the Value(). All I know is that it'll be an object. It might be a DateTime, or a string, or anything. I have to manually try casting from Object to other classes to figure out how the class library works.

The java way of doing this would be to use polymorphism to define multiple getters and setters -- one for each of the valid types that can be gotten and set. For example,

       public int getValue() { ... }
       public datetime getValue() { ... }
       public string getValue() { ...}
       public setValue(string value) { ... }
       public setValue(datetime value) { ... }
       public setValue(int value) { ...}

By doing this, the compiler itself (and the reference documentation) ensure that I'm setting and getting meaningful values.

Properties are a nice language feature, but I hate that they're being abused. This reduces the overall quality of the .NET programming platform, because it reduces the effectiveness of .NET programmers.