改善c#程序建议集1

1 C#中dynamic的正确用法
 
dynamic是FrameWork4.0的新特性。dynamic的出现让C#具有了弱语言类型的特性。编译器在编译的时候不再对类型进行检查，编译期默认dynamic对象支持你想要的任何特性。比如，即使你对GetDynamicObject方法返回的对象一无所知，你也可以像如下那样进行代码的调用，编译器不会报错：

dynamic dynamicObject = GetDynamicObject();           
Console.WriteLine(dynamicObject.Name);           
Console.WriteLine(dynamicObject.SampleMethod());

说到正确用法，那么首先应该指出一个错误用法：

常有人会拿var这个关键字来和dynamic做比较。实际上，var和dynamic完全是两个概念，根本不应该放在一起做比较。var实际上是编译期抛给我们的“语法糖”，一旦被编译，编译期会自动匹配var 变量的实际类型，并用实际类型来替换该变量的申明，这看上去就好像我们在编码的时候是用实际类型进行申明的。而dynamic被编译后，实际是一个object类型，只不过编译器会对dynamic类型进行特殊处理，让它在编译期间不进行任何的类型检查，而是将类型检查放到了运行期。
这从visual studio的编辑器窗口就能看出来。以var声明的变量，支持“智能感知”，因为visual studion能推断出var类型的实际类型，而以dynamic声明的变量却不支持“智能感知”，因为编译器对其运行期的类型一无所知。对dynamic变量使用“智能感知”，会提示“此操作将在运行时解析”。
关于dynamic变量是一个object变量这一点，可以通过IL代码得到验证，这里不再贴出IL代码。当然，编译器也对dynamic声明进行了处理，以区别直接object变量。
dynamic是做为简化互操作性而被MSDN中大肆渲染，我感觉正是基于这一点，才被部分开发人员误解：因为很多开发人员不会接触COM+、OFFICE二次开发之类的编码，所以急需要一个dynamic的应用理由。那么，在日常开发中，我认为dynamic很有价值的一点是：

dynamic可以简化反射。

以前我们这样使用反射：

public class DynamicSample  
{   
    public string Name { get; set; }      
    public int Add(int a, int b)       
    {           
        return a + b;       
    }  

}          

DynamicSample dynamicSample = new DynamicSample();   //create instance为了简化演示，我没有使用反射          
var addMethod = typeof(DynamicSample).GetMethod("Add");          
int re = (int)addMethod.Invoke(dynamicSample, new object[] { 1, 2 });
现在，我们有了简化的写法：
dynamic dynamicSample2 = new DynamicSample();          
int re2 = dynamicSample2.Add(1, 2);

我们可能会对这样的简化不以为然，毕竟看起来代码并没有减少多少，但是，如果考虑到效率兼优美两个特性，那么dynamic的优势就显现出来了。编译器对dynamic进行了优化，比没有经过缓存的反射效率快了很多。如果非要比较，可以将上面两者的代码（调用Add方法部分）运行1000000就可以得出结论。

-----------
在C#中选择正确的集合进行编码
 
要选择正确的集合，我们首先要了解一些数据结构的知识。所谓数据结构，就是相互之间存在一种或多种特定关系的数据元素的集合。结合下图，我们看一下对集合的分类。

集合分类

在上图中，可以看到，集合总体上分为线性集合和非线性集合。线性集合指元素具有唯一的前驱和后驱的数据结构类型。非线性集合是指具有多个前驱或后驱的数据结构类型，如：树、图。在FCL中，非线性集合实现的比较少，所以我们将会更多的讨论线性集合。

clip_image004 注意：由于类型安全、转型效率等方面的原因，本建议将只讨论泛型集合。

线性集合按存储方式，又分为直接存储和顺序存储。所谓直接存储是指：该类型的集合数据元素可以直接通过下标（也即index）来访问，在C#中有三种形式：Array（包括数组和List<T>），string，struct。直接存储结构的优点是：向数据结构中添加元素是很高效的，只要直接放在数据末尾的第一个空位上就可以了。它的缺点是：向集合插入元素将会变得低效，它需要给插入的元素腾出位置并顺序移动后面的元素。

