Design Guidelines for Class Library Developers

The .NET Framework's managed environment allows developers to improve their programming model to support a wide range of functionality. The goal of the .NET Framework design guidelines is to encourage consistency and predictability in public APIs while enabling Web and cross-language integration. It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework. Inconsistent design adversely affects developer productivity. Development tools and add-ins can turn some of these guidelines into de facto prescriptive rules, and reduce the value of nonconforming components. Nonconforming components will function, but not to their full potential.

These guidelines are intended to help class library designers understand the trade-offs between different solutions. There might be situations where good library design requires that you violate these design guidelines. Such cases should be rare, and it is important that you provide a solid justification for your decision. The section provides naming and usage guidelines for types in the .NET Framework as well as guidelines for implementing common design patterns.

Read more: I have delicious Design Guidelines for Class Library Developers.

Difference between properties and method [Microsoft Design]

In most cases, properties represent data, and methods perform actions. Properties are accessed like fields, which makes them easier to use. If a method takes no arguments and returns an object's state information, or accepts a single argument to set some part of an object's state, it is a good candidate for becoming a property.

Properties should behave as if they are fields; if the method cannot, it should not be changed to a property. Methods are preferable to properties in the following situations:
· The method performs a time-consuming operation. The method is perceivably slower than the time it takes to set or get a field's value.
· The method performs a conversion. Accessing a field does not return a converted version of the data it stores.
· The "Get" method has an observable side effect. Retrieving a field's value does not produce any side effects.
· The order of execution is important. Setting the value of a field does not rely on other operations having occurred.
· Calling the method twice in succession creates different results.
· The method is static but returns an object that can be changed by the caller. Retrieving a field's value does not allow the caller to change the data stored by the field.
· The method returns an array.

I also have delicious on Microsoft Design [Use properties where appropriate]