理解了这一点，我们可以看到上面介绍的sumAccounts方法能以下面的方式实现：
public decimal SumAccounts(IEnumerable<Account> myAccounts) { return Enumerable.Sum(myAccounts, a => a.Balance); }事实上我们可能已经这样实现了这个方法，而不是问什么要有扩展方法。扩展方法本身只是C#的一个方便你无需继承、重新编译或者修改原始代码就可以给已存的在类型“添加”方法的方式。
扩展方法通过在文件开头添加using [namespace];引入到作用域。你需要知道你要找的扩展方法所在的名字空间。如果你知道你要找的是什么，这点很容易。
当C#编译器碰到一个对象的实例调用了一个方法，并且它在这个对象的类中找不到那个方法，它就会尝试在作用域中所有的扩展方法里找一个匹配所要求的类和方法签名的。如果找到了，它就把实例的引用当做第一个参数传给那个扩展方法，然后如果有其它参数的话，再把它们依次传入扩展方法。（如果C#编译器没有在作用域中找到相应的扩展方法，它会抛措。）
对C#编译器来说，扩展方法是个“语法糖”，使我们能把代码写得更清晰，更易于维护（多数情况下）。显然，前提是你知道它的用法，否则，它会比较容易让人迷惑，尤其是一开始。
应用扩展方法确实有优势，但也会让那些对它不了解或者认识不正确的开发者头疼，浪费时间。尤其是在看在线示例代码，或者其它已经写好的代码的时候。当这些代码产生编译错误（因为它调用了那些显然没在被调用类型中定义的方法），一般的倾向是考虑代码是否应用于所引用类库的其它版本，甚至是不同的类库。很多时间会被花在找新版本，或者被认为“丢失”的类库上。
在扩展方法的名字和类中定义的方法的名字一样，只是在方法签名上有微小差异的时候，甚至那些熟悉扩展方法的开发者也偶尔犯上面的错误。很多时间会被花在寻找“不存在”的拼写错误上。
在C#中，用扩展方法变得越来越流行。除了LINQ，在另外两个出自微软现在被广泛使用的类库Unity Application Block和Web API framework中，也应用了扩展方法，而且还有很多其它的。框架越新，用扩展方法的可能性越大。
当然，你也可以写你自己的扩展方法。但是必须意识到虽然扩展方法看上去和其它实例方法一样被调用，但这实际只是幻。事实上，扩展方法不能访问所扩展类的私有和保护成员，所以它不能被当做传统继承的替代品。
常见错误 #7: 对手头上的任务使用错误的集合类型C#提供了大量的集合类型的对象，下面只列出了其中的一部分：
Array,ArrayList,BitArray,BitVector32,Dictionary<K,V>,HashTable,HybridDictionary,List<T>,NameValueCollection,OrderedDictionary,Queue, Queue<T>,SortedList,Stack, Stack<T>,StringCollection,StringDictionary.
但是在有些情况下，有太多的选择和没有足够的选择一样糟糕，集合类型也是这样。数量众多的选择余地肯定可以保证是你的工作正常运转。但是你最好还是花一些时间提前搜索并了解一下集合类型，以便选择一个最适合你需要的集合类型。这最终会使你的程序性能更好，减少出错的可能。
如果有一个集合指定的元素类型（如string或bit）和你正在操作的一样，你最好优先选择使用它。当指定对应的元素类型时，这种集合的效率更高。
为了利用好C#中的类型安全，你最好选择使用一个泛型接口，而不是使用非泛型的借口。泛型接口中的元素类型是你在在声明对象时指定的类型，而非泛型中的元素是object类型。当使用一个非泛型的接口时，C#的编译器不能对你的代码进行类型检查。同样，当你在操作原生类型的集合时，使用非泛型的接口会导致C#对这些类型进行频繁的装箱(boxing)和拆箱(unboxing)操作。和使用指定了合适类型的泛型集合相比，这会带来很明显的性能影响。
另一个常见的陷阱是自己去实现一个集合类型。这并不是说永远不要这样做，你可以通过使用或扩展.NET提供的一些被广泛使用的集合类型来节省大量的时间，而不是去重复造轮子。 特别是，C#的C5 Generic Collection Library 和CLI提供了很多额外的集合类型，像持久化树形数据结构，基于堆的优先级队列，哈希索引的数组列表，链表等以及更多。
常见错误#8：遗漏资源释放CLR 托管环境扮演了垃圾回收器的角色，所以你不需要显式释放已创建对象所占用的内存。事实上，你也不能显式释放。C#中没有与C++ delete对应的运算符或者与C语言中free()函数对应的方法。但这并不意味着你可以忽略所有的使用过的对象。许多对象类型封装了许多其它类型的系统资源（例如，磁盘文件，数据连接，网络端口等等）。保持这些资源使用状态会急剧耗尽系统的资源，削弱性能并且最终导致程序出错。
尽管所有C#的类中都定义了析构方法，但是销毁对象（C#中也叫做终结器）可能存在的问题是你不确定它们时候会被调用。他们在未来一个不确定的时间被垃圾回收器调用（一个异步的线程，此举可能引发额外的并发）。试图避免这种由垃圾回收器中GC.Collect()方法所施加的强制限制并非一种好的编程实践，因为可能在垃圾回收线程试图回收适宜回收的对象时，在不可预知的时间内致使线程阻塞。
这并意味着最好不要用终结器，显式释放资源并不会导致其中的任何一个后果。当你打开一个文件、网络端口或者数据连接时，当你不再使用这些资源时，你应该尽快的显式释放这些资源。
资源泄露几乎在所有的环境中都会引发关注。但是，C#提供了一种健壮的机制使资源的使用变得简单。如果合理利用，可以大增减少泄露出现的机率。NET framework定义了一个IDisposable接口，仅由一个Dispose()构成。任何实现IDisposable的接口的对象都会在对象生命周期结束调用Dispose()方法。调用结果明确而且决定性的释放占用的资源。
如果在一个代码段中创建并释放一个对象，却忘记调用Dispose()方法，这是不可原谅的，因为C#提供了using语句以确保无论代码以什么样的方式退出，Dispose()方法都会被调用（不管是异常，return语句，或者简单的代码段结束)。这个using和之前提到的在文件开头用来引入名字空间的一样。它有另外一个很多C#开发者都没有察觉的，完全不相关的目的，也就是确保代码退出时，对象的Dispose()方法被调用：
using (FileStream myFile = File.OpenRead("foo.txt")) { myFile.Read(buffer, 0, 100); }在上面示例中使用using语句，你就可以确定myFile.Dispose()方法会在文件使用完之后被立即调用，不管Read()方法有没有抛异常。
常见错误 #9: 回避异常C#在运行时也会强制进行类型检查。相对于像C++这样会给错误的类型转换赋一个随机值的语言来说，C#这可以使你更快的找到出错的位置。然而，程序员再一次无视了C#的这一特性。由于C#提供了两种类型检查的方式，一种会抛出异常，而另一种则不会，这很可能会使他们掉进这个“坑”里。有些程序员倾向于回避异常，并且认为不写 try/catch 语句可以节省一些代码。
例如，下面演示了C#中进行显示类型转换的两种不同的方式：
// 方法 1: // 如果 account 不能转换成 SavingAccount 会抛出异常 SavingsAccount savingsAccount = (SavingsAccount)account; // 方法 2: // 如果不能转换，则不会抛出异常，相反，它会返回 null SavingsAccount savingsAccount = account as SavingsAccount;很明显，如果不对方法2返回的结果进行判断的话，最终很可能会产生一个 NullReferenceException 的异常，这可能会出现在稍晚些的时候，这使得问题更难追踪。对比来说，方法1会立即抛出一个 InvalidCastExceptionmaking，这样，问题的根源就很明显了。
此外，即使你知道要对方法2的返回值进行判断，如果你发现值为空，接下来你会怎么做？在这个方法中报告错误合适吗？如果类型转换失败了你还有其他的方法去尝试吗？如果没有的话，那么抛出这个异常是唯一正确的选择，并且异常的抛出点离其发生点越近越好。
下面的例子演示了其他一组常见的方法，一种会抛出异常，而另一种则不会：
int.Parse(); // 如果参数无法解析会抛出异常 int.TryParse(); // 返回bool值表示解析是否成功 IEnumerable.First(); // 如果序列为空，则抛出异常 IEnumerable.FirstOrDefault(); // 如果序列为空则返回 null 或默认值有些程序员认为“异常有害”，所以他们自然而然的认为不抛出异常的程序显得更加“高大上”。虽然在某些情况下，这种观点是正确的，但是这种观点并不适��于所有的情况。
举个具体的例子，某些情况下当异常产生时，你有另一个可选的措施（如，默认值），那么，选用不抛出异常的方法是一个比较好的选择。在这种情况下，你最好像下面这样写：
if (int.TryParse(myString, out myInt)) { // use myInt } else { // use default value }而不是这样：
try { myInt = int.Parse(myString); // use myInt } catch (FormatException) { // use default value }但是，这并不说明 TryParse 方法更好。某些情况下适合，某些情况下则不适合。这就是为什么有两种方法供我们选择了。根据你的具体情况选择合适的方法，并记住，作为一个开发者，异常是完全可以成为你的朋友的。