string和structs虽然是直接存储结构，但它们与一般的集合定义有很大的不同，所以也不在本建议讨论之中。在直接存储的数据结构中，需要区分的是数组和List<T>的选择。再次强调一下：如果集合的数目固定并且不涉及到转型，使用数组效率高，否则就使用List<T>。顺序存储结构，也即线性表。线性表的大小可动态的扩大和缩小，它在一片连续的区域中存储数据元素。线性表不能按照索引进行查找，它通过对地址的引用来搜索元素，为了找到某个元素，它必须遍历所有元素，直到找到对应的元素为止。所以线性表的优点是插入和删除数据效率高，而缺点是查找的效率相对来说低一些。

线性表又可以分为队列、栈以及索引群集，在C#中，分别表现为：Queue<T>，Stack<T>，索引群集又进一步泛化为字典类型Dictionary< TKey, TValue >和双向链表LinkedList<T>。

队列Queue<T>遵循的是先入先出模式，它在集合末尾添加元素，在集合起始删除元素，

队列操作

根据队列的特点，可以用来处理并发命令等场景：将所有客户端的命令先入队，由专门的工作线程来执行队列的命令。在分布式中的消息队列就是一个典型的队列应用实例。

栈Stack<T>遵循的是后入先出模式，它在集合末尾添加元素，同时也在集合末尾删除元素，

栈操作

字典Dictionary<TKey, TValue>存储的是键值对，值在基于键的散列码的基础上进行存储。字典类对象由包含集合元素的存储桶组成，每一存储桶与基于该元素的键的哈希值关联。如果需要根据键进行值的查找，使用Dictionary<TKey, TValue>将会使搜索和检索更会快捷。

双向链表LinkedList<T>是一个类型为LinkedListNode的元素对象的集合。当我们在集合中觉得插入和删除数据很慢的时候，我们可以考虑使用链表。如果我们使用LinkedList<T>，我们会发现此类型并没有其它集合普遍具有的Add方法，取而代之的是AddAfter、AddBefore、AddFirst、AddLast等方法。双向链表中的每个节点都向前指向Previous节点，向后指向Next节点。

以上讨论了线性集合，在FCL中，非线性集合实现的不多。非线性集合分为层次集合和组集合。层次集合，如树，在FCL中就没有实现。组集合，又分为集和图。集在FCL中实现为HashSet<T>，而图在FCL中也没有对应实现。集的概念在本意上是指存放在集合中的元素是无序的且不能重复的。下图演示了集的用途：
 

集操作

除了上面我们提到的集合类型，还有其他几个要掌握的集合类型，它们是在实际应用中发展出来的对以上基础类型的扩展：SortedList<T>，SortedDictionary<TKey, TValue>，SortedSet<T>。它们所扩展的对应类为List<T>，Dictionary<TKey,TValue>，HashSet<T>，作用是将原本无序排列的元素，变为有序排列。

除了排序上的需求增加了上面3个集合类，在命名空间System.Collections.Concurrent下，还涉及几个多线程集合类。它们主要是：ConcurrentBag<T>对应List<T>，ConcurrentDictionary<TKey, TValue>对应Dictionary<TKey, TValue>，ConcurrentQueue<T>对应Queue<T>，ConcurrentStack<T>对应Stack<T>。如果我们的集合被用于多线程应用中，可以使用这几个集合类型。关于集合的线程安全性，可以进一步查看MSDN。

本建议到此为止已经介绍了FCL中的大部分泛型集合类，为了对它们有更好的了解，最后我们给出一个主要集合类的类图。实际工作中，应该根据需要选择合适的集合类。

-------在线程同步中使用信号量-------
 
所谓线程同步，就是多个线程之间在某个对象上执行等待（也可理解为锁定该对象），直到该对象被解除锁定。C#中对象的类型分为引用类型和值类型。CLR在这两种类型上的等待是不一样的。我们可以简单的理解为在CLR中，值类型是不能被锁定的，也即：不能在一个值类型对象上执行等待。而在引用类型上的等待机制，则分为两类：锁定和信号同步。

锁定，使用关键字lock和类型Monitor。两者没有实质区别，前者其实是后者的语法糖。这是最常用的同步技术；

