C# Framework Design Guidelines - Notes

    https://channel9.msdn.com/blogs/pdc2008/pc58 -

Krzysztof Cwalina

Constructors - Do minimal work in the constructor - Be Lazy - only capture arguments
Properties   - getters should be simple unlikely to throw exceptions
                       properties should not have dependencies on each other
                       order dependency should not be there
Use a Property - If the member logical attribute of the type
Use a method   - if operation is a conversion, ToString()
                 if the getter has an observable side effect
if order of execution is important
if method might not return immediately
if memeber returns an array

Extension Methods - static methods - the first parameter has "this" as the first as the modifier
allows you to call it as a instance method syntax
Extension methods are compile time...

namespace X.StringManipulation {
   public static class StringExtensions {
      public static bool IsNullOrEmpty(this string s) {
         return String.IsNullOrEmpty(s);
      }
   }
}

using X.StringManipulation;
string message = "hello";
if (message.IsNullOrEmpty()){
  //
}

Consider using extension methods to "add" methods to interfaces

Everyone has to implement the interface methods,

public interface IFoo{
  void Bar(string x, bool y);
  void Bar(string x);
}

Solution:
public interface IFoo{
   void Bar(string x, bool y);
        }

public static class IFooExtensions{
 public static void Bar(this IFoo foo, string x){
   foo.Bar(x, false)
 }
}

IFoo foo = ..;
foo.Bar("Hi!");

Consider using extension methods to manage dependencies - Refactoring dependencies in the program

Uri uri = "ftp://some.ftp.ui".ToUri();
  Have to put it in System.String but,
  Uri is in System.dll
  ToUri is in System.String (mscorlib.dll)
  There is rules saying that System.dll cannot depend on mscorlib.dll

  So solution is to put this in a higher level assembly dll and have an extension
  This can live in System.dll
  namespace System.Net {
     public static class StringExtenstions{
       public static Uri ToUri(this string s){.. }
     }
  }

Avoid frivolously defining extension methods, especially on types you don't own
Avoid defining extension methods on System.Object

 
Type Design : Do as little as possible now (but no less) to ensure room for extensibility in the future
Abstract and Base classes
 - Prefer broad, shallow hierarchies (less than or equal to 2 additional levels rough rule)
 - Consider making base classes not constructible(that is, use abstract classes)
   - Make it clear what the class is for

Virtual Methods 
Example:
public class TheBase: Object {
      public override string ToString(){
               return "Hello from the Base";
      }
}
public class Derived: TheBase {
      public override string ToString(){
               return "Hello from Derived";
      }
}
What will be the output
Derived d = new Derived(); Console.WriteLine(d.ToString()); // Hello from derived
TheBase tb = d; Console.WriteLine(d.ToString()); // Hello from derived
Object o = tb; Console.WriteLine(o.ToString());  // Hello from derived

They all output "Hello from derived" why ?
  - Method call virtualizes at runtime
  - The static type doesn't matter
This is the danger and power of virtual methods
  - Danger: Owner of base classes cannot control what subclasses do
  - Power: Base class does not have to change as new subclasses are created 

Overriding: Follow the Contract
 - Don't change the semantics of member
 - All virtual members should define a contract

References to base types must work with derived types without knowing the difference

Interface Usage :

- Challenging to version over releases
- No common implementation
- Interfaces become sealed..
- The smaller, more focused the interface the better

Type dependency Management :

- Do not have upward dependencies
- Avoid horizontal dependencies

Consider placing library types higher on the dependency stack
Do not create abstractions unless you what you are doing


Test Driven Development

Write tests first, design later
Requires reusable API to be testable - consider designing for dependency injection
avoid heavy dependencies, consider inversion control

Naming Conventions: 
PascalCasing -
camelCasing -
Abbreviations, acronym, initialism and the like - Avoid them...

fxCop
fds
fxarch