本建议我们讨论的是信号同步。信号同步机制中涉及的类型都继承自抽象类WaitHandle，这些类型有EventWaitHandle（类型化为AutoResetEvent、ManualResetEvent）和Semaphore以及Mutex。

EventWaitHandle（子类为AutoResetEvent、ManualResetEvent）和Semaphore以及Mutex都继承自WaitHandle，所以它们底层的原理是一致的，维护的都是一个系统内核句柄。不过我们仍需简单的区分下这三类类型。

EventWaitHandle，维护一个由内核产生的布尔类型对象（我们称之为“阻滞状态”），如果其值为false，那么在它上面等待的线程就阻塞。可以调用类型的Set方法将其值设置为true，解除阻塞。EventWaitHandle类型的两个子类AutoResetEvent和ManualResetEvent，它们的区别并不大，本建议接下来会针对它们阐述如何正确使用信号量。

Semaphore，维护一个由内核产生的整型变量，如果其值为0，则在它上面等待的线程就阻塞，其值大于0，就解除阻塞，同时，每解除阻塞一个线程，其值就减1。

EventWaitHandle和Semaphore提供的都是单应用程序域内的线程同步功能，Mutex则不同，它为我们提供了跨应用程序域阻塞和解除阻塞线程的能力。

1：使用信号机制提供线程同步的一个简单的例子

使用信号机制提供线程同步的一个简单的例子如下：

AutoResetEvent autoResetEvent = new AutoResetEvent(false);     
private void buttonStartAThread_Click(object sender, EventArgs e)       
{           
    Thread tWork = new Thread(() =>{                   
    label1.Text = "线程启动..." + Environment.NewLine;                   
    label1.Text += "开始处理一些实际的工作" + Environment.NewLine;                    //省略工作代码                  
    label1.Text += "我开始等待别的线程给我信号，才愿意继续下去" + Environment.NewLine;                   
    autoResetEvent.WaitOne();                   
    label1.Text += "我继续做一些工作，然后结束了！";                    //省略工作代码              
    });          
    tWork.IsBackground = true;          
    tWork.Start();      
}      

private void buttonSet_Click(object sender, EventArgs e)       
{          
    //给在autoResetEvent上等待的线程一个信号           
    autoResetEvent.Set();      
}
这是一个简单的Winform窗体程序，其中一个按钮负责开启一个新的线程，还有一个按钮负责给刚开启的那个线程发送信号。现在详细解释这里面发生的事情。

AutoResetEvent autoResetEvent = new AutoResetEvent(false);

这段代码创建了一个同步类型对象autoResetEvent，它设置自己的默认阻滞状态是false。这意味着任何在它上面进行等待的线程将会被阻滞。所谓进行等待，就是在线程中应用：

autoResetEvent.WaitOne();

这说明tWork开始在autoResetEvent上等待任何其它地方给它的信号。信号来了，则tWork开始继续工作，否则就一直等着（即阻滞）。接下来我们看到在主线程中（本例中即UI线程，它相对线程tWork来说，就是一个“另外的线程”）：

autoResetEvent.Set();

主线程通过上面这句代码负责向在autoResetEvent上等待的线程tWork上下文发送信号，即将tWork的阻滞状态设置为true。tWork接收到这个信号，开始继续工作。
这个例子相当简单，但是已经完整说明了信号机制的工作原理。

2：AutoResetEvent和ManualResetEvent的区别

AutoResetEvent和ManualResetEvent有这样的区别：前者在发送信号完毕后（即调用Set方法），自动将自己的阻滞状态设置为false，而后者需要进行手动设定。可以通过一个例子来说明这种区别：

AutoResetEvent autoResetEvent = new AutoResetEvent(false);      

private void buttonStartAThread_Click(object sender, EventArgs e)      
{          
    StartThread1();           
    StartThread2();       
}       

private void StartThread1()      
{           

    Thread tWork1 = new Thread(() =>{               
    label1.Text = "线程1启动..." + Environment.NewLine;               
    label1.Text += "开始处理一些实际的工作" + Environment.NewLine;                //省略工作代码              
    label1.Text += "我开始等待别的线程给我信号，才愿意继续下去" + Environment.NewLine;              
    autoResetEvent.WaitOne();               
    label1.Text += "我继续做一些工作，然后结束了！";                //省略工作代码          
    });          

    tWork1.IsBackground = true;           
    tWork1.Start();      
}       

private void StartThread2()      
{           

    Thread tWork2 = new Thread(() =>          
    {               
        label2.Text = "线程2启动..." + Environment.NewLine;               
        label2.Text += "开始处理一些实际的工作" + Environment.NewLine;                //省略工作代码               
        label2.Text += "我开始等待别的线程给我信号，才愿意继续下去" + Environment.NewLine;               
        autoResetEvent.WaitOne();               
        label2.Text += "我继续做一些工作，然后结束了！";                //省略工作代码           
     });           
    tWork2.IsBackground = true;           
    tWork2.Start();      

}      

private void buttonSet_Click(object sender, EventArgs e)      
{          

    //给在autoResetEvent上等待的线程一个信号           
    autoResetEvent.Set();       
}
这个例子的本意是要让新起的两个工作线程tWork1和tWork2都阻滞起来，直到收到主线程的信号再继续工作。结果程序运行的结果是，只有一个工作线程继续工作，另外一个工作线程则继续保持阻滞状态。我想原因大家都已经想到了。由于AutoResetEvent在发送信号完毕就在内核中自动将自己的状态设置回false了，所以另外一个工作线程相当于根本没有收到主线程的信号。

要修正这个问题，可以使用ManualResetEvent。大家可以换成ManualResetEvent试一下。

3：应用实例

最后，再举一个需要用到线程同步的实际例子：模拟网络通信。客户端在运行过程中，服务器每隔一段的时间会给客户端发送心跳数据。实际工作中服务器和客户端会是网络中两台不同的终端，在这个例子中我们进行了简化。工作线程tClient模拟客户端，主线程（UI线程）模拟服务器端。客户端每3秒检测是否收到服务器的心跳数据，如果没有心跳数据，则显示网络连接断开。代码如下：

       

AutoResetEvent autoResetEvent = new AutoResetEvent(false);      

private void buttonStartAThread_Click(object sender, EventArgs e)      
{           

    Thread tClient = new Thread(() =>              
    {                   
        while (true)                  
        {                      

            //等3秒，3秒没有信号，显示断开                     
            //有信号，则显示更新                       
            bool re = autoResetEvent.WaitOne(3000);                       
            if (re)                       
            {                          
                label1.Text = string.Format("时间：{0}，{1}", DateTime.Now.ToString(), "保持连接状态");                      
            }                      
            else 
            {                          
                label1.Text = string.Format("时间：{0}，{1}", DateTime.Now.ToString(), "断开，需要重启");                      
            }                  
        }               

    });

    tClient.IsBackground = true;          
    tClient.Start();       
}       

private void buttonSet_Click(object sender, EventArgs e)      
{            //模拟发送心跳数据           
    autoResetEvent.Set();       
}

 

备注：由本问题带来一个Winform跨线程控件赋值和操作的问题。由于在本示例中不影响上面代码的运行，所以没有涉及，但是回复中有人提出来，所以提前简述一下Winform的线程模型：
在Winform框架中，有一个ISynchronizeInvoke接口，所有的UI元素（表现为Control）都继承了该接口。其中，接口中的InvokdRequired属性表示了当前线程是否是创建它的线程。接口中的Invoke和BeginInvoke方法负责将消息发送到消息队列中，这样，UI线程就能够正确处理它。
具体到代码中，对于夸线程控件赋值，可以采用下面的方法：

this.label1.BeginInvoke(new Action(()=>{        this.label1.Text = "跨线程中赋值";}));

------正确停止线程-----

 
开发者总尝试对自己的代码有更多的控制。“让那个还在工作的线程马上停止下来”就是诸多要求中的一种。然而事与愿违，这里面至少存在两个问题：

第一个问题是：正如线程不能立即启动一样，线程也并不能说停就停。无论采用何种方式通知工作线程需要停止，工作线程都会忙完手头最紧要的活，然后在它觉得合适的时候退出。以最传统的Thread.Abort方法为例，如果线程当前正在执行的是一段非托管代码，那么CLR就不会抛出ThreadAbortException，只有当代码继续回到CLR中时，才会引发ThreadAbortException。当然，即便是在CLR环境中，ThreadAbortException也不会立即引发。

其次，正确停止线程，不在于调用者采取了什么行为（如最开始的Thread.Abort()方法），而更多依赖于工作线程是否能主动响应调用者的停止请求。大体机制是，如果线程需要被停止，那么线程自身就得负责开放给调用者这样的接口：Cancled，然后线程在工作的同时，还得以某种频率检测Cancled标识，若检测到Cancled，线程自己负责退出。

FCL现在为我们提供了标准的取消模式：协作式取消（Cooperative Cancellation）。协作式取消的机制就是上文提到的机制。下面是一个最基础的协作式取消的样例：

CancellationTokenSource cts = new CancellationTokenSource();          

Thread t = new Thread(() =>              
{                   
    while (true)                  
    {                      
        if (cts.Token.IsCancellationRequested)                      
        {                           
            Console.WriteLine("线程被终止！");                          
            break;                      
        }                       
        Console.WriteLine(DateTime.Now.ToString());                       
        Thread.Sleep(1000);                  
    }              
});          
t.Start();           
Console.ReadLine();           
cts.Cancel();
调用者使用CancellationTokenSource的Cancle方法通知工作线程退出。工作线程则以大致1000毫秒的频率一边工作，一边检查是否有外界传入进来的Cancel信号。若有这样的信号，则负责退出。可以看到，在正确停止线程的机制中，真正起到主要作用的是线程本身。样例中的工作代码比较简单，不过也足以说明问题。更复杂的计算式的工作，也应该以这样的一种方式，妥善而正确地处理退出。

协作式取消中的关键类型是CancellationTokenSource。它有一个关键属性Token，Token是一个名为CancellationToken的值类型。CancellationToken继而进一步提供了布尔值的属性IsCancellationRequested作为需要取消工作的标识。CancellationToken还有一个方法尤其值得注意，那就是Register方法。它负责传递一个Action委托，在线程停止的时候被回调，使用方法如：

cts.Token.Register(() =>          
{               
    Console.WriteLine("工作线程被终止了。");           
});
本建议中的例子使用Thread进行了演示，使用ThreadPool也是一样的模式，这里就不再赘述。后面我们还会讲到任务Task，它依赖于CancellationTokenSource和CancellationToken完成了所有的取消控制。

--------C#中标准Dispose模式的实现--------
 
需要明确一下C#程序（或者说.NET）中的资源。简单的说来，C#中的每一个类型都代表一种资源，而资源又分为两类：
托管资源：由CLR管理分配和释放的资源，即由CLR里new出来的对象；
非托管资源：不受CLR管理的对象，windows内核对象，如文件、数据库连接、套接字、COM对象等；
毫无例外地，如果我们的类型使用到了非托管资源，或者需要显式释放的托管资源，那么，就需要让类型继承接口IDisposable。这相当于是告诉调用者，该类型是需要显式释放资源的，你需要调用我的Dispose方法。
不过，这一切并不这么简单，一个标准的继承了IDisposable接口的类型应该像下面这样去实现。这种实现我们称之为Dispose模式：

public class SampleClass : IDisposable  
{       
    //演示创建一个非托管资源       
    private IntPtr nativeResource = Marshal.AllocHGlobal(100);      
    //演示创建一个托管资源       
    private AnotherResource managedResource = new AnotherResource();       
    private bool disposed = false;      
    /// <summary>      
    /// 实现IDisposable中的Dispose方法       
    /// </summary>       
    public void Dispose()       
    {          

        //必须为true          
        Dispose(true);           
        //通知垃圾回收机制不再调用终结器（析构器）           
        GC.SuppressFinalize(this);      
    }      

    /// <summary>      
    /// 不是必要的，提供一个Close方法仅仅是为了更符合其他语言（如C++）的规范      
    /// </summary>      
    public void Close()       
    {          
        Dispose();       
    }      

    /// <summary>       
    /// 必须，以备程序员忘记了显式调用Dispose方法      
    /// </summary>       
    ~SampleClass()      
    {           
        //必须为false           
        Dispose(false);       
    }      

    /// <summary>      
    /// 非密封类修饰用protected virtual       
    /// 密封类修饰用private      
    /// </summary>      
    /// <param name="disposing"></param>      
    protected virtual void Dispose(bool disposing)      
    {           
        if (disposed)          
        {               
            return;           
        }          

        if (disposing)           
        {               
            // 清理托管资源              
            if (managedResource != null)               
            {                   
                managedResource.Dispose();                   
                managedResource = null;              
            }           
        }           

        // 清理非托管资源          
        if (nativeResource != IntPtr.Zero)           
        {               
            Marshal.FreeHGlobal(nativeResource);               
            nativeResource = IntPtr.Zero;          
        }           

        //让类型知道自己已经被释放           
        disposed = true;      
    }       

    public void SamplePublicMethod()      
    {           
        if (disposed)           
        {              
            throw new ObjectDisposedException("SampleClass", "SampleClass is disposed");          
        }            //省略      
    }   
}
在Dispose模式中，几乎每一行都有特殊的含义。

在标准的Dispose模式中，我们注意到一个以~开头的方法：

/// <summary>       
/// 必须，以备程序员忘记了显式调用Dispose方法       
/// </summary>       
~SampleClass()       
{           
    //必须为false           
    Dispose(false);       
}
这个方法叫做类型的终结器。提供终结器的全部意义在于：我们不能奢望类型的调用者肯定会主动调用Dispose方法，基于终结器会被垃圾回收器调用这个特点，终结器被用做资源释放的补救措施。
一个类型的Dispose方法应该允许被多次调用而不抛异常。鉴于这个原因，类型内部维护了一个私有的布尔型变量disposed：

private bool disposed = false;

在实际处理代码清理的方法中，加入了如下的判断语句：

 if (disposed)          
{               
    return;           
}           
//省略清理部分的代码，并在方法的最后为disposed赋值为true           
disposed = true;
这意味着类型如果被清理过一次，则清理工作将不再进行。

应该注意到：在标准的Dispose模式中，真正实现IDisposable接口的Dispose方法，并没有实际的清理工作，它实际调用的是下面这个带布尔参数的受保护的虚方法：

/// <summary>       
/// 非密封类修饰用protected virtual       
/// 密封类修饰用private       
/// </summary>       
/// <param name="disposing"></param>       

protected virtual void Dispose(bool disposing)       
{           
//省略代码       
}
之所以提供这样一个受保护的虚方法，是为了考虑到这个类型会被其他类继承的情况。如果类型存在一个子类，子类也许会实现自己的Dispose模式。受保护的虚方法用来提醒子类必须在实现自己的清理方法的时候注意到父类的清理工作，即子类需要在自己的释放方法中调用base.Dispose方法。
还有，我们应该已经注意到了真正撰写资源释放代码的那个虚方法是带有一个布尔参数的。之所以提供这个参数，是因为我们在资源释放时要区别对待托管资源和非托管资源。
在供调用者调用的显式释放资源的无参Dispose方法中，调用参数是true：

public void Dispose()       
{           
    //必须为true           
    Dispose(true);           
    //其他省略       
}
这表明，这个时候代码要同时处理托管资源和非托管资源。

在供垃圾回收器调用的隐式清理资源的终结器中，调用参数是false：

~SampleClass()       
{           
    //必须为false           
    Dispose(false);       
}
这表明，隐式清理时，只要处理非托管资源就可以了。

那么，为什么要区别对待托管资源和非托管资源。在认真阐述这个问题之前，我们需要首先弄明白：托管资源需要手动清理吗？不妨先将C#中的类型分为两类，一类继承了IDisposable接口，一类则没有继承。前者，我们暂时称之为非普通类型，后者我们称之为普通类型。非普通类型因为包含非托管资源，所以它需要继承IDisposable接口，但是，这个包含非托管资源的类型本身，它是一个托管资源。所以说，托管资源需要手动清理吗？这个问题的答案是：托管资源中的普通类型，不需要手动清理，而非普通类型，是需要手动清理的（即调用Dispose方法）。
Dispose模式设计的思路基于：如果调用者显式调用了Dispose方法，那么类型就该按部就班为自己的所以资源全部释放掉。如果调用者忘记调用Dispose方法，那么类型就假定自己的所有托管资源（哪怕是那些上段中阐述的非普通类型）全部交给垃圾回收器去回收，而不进行手工清理。理解了这一点，我们就理解了为什么Dispose方法中，虚方法传入的参数是true，而终结器中，虚方法传入的参数是false。
注意：我们提到了需要及时释放资源，却并没有进一步细说是否需要及时让引用等于null这一点。有一些人认为等于null可以帮助垃圾回收机制早点发现并标识对象是垃圾。其他人则认为这没有任何帮助。下一篇“引用类型赋值为null与加速垃圾回收”我们再细说这一点。

--------非用ICloneable不可的理由------

好吧，我承认，这是一个反标题，实际的情况是：我找不到一个非用ICloneable不可的理由。事实上，接口ICloneable还会带来误解，因为它只有一个Clone方法。
我们都知道，对象的拷贝分为：浅拷贝和深拷贝。ICloneable仅有一个Clone方法使我们无法从命名的角度去区分到底是哪个拷贝。
浅拷贝：将对象的字段复制到副本（新的对象）中，同时将字段的值也赋值过去，但是引用类型字段只复制引用，而不是引用类型本身。这意味着，源对象引用类型字段的值改变了，会影响到副本中对应的值也改变；
深拷贝：将对象的字段复制到副本（新的对象）中，无论是值类型还是引用类型字段，都会复制类型本身及类型的值。这意味着，源对象引用类型字段的值改变了，不会影响到副本中对应的值；
于是问题来了，如果类型继承了ICloneable接口，那么类型中的Clone是浅拷贝还是深拷贝。微软的解释是：你既可以在Clone方法中实现浅拷贝，也可以实现深拷贝。那么，为什么不直接提供两个方法呢？比如：DeepClone或者ShallowClone。还是，一般类型的创建，只要实现了浅拷贝就不需要再实现深拷贝（或者反之），所以我们没有必要提供两个方法。

下面是一个既实现了浅拷贝也实现深拷贝的例子：

代码

[Serializable]
class Employee : ICloneable
{
    public string IDCode { get; set; }
    public int Age { get; set; }
    public Department Department { get; set; }

    #region ICloneable 成员

    public object Clone()
    {
        return this.MemberwiseClone();
    }

    #endregion

    public Employee DeepClone()
    {
        using (Stream objectStream = new MemoryStream())
        {
            IFormatter formatter = new BinaryFormatter();
            formatter.Serialize(objectStream, this);
            objectStream.Seek(0, SeekOrigin.Begin);
            return formatter.Deserialize(objectStream) as Employee;
        }
    }

    public Employee ShallowClone()
    {
        return Clone() as Employee;
    }
}

 

实际上，ICloneable还带来一个问题（该问题Bill Wagner在Effcitive c#中曾经论述过），那就是：如果类型继承自ICloneable，但是同时它不是一个Sealed类型的话，它们的子类的默认Clone方法会带来BUG（子类的Clone方法会返回父类的副本，而不是子类本身）。这会逼迫所有的子类都重写Clone方法；
ICloneable的Clone方法的另一个问题是：它不是类型安全的，它返回的是Object，使用它的时候还设计到转型的问题，而我们自己实现的Clone方法却可以规避掉这个问题（如上文代码）。
综上所述，类型确实没必要继承ICloneable接口，如果类型本身需要实现拷贝功能，直接公开方法就行。如果在应用中你觉得确实必须实现这个接口的，来指正我吧。

--------引用类型赋值为null与加速垃圾回收-------
 
在标准的Dispose模式中（见前一篇博客“C#中标准Dispose模式的实现”），提到了需要及时释放资源，却并没有进一步细说让引用等于null是否有必要。
有一些人认为等于null可以帮助垃圾回收机制早点发现并标识对象是垃圾。其他人则认为这没有任何帮助。是否赋值为null的问题首先在方法的内部被人提起。现在，为了更好的阐述提出的问题，我们来撰写一个Winform窗体应用程序。如下：

private void button1_Click(object sender, EventArgs e)       
{           
    Method1();           
    Method2();       
}       

private void button2_Click(object sender, EventArgs e)       
{           
    GC.Collect();       
}               

private void Method1()      
{           
    SimpleClass s = new SimpleClass("method1");          
    s = null;          
    //其它无关工作代码（这条注释源于回应回复的朋友的质疑）      
}       

private void Method2()      
{           
    SimpleClass s = new SimpleClass("method2");      
}   
 

class SimpleClass 
{       
    string m_text;       
    public SimpleClass(string text)       
    {          
        m_text = text;       
    }      
    ~SimpleClass()      
    {           
        MessageBox.Show(string.Format("SimpleClass Disposed, tag:{0}", m_text));      
    }   
}
先点击按钮1，再点击按钮2释放，我们会发现：

q 方法Method2中的对象先被释放，虽然它在Method1之后被调用；
q 方法Method2中的对象先被释放，虽然它不像Method1那样为对象引用赋值为null；
在CLR托管应用程序中，存在一个“根”的概念，类型的静态字段、方法参数以及局部变量都可以作为“根”存在（值类型不能作为“根”，只有引用类型的指针才能作为“根”）。
上面的两个方法中各自的局部变量，在代码运行过程中会在内存中各自创建一个“根”.在一次垃圾回收中，垃圾回收器会沿着线程栈上行检查“根”。检查到方法内的“根”时，如果发现没有任何一个地方引用了局部变量，则不管是否为变量赋值为null，都意味着该“根”已经被停止掉。然后垃圾回收器发现该根的引用为空，同时标记该根可被释放，这也表示着Simple类型对象所占用的内存空间可被释放。所以，在上面的这个例子中，为s指定为null丝毫没有意义（方法的参数变量也是这种情况）。

更进一步的事实是，JIT编译器是一个经过优化的编译器，无论我们是否在方法内部为局部变量赋值为null，该语句都会被忽略掉：
s = null;在我们将项目设置为Release模式下，上面的这行代码将根本不会被编译进运行时内。
正式由于上面这样的分析，很多人认为为对象赋值为null完全没有必要。但是，在另外一种情况下，却要注意及时为变量赋值为null。那就是类型的静态字段。为类型对象赋值为null，并不意味着同时为类型的静态字段赋值为null：

private void button1_Click(object sender, EventArgs e)       
{           
    SimpleClass s = new SimpleClass("test");      
}       

private void button2_Click(object sender, EventArgs e)      
{           
    GC.Collect();       
}

class SimpleClass  
{       

    static AnotherSimpleClass asc = new AnotherSimpleClass();       
    string m_text;       
    public SimpleClass(string text)       
    {          
        m_text = text;       
    }              
    ~SimpleClass()       
    {           
        //asc = null;           
        MessageBox.Show(string.Format("SimpleClass Disposed, tag:{0}", m_text));      
    }  
}   

class AnotherSimpleClass  
{      
    ~AnotherSimpleClass()      
    {           
        MessageBox.Show("AnotherSimpleClass Disposed");      

    }   
}
以上代码运行的结果使我们发现，当执行垃圾回收，当类型SampleClass对象被回收的时候，类型的静态字段asc并没有被回收。

必须要将SimpleClass的终结器中注释的那条代码启用。
字段asc才能被正确释放（注意，要点击两次释放按钮。这是因为一次垃圾回收会仅仅首先执行终结器）。之所以静态字段不被释放（同时赋值为null语句也不会像局部变量那样被运行时编译器优化掉），是因为类型的静态字段一旦被创建，该“根”就一直存在。所以垃圾回收器始终不会认为它是一个垃圾。非静态字段不存在这个问题。将asc改为非静态，再次运行上面的代码，会发现asc随着类型的释放而被释放。
上文代码的例子中，让asc=null是在终结器中完成的，实际工作中，一旦我们感觉到自己的静态引用类型参数占用内存空间比较大，并且使用完毕后不再使用，则可以立刻将其赋值为null。这也许并不必要，但这绝对是一个好习惯。试想一下在一个大系统中，那些时不时在类型中出现的静态变量吧，它们就那样静静地呆在内存里，一旦被创建，就永远不离开，越来越多，越来越多……。

-------------