Effective C# Item 35: Prefer Overrides to Event Handlers

      许多.net类库中的类都提供了两种不同的处理事件句柄的方法。既可以为其添加事件，也可以重写其基类的事件抽象方法。为什么要为同一件事提供两种不同的方法呢？这是为了对应不同的情况。在实现派生类的时候，更好的选择是重写基类中的抽象方法。

      假设我们现在正在编写一个windows应用程序，这个程序需要对鼠标按键按下的事件做出响应。在自定义的Form类中，我们可以选择重写OnMouseDown()事件：

    public class MyForm : Form
    {
        protected override void OnMouseDown(MouseEventArgs e)
        {
            try
            {
                HandleMouseDown(e);
            }
            catch
            {
                //error
            }
            base.OnMouseDown(e);
        }
    }

      或者添加事件句柄：

    public class MyForm : Form
    {
        public MyForm()
        {
            this.MouseDown += new MouseEventHandler(MyForm_MouseDown);
        }
 
        void MyForm_MouseDown(object sender, MouseEventArgs e)
        {
            try
            {
                HandleMouseDown(e);
            }
            catch
            {
                //error
            }
        }
    }

      这里推荐使用第一种方法。一旦事件句柄抛出异常，不会再有其他的事件句柄被调用。这避免了一些错误代码继续被调用而引发的问题。通过重写受保护的虚方法，我们的句柄可以第一个被调用。基类中虚函数负责其他相关句柄的调用。这意味着如果需要调用那些事件句柄(一般来说是需要的)，就要调用基类的虚函数。在有些特殊情况下我们需要替换基类的默认行为，可能不需要调用任何原有的事件句柄。虽然我们不能保证所有的事件句柄都被执行，因为其可能会抛出异常，但是我们可以保证派生类的行为是正确的。

      使用override比添加事件句柄高效的多。在Item 22中展示了System.Windows.Forms.Control类是如何存储句柄时间并将其对应到每一个事件的。这种事件机制由于要检查事件句柄将造成更多的消耗。事件句柄列表中的每个方法都需要执行。相比重写虚方法，通过事件处理会消耗更多的时间。

      如果这还不足以说服你，咱们可以再回头看一下开始时候的代码。哪一种更清晰？重写虚方法只需要维护一个函数就可以达到检查和修改的目的。而事件机制需要两个维护点：事件句柄函数和事件绑定代码。其中任何一点都可能造成整体功能上的失败。一个函数显然要简单些。

      这些就是使用重写和不是事件句柄的理由。但是.net设计者之所以会提供事件也是有其理由的。他们不会做无用的工作。这种重写是针对派生类的。除此之外的情况我们必须使用事件机制。例如我们经常需要为Form添加一个按钮的点击事件。这个事件由按钮引发，在form中处理。当然我们可以搞一个自定义按钮，然后在里面重写点击的虚方法，但这太繁琐了，为了处理一个事件，需要创建一个自定义的按钮类，完全是在给自己找麻烦。而使用事件机制就非常的简单。这也是.net framework设计者在设计事件机制的一个理由。

      另外一个理由是事件的绑定是在运行期进行的。我们可以更加灵活的处理事件，在运行时为其绑定不同的事件。假设我们正在编写一个绘图程序，点击鼠标可能是画线的开始，也可能是选取某个对象。我们可以在使用者切换模式的时候来切换这些事件。而且，我们可以为同一个事件添加多个事件句柄。

      当我们创建派生类时，应当使用重写虚函数的方法来处理事件。这样便于维护也更加高效。其他情况则应该使用事件句柄。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录

 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 40: Match Your Collection to Your Needs

      如果要问 “哪种集合是最好的？”我的回答是：“视需要而定。”不同的集合有不同的功能特性，并且针对其行为的不同进行了优化。.Net Framework支持许多相似的集合：列表、数组、队列、栈等等。另外，C#支持多维数组，其性能特点不同于其它的一维数组或者交错数组。.Net Framework中还包含了很多专门化的集合，你可以回顾一下以前创建的程序中用到的那些集合。由于所有的集合都实现了ICollection接口，你可以非常快速的找到它们。在描述ICollection接口的文档中列出了所有实现这个接口的类。这二十多个类都是可供我们使用的集合。

      在创建集合时，你应当考虑最经常对这个集合执行哪些操作，这有助于选出适合你需要的正确的集合。另外，为了使程序更具弹性，你应当依赖于集合类所实现的接口编程，这样即使发现当初设想中使用的集合是不正确的，你仍然可以用其它的集合来代替它。

      在.Net Framework中有三种不同类型的集合：数组、类数组集合和基于哈希原理的集合容器。其中数组是最简单，一般来说也是速度最快的，那就让我们先从这里说起吧。数组是我们最常用的集合类型。

      一般来说当需要使用集合时，System.Array类，或者更恰当的说，一个指定类型的数组类应当是你的第一选择。选用数组最重要的原因就是数组是类型安全的。除C# 2.0中的泛型(参见本书第49项)外，其它集合储存的都是System.Object类型的引用。当我们声明数组时，编译器会为我们指定的类型创建一个特殊的System.Array的派生。例如下例中的声明将创建一个整型数组：

private int [] _numbers = new int[100];

      数组中储存的将是整数，而不是System.Object。这样的意义在于当我们添加、获取或者移除数组中的值类型的时候，可以避免装箱和拆箱操作所带来的效率上的损失(参见本书第17项)。上例中的初始化过程创建了一个可以储存100个整数的一维数组。数组所占用的内存单元都被置以0。值类型数组的初始值都是0，而引用类型数组的初始值都是null。我们可以通过索引来访问数组中的每一项。

int j = _numbers[9];

      除此之外，我们还可以使用foreach或者枚举器来遍历数组 

            foreach (int i in _numbers)
            {
                Console.WriteLine(i.ToString());
            }
            //或者
 

              IEnumerator it = _numbers.GetEnumerator();
            while (it.MoveNext())
            {
                int i = (int)it.Current;
                Console.WriteLine(i.ToString());
            }

      如果你需要储存单一序列的对象，你应当选择数组来储存他们。但是一般来说，我们的数据构成都是比较复杂的集合。这很容易让我们马上倒退回C语言风格转而使用交错数组――一种包含数组的数组。有时这正是我们需要的。在交错数组中外层集合的每个元素都是一个数组。

    public class MyClass
    {
        private int[][] _jagged;
        public MyClass()
        {
            _jagged = new int[5][];
            _jagged[0] = new int[10];
            _jagged[1] = new int[12];
            _jagged[2] = new int[7];
            _jagged[3] = new int[23];
            _jagged[4] = new int[5];
        }
    }

      外层数组内部存储的每个一维数组可以是不同大小的。当需要创建不同大小的数组的数组时，你可以使用交错数组。交错数组的缺点在于列方向遍历的效率低。例如现在要检查交错数组中每一行第三列的值，每检查一行，都需要对数组进行2次查找。在交错数组中，第0行第3列的元素和第1行第3列的元素之间并没有关联关系。只有多维数组才能高效的完成列方向上的遍历。以前C和C++的程序员使用一维数组来完成对将二维(或多维)数组的映射。对于以前的C和C++程序员来说，这样的代码是很清晰的：

double num = MyArray[ i * rowLength + j ];

      而其它人更喜欢这样写：

double num = MyArray[ i, j ];

      但是C和C++不支持多维数组，而C#支持。使用多维数组可以创建一个真实的多维结构，不论对于你还是编译器来说都会更加清晰。你可以使用类似于一维数组声明的标记来创建一个多维数组。

private int[,] _multi = new int[10, 10];

      上面的声明创建了一个二维数组，10×10的阵列共100个元素。在多维数组中每一个维度的长度都是恒定值。利用这个特性，编译器可以生成高效的初始化代码。而初始化一个交错数则组需要多次初始化声明。在早些的简单例子中可以看到，对于例子中的交错数组，你需要声明五次。交错数组越大、维数越多所需要的初始化代码也越庞大，你必须手工来完成这一切。然而对于多维数组来说，所需要的仅仅是在初始化声明时指定其维度。此外，多维数组还可以高效的初始化数组元素。对于值类型的数组来说，有效范围内的每个索引所对应的元素，都被初始化为一个值的容器。这些值的内容都是0。引用类型的数组的每个索引对应的都是null。对于数组的数组，其存储单元内部也是null。

      一般来说，多维数组中的遍历要比交错数组快的多，特别是列方向或斜线方向的遍历。编译器可以使用指针算法来处理数组中的任意一个维度。而对于交错数组来说，这需要在每个一维数组中搜索正确的值。

      多维数组可以充当任意的集合，在很多场合都能发挥作用。假设你要创建一个在棋盘上进行的游戏。你需要安排一个有64块区域的表格来做为棋盘：

private Square[,] _theBoard = new Square[8, 8];

      这样的初始化方式创建了储存这些Square类型的数组。假设Square是引用类型，由于这些Square类型本身还没有被创建，因此每个数组中存储的元素都是null。为了初始化这些元素，我们必须考虑到数组中的每一个维度。

    for (int i = 0; i < _theBoard.GetLength(0); i++)
    {
        for (int j = 0; j < _theBoard.GetLength(1); j++)
        {
            _theBoard[i, j] = new Square();
        }
    }

      但是在多维数组中，你拥有更加灵活的遍历元素方式。我们可以通过数组的索引来获取其中合法的元素：

Square sq = _theBoard[4, 4];

      如果你需要遍历整个集合，你可以使用迭代器

foreach(Square sq in _theBoard)
{
    sq.PaintSquare();
}

      与之对比的是如果我们使用交错数组：

foreach(Square[] row in _theBoard)
{
    foreach(Square sq in row)
    {
        sq.PaintSquare();
    }
}

      交错数组中增加每一个新的维度代表着需要声明一个新的foreach来完成遍历。而在多维数组中，一个foreach声明就可以生成检查每个维度是否越界和获取数组中元素的所有代码。foreach声明会生成特殊的代码来对数组的每个维度进行遍历。foreach循环所生成的代码等同于如下代码：

           for (int i = _theBoard.GetLowerBound(0); i < _theBoard.GetUpperBound(0); i++)
            {
                for (int j = _theBoard.GetLowerBound(1); j < _theBoard.GetUpperBound(1); j++)
                {
                    _theBoard[i, j].PaintSquare();
                }
            }

      这些代码看起来效率并不高，因为在循环内部调用了GetLowerBound和GetUpperBound方法，但是实际上这是最高效的结构。JIT编译器可以将数组的边界缓存起来，并且取消内部对数组越界判断的操作。

      数组类有两个主要的缺点，正是这两个缺点使得.Net Framework中其它的集合类型有了用武之地。第一个缺点影响数组的大小调整：数组不能动态的调整大小。如果你需要调整数组某一维度的大小，你就必须重新创建一个数组并从原数组中将所有已存在的元素拷贝至新数组。调整大小非常耗时：一个新的数组必须被分配空间，已有数组中的全部元素必须被拷贝到新数组中。尽管这种在托管堆上的拷贝和移动的代价已经不像C或者C++时代那样昂贵，但是依然会耗费时间。而更重要的是这种操作可能导致陈旧数据被应用。考虑下面的代码片断：

        private string[] _cities = new string[100];

        public void SetDataSource()
        {
            myListBox.DataSource = _cities;
        }

        public void AddCity(string cityName)
        {
            string[] temp = new string[_cities.Length + 1];
            _cities.CopyTo(temp, 0);
            temp[_cities.Length] = cityName;
            _cities = temp;
        }

      即便是AddCity方法被调用之后，列表框所使用的数据源仍然是_cities数组的老版本拷贝。新添加的城市永远不会显示在列表框之中。

      ArrayList类是构建在数组上的一种高层次抽象。ArrayList集合混合了一维数组和链表的特征。你可以在ArrayList中进行插入操作，也可以调整它的大小。ArrayList将其大部分职责都委托给其内部包含的数组，这意味着ArrayList类在功能特性上和Array类是非常相似的。当我们可以使用ArrayList来轻松的应对未知大小的集合，这也是ArrayList较Array而言的主要优点。ArrayList可以随时增长或缩减。虽然我们仍然需要付出拷贝和移动数组元素的代价，但是这些算法的代码是已经写好并经过测试的。由于ArrayList对象内部储存数据的数组是封装好的，也不会出现陈旧数据的问题：客户程序将指向ArrayList对象而不是内部数组。ArrayList集合是C++标准类库中的vector类在.Net Framework中的版本。

      队列和栈类在System.Array基础上提供了专门的接口。通过这些类的特定的接口实现了先进先出的队列和后进先出的栈。我们要始终牢记这些集合是使用其内部的一维数组来储存数据的。当我们改变它们的大小时同样会受到性能上的损失。

      .Net中不包含链表结构的集合。由于有高效的垃圾收集机制，表结构出场亮相的次数也减少了。如果你的确需要实现链表行为时，你有两种选择。如果你引起经常要添加或移除项目而使用列表时，你可以使用字典类简单的储存键，对于值则赋以null。当需要实现一个键/值的单链表时，你可以使用ListDictionary类。或者你可以使用HyBridDictionary类。当集合较小时，HyBridDictionary类会使用ListDictionary来应对，而对于较大的集合则选用HashTable。这几个集合和其它许多集合一起位于System.Collections.Specialized命名空间下。尽管如此，如果你为了实现某些用户指令的目的而使用链表结构的话，那么你完全可以使用ArrayList集合来代替它。尽管ArrayList内部是使用数组来进行存储的，但是它也可以完成在任意位置插入元素的功能。

      另外两种支持基于字典的集合是SortedList和Hashtable。它们都包含键/值对。SortedList会对键进行排序而Hashtable不会。Hashtable提供了对给定键的快速搜索，而SortedList提供了按键的顺序遍历元素的功能。Hashtable通过做为键的对象的哈希值来进行搜索，如果哈希键是足够高效的话，那么其每次搜索操作所耗费的时间是一个常数，即时间复杂度为0(1)。SortedList使用二分法来进行搜索，这种算法操作的时间复杂度为0(ln n)。

      最后我们来介绍一下BitArray类。顾名思义，这个类是用来存储二进制数据的。BitArray类使用一个整型的数组来储存数据。整型数组中的每个存储单元储存32个二进制值。这样做可以达到压缩的目的，但是同样也会降低性能。每次对BitArray进行get或者set操作都会引发对储存着目标数据和其它31个二进制数据的整数的操作。BitArray包含了一些方法来对其内部的值进行布尔型操作，例如：OR，XOR，AND和NOT。这些方法使用BitArray做为参数，可以被用来快速过滤BitArray中的多位二进制数。BitArray针对位操作做了专门的优化，应当使用它来存储那些经常进行做为掩码的二进制标记集合，而不应当使用一般的布尔型的数组来代替。

      除了Array类之外，在.Net Framework 1.x版本的C#中再也没有其它集合类是强类型的。它们储存的都是Object的引用。C#泛型中包含了一种新版本的拓扑结构，它能够以一种更加普遍化的方式被创建。泛型是创建类型安全集合的最好方法。你也可以通过现在的System.Collection命名空间中包含的抽象基类在非类型安全的集合上构建你自己的类型安全接口：CollectionBase和ReadOnlyCollectionBase提供了存储键/值集合的基类。DictionaryBase类使用的是哈希表的实现方法，他的功能特点和哈希表非常相似。

      当你的类包含集合时，你会希望为将它暴露给你的类用户。你有两种方法来达到这个目的：使用索引器或者实现IEnumerable接口。在本节开始的部分，我向你展示了数组如何通过[]标记来获取其中的项目，你也可以使用foreach来遍历数组中的项目。

      你可以为你的类创建多维索引器。这很类似于C++中重载操作符[]一样。就像C#中的数组一样，你可以创建多维的索引器：

        public int this[int x, int y]
        {
            get
            {
                return ComputeValue(x, y);
            }
        }

      添加索引功能通常意味着你的类型内部包含一个集合。而这也意味这你的类型应当支持IEnumerable接口。IEnumerable接口提供了一种标准的迭代遍历集合中所有元素的机制。

    public interface IEnumerable
    {
        IEnumerator GetEnumerator();
    }

      GetEnumerator方法返回一个实现了IEnumerator接口的对象。IEnumerator接口支持对集合的遍历：

    public interface IEnumerator
    {
        object Current { get;}
        bool MoveNext();
        void Reset();
    }

      除了IEnumerable接口外，如果你的类型要模拟一个数组，那么你还应当考虑IList和ICollection接口。如果你的类型要模拟一个字典，那么你应当考虑实现IDictionary接口。当然，你可以自己来实现这些庞大的接口，如果要解释实现方法的话，我恐怕需要多花上许多篇幅。其实有一个更简单的解决办法：当我们要创建特殊目的的集合时，我们可以从CollectionBase或者DictionaryBase来派生出我们的类。

      让我们来回顾一下本节所覆盖的内容。一个最好的集合取决于它要执行的操作和应用程序对空间和时间的要求。在大多数情况下，Array类提供了最高效的集合容器。C#中多维数组的出现意味着我们可以非常简单的模拟多维结构而不必担心牺牲性能。当你的程序需要更加灵活的添加和删除项时，你可以哪些使用更加灵活的集合类型。最后，当你要创建一个模拟集合的类时，应当为其实现索引器和IEnumerable接口。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著
 
      回到目录
 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

      跟踪可以监视应用程序在执行时的情况，获取需要的信息。通过跟踪，可以收集到程序在执行过程中的一些有用的信息。在.Net中可以通过Trace类方便的实现简单的跟踪机制。在默认情况下是使用DefaultTraceListener侦听器对Trace发送的消息进行侦听和存储的。除此之外，.Net Framework还提供了一些特殊化功能的侦听器，同默认侦听器一样，它们都派生自TraceListener类。

• TextWriterTraceListener将收集的消息输出到Stream中，我们可以方便的将其保存成文件。
• EventLogTraceListener输出到事件日志
• ConsoleTraceListener可以将跟踪信息发送到标准输出流
• XmlWriterTraceListener当然就是将信息以xml的形式输出到Stream中，同样方便保存为xml片断文件

      侦听器可以通过在代码中调用Trace.Listeners.Add和Remove方法进行添加和移除操作。另外也可以通过在应用程序配置文件中设置<system.diagnostics>元素来对消息跟踪、侦听器以及跟踪开关级别进行设置。其中的<trace>子元素可以对消息跟踪进行相关的设置。

<configuration>
   <system.diagnostics>
      <trace>
         <listeners>
            <add name="myListener" type="System.Diagnostics. XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="c:\myListener.xml" />
            <remove name="Default"/>
         </listeners>
      </trace>
   </system.diagnostics>
</configuration>

      上例中我们添加了一个名为myListener的XmlWriterTraceListener类型的侦听器，并移除了默认的侦听器。

      如果对于跟踪侦听还有其他特殊的要求，也可以实现自己的侦听器并用相似的方法添加它们。下例是一个派生自TextWriterTraceListener的自定义侦听器类。它完成的功能也很简单。通过重写WriteLine方法，该侦听器可以简单的格式化输出形式并添加时间。较常用的还有Write和WriteIf方法。

    public class MyTraceListener : System.Diagnostics.TextWriterTraceListener
    {
        public MyTraceListener(string filename)
            : base(filename)
        {
        }

        public override void WriteLine(string str)
        {
            base.WriteLine(string.Format("my trace name='{0}' time='{1}' ", str, DateTime.Now.ToString()));
        }
    }

P.S.对于XmlWriterTraceListener类型的侦听器来说，它会将消息输出为特定格式的xml片断。为了生成标准xml文件，还需要对其进行进一步的操作。最直接的做法就是将跟踪结果先储存在临时的文件中，在跟踪结束后将生成的xml片断添加到正式的trace文件里。但是某些情况下，trace文件会随着时间的增长和操作的增多变得非常巨大，由于xml的结构要求，我们不能像一般文档那样对其在末尾进行简单的追加操作。频繁的读取和导航可能会消耗较多的资源。对于这种情况我们可以使用引用外部实体来合并xml文档。XInclude？貌似支持它的太少了点...

再P.S.使用.Net使用XmlDocument处理xml文件时是禁用DTD的。如果要处理上面说的这种xml文档需要将XmlReaderSettings的ProhibitDtd属性设为false并在Load文档时候传入。
 

评论: 3　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 31: Prefer Small，Simple Functions

      对于有经验的程序员来说，不论在接触C#之前使用什么语言，都有一些提高代码效率的方法。不过有些做法虽然在之前的语言中有效，但在.Net环境中却适得其反。这一点在我们尝试手动为C#编译器优化算法时尤为明显。我们的举动往往使得JIT编译无法做出更加有效的优化。那些以优化为目的的工作，结果往往是生成更慢的代码。我们完全不必追求创建最直截了当的代码，有些工作完全可以交给编译器完成。有些过分优化会造成问题，一个典型的例子就是我们为了避免进行函数调用而创建一个又长又复杂的函数。这样的做法会降低.Net应用程序的表现，是和初衷相违背的。让我们来注意一下其中的细节。

      这里简单的介绍一下JIT编译的工作原理。.Net在运行时通过JIT编译器将C#编译器生成的IL转换为机器代码。这个工作贯穿在程序运行的生命周期中。JIT并不是在程序开始时就处理整个应用程序，而是一个函数一个函数的处理。在程序启动时只处理必需的部分函数，其他的代码只在需要使用时才进行JIT编译。那些永远不会被调用的函数永远也不会被JIT编译。相比那中少而大的函数设计，小而多的函数设计反而能减少代码的额外开销。我们考虑下面的代码：

        public string BuildMsg(bool takeFirstPath)
        {
            StringBuilder msg = new StringBuilder();
            if (takeFirstPath)
            {
                msg.Append("A problem occurred");
                msg.Append("\nThis is a problem");
                msg.Append("imagine much more text");
            }
            else
            {
                msg.Append("This path is not so bad");
                msg.Append("\nIt is only a minor inconvenience");
                msg.Append("Add more detailed diagnostics here");
            }
            return msg.ToString();
        }

      在第一时间BuildMsg被调用，所有的代码都会被JIT编译。但其中只有一条路径上的代码是有用的。但是我们可以考虑这样改进函数：

        public string BuildMsg(bool takeFirstPath)
        {
            StringBuilder msg = new StringBuilder();
            if (takeFirstPath)
            {
                return FirstPath();
            }
            else
            {
                return SecondPath();
            }
        }

      不同于最开始的代码，现在每个分支都调用了它们各自的函数。这种做法节省了运行时的消耗，虽然这点看起来消耗微不足道。但是我们考虑一下更极端一点的例子：一个if的两个分支中各包含有20个甚至更多分支。原先的做法会在开始时将整个函数读入，招致不必要的消耗。如果将函数细化JIT编译器就会以需求逻辑对函数进行编译。那些不必需的代码就不会马上被编译。对于那些较长的switch分支来说，将每个case分别定义为不同的函数可以将消耗节省几倍。

      小而简单的函数有助于JIT编译器更轻松的对其进行注册。通过注册，局部变量可以被存储在寄存器中而不是栈中。创建较少的局部变量有助于JIT编译器找到最佳候选注册变量。同样控制流程也会影响到JIT编译器注册变量。如果一个函数中包含一个循环，那么这个循环变量就很可能被注册。但是一旦一个函数中有多个循环，那么JIT编译器就必需在这些循环变量中做出一些选择。简单的函数可能包含较少的局部变量，这有助于JIT编译器优化对寄存器的使用。

      JIT编译器同样会关系到内联函数。内联函数就是以函数体来取代函数调用。考虑下面的例子：

        private string _name;
        public string Name
        {
            get
            {
                return _name;
            }
        }
       //访问
        string val = Obj.Name

      和调用函数相比，属性访问器使用更少的指令代码。函数调用不仅要保存寄存器状态、执行方法代码和保存返回值，而且当其参数需要入栈时更会需要更多的代码。如果我们这样写，所需的机器指令会更少：

string val = Obj._name

      当然，我们都明白使用属性是好过于直接创建公有的数据成员的。JIT编译器为了同时兼顾效率和规范，将内联属性访问器。JIT编译器会内联一些可以获得速度和空间优化的函数。我们不需要为内联定义额外的规则，内联函数并不是我们的职责。C#语言也没有提供一个可以只是编译器该方法为内联方法的关键字。事实上C#编译器也没有为JIT编译器提供任何内联的信息。我们所有能做的就是让代码保持清晰，这样JIT编译器更容易做出最佳判断。较小的函数是适于内联的。但是注意任何虚函数或者包含了try/catch的函数都不可能成为内联函数，即便它非常小。

      我们不需要为我们的算法确定一个在机器级别最好的表现。C#编译器和JIT编译器会为我们做这些工作。C#编译器为每个方法生成IL。JIT编译器再将这些IL转换为目标机的机器代码。我们不必太过专注于JIT编译器使用的每一条规则，而是应该将这些精力投入到如何将算法表达的更加规范，让运行环境的工具可以更有效的为我们工作。

      将C#代码转换为机器可执行的代码需要两个步骤。C#编译器生成IL，JIT编译器在需要时为每个方法生成机器代码。小函数可以让JIT编译器分期处理以减少消耗，而且也有助于内联。但是光是小还是不够，更简单的控制流程也很重要。减少控制流程分支有助于JIT编译器注册临时变量。这不仅关系到我们的代码是否清晰，也关系到执行效率问题。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 4　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 30: Prefer CLS-Compliant Assemblies

      .Net环境是与语言无关的：开发者可以不受限制的将各种不同的.Net语言编写的组件结合起来。我们必须创建遵从于CLS(公共语言规范)的程序集以便其他编程语言的开发者可以使用我们的组件。

      CLS是每种语言必须支持的操作的子集。要创建一个符合CLS的程序集，我们必须将这个程序集的接口限制在符合CLS的范围之内。这样任何一种符合CLS的语言都可以使用这个程序集。不过这并不是要求我们在整个编程过程中都使用这些符合CLS的语言子集。

      要创建符合CLS的程序集，我们必须遵循两条规则。首先所有公开和受保护成员的参数和返回值的类型必须是符合CLS的。其次，对于任何不符合CLS的公开或受保护成员，必须有相当的符合 CLS 的替换成员。

      第一个规则很容易达到。我们可以通过为程序集添加CLSCompliant属性来强制编译器进行检测。

[assembly: CLSCompliantAttribute(true)]

      这样编译器会对整个程序集强制要求符合公共语言规范。当我们的方法或属性达不到要求时就会生成一个警告。这使得我们可以方便的达到目标。下面两个例子不能通过要求，因为32位无符号整数是不符合CLS的。

public UInt32 Foo()
{
}

public void Foo2(UInt32 parm)
{
}

      我们应当明白创建符合CLS规范的程序集只会涉及到那些外部可见的成员。当Foo和Foo2被声明为public或protected时会出现不符合CLS的警告。但是如果他们是private或internal的话，就可以包含在符合CLS规范的程序集内。CLS接口规范只要求那些暴露在外的程序集项目。

      下面的属性是否符合CLS呢？

        public MyClass TheProperty
        {
            get
            {
                return _myClassVar;
            }
            set
            {
                _myClassVar = value;
            }
        }

      这要取决于MyClass是否符合CLS了。只有当MyClass符合CLS的情况下该属性才符合CLS。

      当我们的公开和受保护的接口不符合CLS时，我们是不能创建符合CLS的程序集的。从组件设计的角度上来看，这使得我们的组件很难被那些希望创建符合CLS的程序集应用。他们必须将这些接口隐藏起来，创建相同功能性的包装。虽然这是可行的，但是对于组件使用者来说并不是一个好的做法。我们应当在工作中尽量遵从CLS，对于那些需要创建符合CLS的程序集的用户来说，这是最简便的做法。

      第二个规则要求我们确保所有公开和受保护的操作都是和语言无关的。另外我们也需要确保没有这种不符合的对象隐藏在应用了多态的接口中。

      操作符重载这个特性有的人喜欢，有的人讨厌。并不是所有的语言都支持和允许操作符重载。CLS标准对于操作符重载的概念并没有表示支持或者反对。它为每一个操作符定义了一个函数名称：当我们使用=操作符时就创建了名为op_equals的函数。当我们重载了+运算符时就创建名为op_add的函数。当我们重载了运算符时，这些新的语义就可以在支持运算符重载的语言中使用了。对于那些使用不支持运算符重载的开发者来说，他们必须使用“op_运算符函数”这样的名称。如果我们希望这些开发者能使用我们的程序集，那么我们就需要提供更加清晰的语义。这里推荐一个比较简单的方法：每当我们重载操作符，应当再创建一个相同功能的函数。

        public static Foo operator +(Foo left, Foo right)
        {
            return Foo.Add(left, right);
        }
 
        public static Foo Add(Foo left, Foo right)
        {
            return new Foo(left.Bar + right.Bar);
        }

      最后我们要注意在接口的多态中是否隐藏有不符合CLS的类型。这种情况比较容易出现在事件的参数中。我们可能会创建一个不符合CLS的类型并在使用其基类时要求其符合CLS。

      假设我们创建这这样一个派生自EventArgs的类：

    internal class BadEventArgs : EventArgs
    {
        internal UInt32 ErrorCode;
    }

      这个BadEventArgs类是不符合CLS的。我们在其他语言中不能使用这样的事件句柄。但是通过多态我们可以简单的做到。我们可以声明一个基类的事件类型EventArgs：

        public delegate void MyEventHandler(object sender, EventArgs args);
        public event MyEventHandler OnStuffHappens;

        BadEventArgs arg = new BadEventArgs();
        arg.ErrorCode = 24;
        OnStuffHappens(this, arg);

      在接口的声明中，我们使用的是EventArgs参数，这是符合CLS的。但是实际上所用的类型却是不符合的。这使得它在一些语言中无法使用。

      最后我们讨论一下如何创建符合CLS的类和不符合的接口。这可能非常复杂，这里我们简单的介绍一下。了解符合CLS的几口有助于我们全面理解CLS的含义以及运行环境是如何看待这种兼容的。

      当我们为接口声明为符合CLS时，它就是符合CLS的。

[assembly: CLSCompliantAttribute(true)]
public interface IFoo
{
    void DoStuff(Int32 arg1, string arg2);
}

      我们可以在任何符合CLS的类声明中这样的接口。然而，如果在没有标记为符合CLS的程序集中声明这样的接口，它就不是符合CLS的。换句话说，只有定义在声明为符合CLS的程序集中的接口才是符合CLS的。仅仅声明接口是不足以达到目的的。这种情况是由于编译器造成的。只有当程序集声明符合CLS时，它才检查每个类型是否符合CLS。在没有声明的时候，编译器总是假设该程序集是不符合CLS的，其中的类，即便是该类声明为CLS兼容，也被认为是不符合CLS的。

      我们来看下面的这种情况：

public interface IFoo2
{
    void DoStuff(UInt32 arg1, string arg2);
}

      一个类公开的实现了不符合CLS的IFoo2接口。如果想要这个实现了IFoo2接口的类符合CLS，那么我们必须使用接口的显式实现。

public class MyClass : IFoo2
{
    void IFoo2.DoStuff(Int32 arg1, string arg2)
    {
    }
}

      MyClass拥有一个符合CLS的公开接口。期望使用IFoo2接口的客户端必须通过不符合CLS的IFoo2来访问它。

      但是这样做还不够。创建一个符合CLS的类型要求所有的公开和受保护接口只包含符合CLS的类型。这意味着我们的基类必须是符合CLS的。实现的所有接口也必须是符合CLS的。如果实现了一个非CLS的接口，那么我们就必须使用显式接口实现来从公共接口中隐藏它。

      符合CLS并不是强制我们要采用最普遍的公用名称来进行设计和实现。它要求我们关注程序集中的公共接口。对于任何公开或受保护的类来说，下面提到的几项都应当是符合CLS的：

          1、 基类

          2、 公开和受保护的函数和属性的返回值

          3、 公开和受保护的函数和索引的参数

          4、 事件的参数

          5、 公共接口的声明和实现

      我们只要多注意一些，就可以创建一个可以被其他语言使用的程序集了。CLS会确保语言的交互性。我们需要多花上一点时间在公共接口上。并不是代码中所有的类型都必须是CLS的，只要避免那些不符合CLS的类出现在公共接口中就可以了。跨语言互操作性值得我们花费这些时间。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Chapter 4 Create Binary Components

      创建二进制组件和创建类有很多相似之处：我们都在尝试区分和分割功能。它们的区别在于二进制组件可以用来描述那些离散的功能。我们可以创建组件程序集来实现简单的逻辑共享，跨语言编程和简单的程序发布。

      在.Net中程序集是一个组件包。每个程序集都可以被独立的发布和升级。升级一个已发布程序集的简易程度取决于对程序集中最小化耦合的处理是否得当。最小化耦合意味着我们不仅仅要最小化程序集中复杂的依赖关系，还要考虑便于升级版本。这章的主要内容就是如何创建易于使用、发布和更新的程序集。

      .Net的运行环境可以支持由多个二进制组件构成的程序集。我们可以独立更新其中的每一个。我们必须清楚CLR(公共语言运行库)是如何寻找和装载程序集的。在创建组件时我们必须遵循这种规则，否则就不能实现二进制组件的效果。下面的篇幅就是介绍这些的。

      CLR装载器并不会在程序开始运行时就装载所有的程序集引用。而是在运行需要时再由装载器处理该程序集引用。这可能是由方法调用或者数据访问。装载器寻找程序集引用并装载，实时编译需要的IL。

      当CLR需要装载一个程序集时，第一步时检测需要装载的文件。程序集的元数据中记录了它所有的引用。这些记录有强名称和弱名称之分。对于一个强名称程序集这种记录包含4个部分：程序集的名称，版本号，支持的区域性和公钥。对于非强名称程序集来说就只有程序集的名称。使用强名称可以减少被恶意组件替换的可能性。强名称让我们可以使用配置文件设置所需组件的版本。

      在检测到正确的程序集名称和版本号之后，CLR会检测这个程序集是否已经被装载过。如果已经装载，那么就它就可以直接应用。否则CLR会继续寻找该程序集。如果该程序集是强名称的CLR首先在GAC(全局程序集缓存)中寻找。如果不在GAC中，装载器会检查配置文件中指定的文件夹。如果这个文件夹存在，那么只在这个文件夹中搜索需要的程序集。如果没有在这个文件夹中找到所需的程序集，那么装载失败。

      如果配置文件中没有指定文件夹，那么装载器将搜索之前已定义的文件夹：

• 应用程序文件夹。也就是主应用程序集所在的位置。
• 特定性区域文件夹。这是在应用程序文件夹下的一个子文件夹。这个文件夹名称和目前的特定性区域相匹配。
• 程序集子文件夹。该文件夹的名称和程序集相匹配。它们以[特定性区域]/[程序集名称]方式组合。
• 私有的bin目录。这个目录是在程序配置文件中定义的私有目录。它以[bin目录]/[程序集名称]、[bin目录]/[特定性区域]或者[bin目录]/[特定性区域]/[程序集名称]来命名。

      有三件事我们应当注意。首先，只有强名称程序集可以被储存在GAC中。其次，我们可以使用配置文件来修改强名称程序集中默认的更新行为。最后，强名称程序集可以更好的保护我们的程序免受外来恶意篡改的威胁。

      通过介绍CLR如何装载程序集，我们应该考虑如何创建可以升级的程序集。首先我们应当考虑创建强名称程序集，并填写元数据记录。当我们使用VS.Net创建一个项目时，我们应当填写assemblyInfo.cs中的所有属性，包括完整的版本号。这使得组件更容易更新。assemblyInfo.cs中包含三个不同的部分。第一部分是主要信息：

[assembly: AssemblyTitle("My Assembly")]
[assembly: AssemblyDescription("This is the sample assembly")]
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
[assembly: AssemblyCompany("My Compay")]
[assembly: AssemblyProduct("It is part of a product")]
[assembly: AssemblyCopyright("Insert legal text here")]
[assembly: AssemblyTrademark("More legal text")]
[assembly: AssemblyCulture("en-US")]

      最后一项AssemblyCulture只对本地化程序集有效。如果程序集中不包含本地化资源，就应该让该项为空。用来描述区域性名称的字符遵照RFC 1766标准。

      第二部分包含了版本号。在VS.Net中的格式是这样的：

[assembly: AssemblyVersion("1.0.*")]

      AssemblyVersion包含四部分：<主版本>.<次版本>.<内部版本号>.<修订号>。星号标志表示内部版本号和修订号由编译器通过当前日期和时间填充。内部版本号的值是当前日期与2000年1月1日相差的天数。修订号是当前时间和今日0点之间相差的秒数除2这个算法可以保证内部版本号和修订号是不断增长的：每次重新编译的版本号都比之前的大。

      这种算法的好处在于不会有两个版本号时相同的。缺点在于当我们发布时需要记录内部版本号和修订号(因为它们不是很规则)。作者在这里推荐让编译器生成内部版本号和修订号。通过记录内部版本号我们就可以得到最终的版本信息。当我们发布新版本程序集时不要忘记修改版本号。

      最后一部分包含强名称信息：

[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]

      我们应当创建强名称程序集。强名称程序集更加安全，而且独立易于升级。不过我们应当避免在ASP.Net应用程序中使用强名称。这种部分安装不能被恰当的加载。另外强名称程序集需要使用AllowPartiallyTrustedCallers属性，否则它将不能被非强名称程序集访问。

      当我们升级组件时，它们的共有和受保护部分的接口必须在IL层兼容。这就意味着不能删除方法、修改参数或者修改返回值。这是为了让所有引用到该组件的组件都不需要重新编译。

      我们可以通过配置信息来变更引用的程序集。配置信息可以存储在三个不同的位置，这取决于我们期望升级组件的方式。对于简单的应用程序，我们可以创建应用程序配置文件来对它进行设置。如果要配置所有引用到该组件的应用程序，我们需要在GAC中创建发布者策略文件。如果需要进行全局性的配置，我们需要编辑machine.config文件，它位于.Net运行库安装路径下的Config 目录中。

      在实际应用中，我们从不需要修改machine.config来配置程序集。这个文件包含了应用于整个计算机的设置。我们使用应用程序配置文件来升级单独的应用程序。对于被多个应用程序共享的组件，我们使用发布者策略文件来配置升级。

      配置文件包含了一段用于描述现有版本号和升级版本号的xml。

 <dependentAssembly>
    <assemblyIdentity name="MyAssembly" publicKeyToken ="a0231341ddcfe32b" culture="neutral" />
    <bindingRedirect oldVersion="1.0.1444.20531" newVersion="1.1.1455.20221" />
 </dependentAssembly>

      我们可以使用配置文件来识别现有的和将要升级的程序集。当我们发布升级版本时我们可以升级或者创建适当的配置文件，应用程序就会使用新版本的组件。

      我们可以把软件想像成程序集的集合：我们可以单独升级其中的每一个部分。我们需要预先做一些工作来让软件在第一次安装时包含必要的信息，以支持这种程序集单独升级的方式。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录

评论: 1　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 29: Use the new Modifier Only When Base Class Updates Mandate it

      当我们需要重定义一个基类中非虚的成员时，我们可以使用new修饰符，但这并不意味着我们应该这样做。这种重定义会引起行为上的歧义。大部分程序员看到下面的两端代码时都会认为如果这两个类是继承关系的话，它们的行为应该时相同的：

object c = MakeObject();

MyClass c1 = c as MyClass;
c1.MagicMethod();

MyOtherClass c2 = c as MyOtherClass;
c2.MagicMethod();

      但是如果通过new进行重定义，那么结果可能并不是这样：

    public class MyClass
    {
        public void MagicMethod()
        {
        }
    }

    public class MyOtherClass : MyClass
    {
        public new void MagicMethod()
        {
        }
    }

      像这种情况经常会让很多开发人员头疼。如果调用同一个对象的同一个方法，我们期望执行结果是相同的。但是事实上虽然名称相同，但它们调用的函数却是完全不同的，这非常糟糕。它破坏了唯一性。MyOtherClass对象的行为并不是我们期望的。使用new修饰符可以让我们在类中添加一个完全不同的方法，这不同于重写基类中的虚方法。

      非虚的方法都是静态确定的。不论在任何位置的代码，这些方法都调用同样的函数。在运行时不会在其派生类中寻找此方法的不同版本。而虚方法是动态确定的。运行时将通过不同的类型来调用该方法不同的版本。

      我们应当避免使用new来重定义非虚方法。不然我们就需要将基类中的所有方法都声明为虚的。设计者通过定义这些虚方法为类添加了一种行为约定。它的派生类都可以通过这个虚方法来达到自己不同的实现需要。每一条虚方法都定义了其派生类可能需要改变的行为。“默认虚方法”的设计认为基类中所有的方法都为虚，派生类可以修改基类中所有的行为。这往往意味着你并没有认真思考派生类之间行为的分支关系。我们应当多花些时间思考派生类中哪些方法和属性时需要多态性的，仅仅把这些有需要的方法和属性设为虚的。我们不要将这想象为对用户的限制。而是将它看作指导用户自定义行为的入口。

      仅有一种情况下我们应该使用new修饰符：我们更新了一个新版本的基类，而这个基类中有包含和我们原有类型相同名称的方法。我们在下例中创建一个MyWidget类，使用其他类库定义的BaseWidget类做为基类：

    public class MyWidget : BaseWidget
    {
        public void DoWidgetThings()
        {
        }
    }

      我们完成了这个类并交付用户使用。然后我们发现BaseWidget公司发布了一个新版本的BaseWidget类。对于新特性的热衷让我们立即尝试使用新的基类来构建MyWidget类。但是却失败了，因为我们发现BaseWidget中添加了他们自己的DoWidgetThings方法。

    public class BaseWidget
    {
        public void DoWidgetThings()
        {
        }
    }

      问题出现了。我们的新基类偷偷的提供了一个和我们类型相同名称的方法。我们有两种方法可以解决这个问题。一是更改我们类中DoWidgetThings方法的名称：

    public class MyWidget : BaseWidget
    {
        public void DoMyWidgetThings()
        {
        }
    }

      二是使用new修饰符：

    public class MyWidget : BaseWidget
    {
        public new void DoWidgetThings()
        {
        }
    }

      如果能获得所有所用MyWidget类的客户程序代码，那我们应当选择修改名称的方法。但是如果我们已经发布了MyWidget类，这种修改就会强迫我们所有的用户修改其代码。如果发布范围较大的话，这种修改付出的代价太高。new操作符可以帮助我们处理这个问题。所有的客户端都可以不做任何更改的继续使用DoWidgetThings()方法。没有用户会使用BaseWidget.DoWidgetThings()因为他们不知道基类中有这样一个方法。new操作符在升级基类版本时隐藏了命名冲突的成员。

      当然，在经过一段时间后，有的用户可能会开始需要使用BaseWidget.DoWidgetThings()方法。这样我们又回到了原来的问题：两个方法的名称相同但是行为不同。考虑到使用new修饰符会产生长期的语义分歧，因此虽然更改方法名称会比较麻烦，但是相比之下这种处理方式往往更加得当。

      在使用new修饰符时必须小心。不恰当的使用会造成方法调用的歧义。只有当升级基类发生命名冲突时才可以使用它来进行特殊处理。而且即便如此也应当谨慎使用。不要在其他情况下使用new修饰符。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 28: Avoid Conversion Operators

      转换操作为我们提供了类之间的一种可置换的关系。这意味着一个类的对象可以被其它类的对象替代。这样的好处在于：一个派生类的对象可以被其基类的对象代替。我们可以参考下图结构。我们创建一个Shape基类和三个派生类：Circle，Ellipse，Square。任何情况下都可以用Circle来替代Shape，因为Circle是一个特殊的Shape，这是多态的表现。就像在.Net中，任何对象都可以被System.Object型的对象替代，它是所有类型的基类。同样，我们自己创建的类的对象也可能被实现同样接口的类、实现同样基类接口的类或者基类的对象替代。

      如果我们需要为类定义转换操作，就说明它可能会被其它的目标类型所替换。这种替换经常会引发一些潜在的错误，往往是因为两个类型之间的转换并不完美造成的。另外，在效率方面，修改目标类型的操作效率往往较低，特别是当转换产生临时对象的时候。而且，转换操作的规则基于编译期的类型对象发挥作用，而不是运行期。用户可能会需要使用多种强制类型转换来实现这种替代关系，这可能会造成代码难以维护。

      如果确实需要将一个类型转换为另一个目标类型，我们应当通过构造函数来实现。这样会使我们创建新对象的操作更加清晰。使用隐式转换往往会造成一些难以发现的错误。假设我们有如图中的类结构。从基类中派生出三个子类。我们知道每个圆都是一个椭圆，另外一些特殊的椭圆是圆。虽然圆和椭圆之间是有关系的，但是我们还是将结构设计成这样，这是因为我们不希望在结构中有非抽象的叶子类(否则这里的结构应该是hape->Ellipse->Circle)。由于每个圆都是椭圆，那么我们可以添加一个由圆创建一个新的椭圆的转换：

    class Circle : Shape
    {
        private PointF _center;
        private float _radius;

        public Circle(PointF c, float r)
        {
            _center = c;
            _radius = r;
        }

        public Circle()
            : this(PointF.Empty, 0)
        {
        }

        static public implicit operator Ellipse(Circle c)
        {
            return new Ellipse(c._center, c._center, c._radius, c._radius);
        }
    }

      现在我们就能在任何可以使用Ellipse的地方使用Circle了，这种转换是自动发生的：

public double ComputeArea(Ellipse e)
{
    //计算面积
}

Circle c = new Circle(new PointF(3.0f, 3.0f), 5.0f);
ComputeArea(c);

      上面的例子展示了一个圆是如何转换为一个椭圆的。ComputeArea函数也可以在转换后正常运行。但这只是运气好罢了，我们看下面的这个函数：

public double Flatten(Ellipse e)
{
    e.R1 /= 2;
    e.R2 *= 2;
}

Circle c = new Circle(new PointF(3.0f, 3.0f), 5.0f);
Flatten(c);

      这时程序就不能发挥作用了。由于Flatten()方法使用椭圆做为参数，编译器要求我们必须提供一个将圆变为椭圆的转换。这个转换可以在我们调用时为Flatten()函数提供一个椭圆类型的临时对象作为参数。这个临时对象将被Flatten()函数修改，然后立刻被销毁。那些我们期望的操作并没有发生在原来的Circle c上，而是发生在了临时的对象上。

      既然隐式转换不行，我们继续尝试使用显式的强制类型转换：

Circle c = new Circle(new PointF(3.0f, 3.0f), 5.0f);
Flatten((Ellipse)c);

      这样并没有解决根本问题。我们还是创建了临时对象。Circle c不会发生任何变化。接下来，我们继续尝试通过Ellipse的构造函数来达到转换的目的：

Circle c = new Circle(new PointF(3.0f, 3.0f), 5.0f);
Flatten(new Ellipse(c));

      大部分程序员一眼就能看出上面的代码不会达到目的。在Flatten()函数中进行的所有修改还是丢失了。我们可以这样修补它的错误：

Circle c = new Circle(new PointF(3.0f, 3.0f), 5.0f);
Ellipse e = new Ellipse(c);
Flatten(e);

      变量e就是修改过的椭圆了。通过使用构造函数来取代转换，使得对象的创建过程更加清晰。

      通过转换操作返回的对象属性可能会丧失其原有的某些行为，这会为我们造成另一些麻烦。通过转换操作，一些客户程序可能会访问到对象的内部成员。这一点是我们需要避免的。

      转换操作可能会在编程时为我们带来一些问题。当用户期望使用其他的类型来代替我们原有类型时，我们应当清楚这种转换产生的是一个很快就会被销毁的临时对象。由于这种转换的代码时编译器自动生成的，我们很难发现其中隐藏的bug。因此在条件允许的情况下我们应当尽量避免转换操作。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 2　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 27: Avoid ICloneable

      ICloneable听起来不错：通过它我们就可以让类型支持拷贝。但是我们的类往往并不是独立存在的。一旦我们确定要支持ICloneable，那么它的所有派生类也需要实现这个接口。内部的所有成员也需要支持ICloneable或者其它创建拷贝的机制。要实现深克隆经常会带来很多的问题。在理论上ICloneable是用来解决这些克隆问题的：它可以支持浅克隆或者深克隆。浅克隆创建一个新的对像，对像成员的内容都是原内容的拷贝。对于引用类型来说，新的对像和原对像引用的地址是一样的。而深克隆也是创建一个新对像并拷贝其成员。所有的引用类型都被递归克隆，而不再引用原对像成员。对于.Net内建值类型，例如int来说，这两种克隆方式的结果没有区别。究竟支持哪种要取决于我们的类。但是混合了潜克隆和深克隆机制的类会给我们造成一些错误。一旦掉进了ICloneable的陷阱，就很难全身而退了。一般情况下尽量将类创建得简单，避免使用ICloneable。这样既便于使用，也便于实现。

      任何只包含内建类型成员的值类型是不需要支持ICloneable的。简单的拷贝值到结构体中比使用Clone()更加高效。Clone()在返回值时需要装箱操作，在使用返回值时又需要对其拆箱。

      那么如果值类型中包含引用类型呢？最常见的例子就是一个结构体中包含string型成员：

public struct ErrorMessage
{
    private int errCode;
    private int details;
    private string msg;
}

      string是一个特例因为它是不可变类型(参见 Item7: Prefer Immutable Atomic Value Types)。它不会引发一般的引用类型造成的麻烦。因为一旦msg的值变化了，就代表它指向了一个新的string对像的引用。

      如果结构中包含其它的引用类型，那么情况就会复杂的多。而且这种情况也是很常见的。当我们使用内建的拷贝操作(最简单的=操作符)时，创建的是一个潜克隆对像，其中的引用类型成员同原结构体中的成员指向同一个对像。如果要创建深拷贝，我们首先要确定结构中的引用类型是否支持深拷贝。

      我们使用ICloneable的时候必须谨慎，因为我们需要考虑到派生类的情况。先看下面这个例子：

    class BaseType : ICloneable
    {
        private string _label = "class name";
        private int[] _values = new int[10];


        ICloneable 成员#region ICloneable 成员

        public object Clone()
        {
            BaseType rVal = new BaseType();
            rVal._label = _label;
            for (int i = 0; i < _values.Length; i++)
            {
                rVal._values[i] = _values[i];
            }
            return rVal;
        }

        #endregion
    }

    class Derived : BaseType
    {
        private double[] _dValues = new double[10];
    }

    //调用
    Derived d = new Derived();
    Derived d2 = d.Clone() as Derived;
    if (d2 == null)
    {
        Console.WriteLine("null");
    }

      运行后我们会发现d2为null。派生类的确调用了基类的ICloneable.Clone()方法，但是返回的却是一个基类的对像，而不是派生类的。这也是为什么d2为null的原因。而且即便解决了这个问题，派生类中的_dValues也不能成功的克隆。我们需要提供一个钩子函数来使得所有的派生类支持克隆。而且派生类中新成员必须是值类型或者支持克隆的引用类型。对于派生类来说，这是一个有些苛刻的要求。支持ICloneable往往会给我们带来额外的负担。

      如果必须支持ICloneable，我们可以创建一个抽象Clone()方法来让所有的派生类实现。这样我们还需要为派生类提供一个创建基类对像拷贝的方法。下例中通过定义一个受保护的拷贝构造函数来实现：

    class BaseType
    {
        private string _label;
        private int[] _values;

        protected BaseType()
        {
            _label = "class name";
            _values = new int[10];
        }

        protected BaseType(BaseType right)
        {
            _label = right._label;
            _values = right._values.Clone() as int[];
        }
    }

    sealed class Derived : BaseType, ICloneable
    {
        private double[] _dValues = new double[10];

        public Derived()
        {
            _dValues = new double[10];
        }

        private Derived(Derived right)
            : base(right)
        {
            _dValues = right._dValues.Clone as int[];
        }

        ICloneable 成员#region ICloneable 成员

        public object Clone()
        {
            Derived rVal = new Derived(this);
            return rVal;
        }

        #endregion
    }

      上例中基类没有实现ICloneable，它提供了一个受保护的构造函数来让派生类拷贝基类成员。对于声明为sealed的派生类可以在必要时实现ICloneable。这样虽然基类提供了对克隆的必要支持，也不要求所有的派生类都实现克隆。

      ICloneable虽然有它的优势，但是也会造成很多麻烦。永远不要让值类型支持ICloneable。尽量避免在不必要的情况下使用ICloneable接口。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 1　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

Effective C# Item 26: Implement Ordering Relations with IComparable and IComparer

      有时候我们需要为类定义排序关系以便在集合中对该类的对象进行排序和检索。在.Net Framework中定义了两种用来描述排序顺序关系的接口：IComparable和IComparer。IComparable接口描述了类型的通用排序比较方法，而IComparer描述的是两个对象之间的比较方法。在本节中主要讨论如何实现这种排序顺序关系。另外，我们可以通过实现自定义关系运算符来提供这些特殊的比较关系。

      IComparable接口包含一个方法：CompareTo()。这个方法的历史可以追溯到C语言类库中的strcmp函数：如果当前对象小于比较对象则返回小于0的值，如果相等则返回0，如果当前对象大于比较对象则返回大于0的值。IComparable的参数为System.Object型，因此我们在使用的时候需要对参数的类型进行检查：

    public struct Customer : IComparable
    {
        private readonly string _name;
        public string Name
        {
            get
            {
                return _name;
            }
        }

        public Customer(string name)
        {
            _name = name;
        }

        IComparable 成员#region IComparable 成员

        public int CompareTo(object right)
        {

            if (!(right is Customer))
            {
                throw new ArgumentException("Argument not a customer", "right");
            }
            Customer rightCustomer = (Customer)right;
            return _name.CompareTo(rightCustomer.Name);
        }

        #endregion
    }

      IComparable接口有一些不尽人意之处。我们必须检查输入参数的类型，因为我们不能确定使用者会传递哪种类型的对像。另外在对值类型进行操作的时候还会因为boxing和unboxing而降低执行效率。当我们使用IComparable对集合进行排序时需要进行N*log(n)次比较。对于一个大小为1000的集合来说，需要进行7000次左右的比较，在某些条件下这相当于20000多次boxing和unboxing。在这种情况下我们必须寻找更好的比较途径。虽然我们不能修改IComparable.CompareTo()的定义，但是我们还是可以通过重写CompareTo方法来解决这个问题：

    public struct Customer : IComparable
    {
        private readonly string _name;
        public string Name
        {
            get
            {
                return _name;
            }
        }

        public Customer(string name)
        {
            _name = name;
        }

        IComparable 成员#region IComparable 成员

        int IComparable.CompareTo(object right)
        {

            if (!(right is Customer))
            {
                throw new ArgumentException("Argument not a customer", "right");
            }
            Customer rightCustomer = (Customer)right;
            return _name.CompareTo(rightCustomer.Name);
        }

        #endregion

        public int CompareTo(Customer right)
        {
            return _name.CompareTo(right.Name);
        }
    }

      现在IComparable.CompareTo()只是一个接口实现，只能通过IComparable接口被调用。用户使用的将是类型安全的比较。不正确的比较类型不能通过编译。不能通过编译的原因是参数类型和Customer.CompareTo(Customer right)方法不符。只有通过IComparable接口才会调用CompareTo(object right)方法。

      当我们实现IComparable接口时，应当也提供一个强类型的重载。这样可以减少我们发生错误的可能性，而且比较两个已知类型对像的效率较高。不过这种重载对于集合的Sort()方法来说没有效果，因为它是通过接口来访问CompareTo()方法的。

      我们可以再对Customer结构做一些修改。在C#中允许我们重载运算符。它们调用的是类型安全的CompareTo()方法：

    public struct Customer : IComparable
    {
        private readonly string _name;
        public string Name
        {
            get
            {
                return _name;
            }
        }

        public Customer(string name)
        {
            _name = name;
        }

        IComparable 成员#region IComparable 成员

        int IComparable.CompareTo(object right)
        {

            if (!(right is Customer))
            {
                throw new ArgumentException("Argument not a customer", "right");
            }
            Customer rightCustomer = (Customer)right;
            return _name.CompareTo(rightCustomer.Name);
        }

        #endregion

        public int CompareTo(Customer right)
        {
            return _name.CompareTo(right.Name);
        }
        public static bool operator <(Customer left, Customer right)
        {
            return left.CompareTo(right) < 0;
        }
        public static bool operator <=(Customer left, Customer right)
        {
            return left.CompareTo(right) <= 0;
        }
        public static bool operator >(Customer left, Customer right)
        {
            return left.CompareTo(right) > 0;
        }

        public static bool operator >=(Customer left, Customer right)
        {
            return left.CompareTo(right) >= 0;
        }
    }

      上例中我们完成了以姓名对用户排序。现在我们又需要对用户的收入进行排序，而且不可以修改上例中对姓名排序的基本排序方式。为了解决这个问题，我们可以创建一个实现IComparer接口的类来达到目的。在.Net类库中凡是实现了IComparable接口的类型都通过IComparer接口进行了重载。我们可以为Customer接口内部创建一个私有的类，并将其通过静态属性暴露出来：

    public struct Customer : IComparable
    {
        private readonly string _name;
        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                _name = value;
            }
        }

        private double _revenue;

        public double Revenue
        {
            get
            {
                return _revenue;
            }
            set
            {
                _revenue = value;
            }
        }
        private static RevenueComparer _revComp = null;

        public static IComparer RevenueCompare
        {
            get
            {
                if (_revComp == null)
                {
                    _revComp = new RevenueComparer();
                }
                return _revComp;
            }
        }

        IComparable 成员#region IComparable 成员

        int IComparable.CompareTo(object right)
        {

            if (!(right is Customer))
            {
                throw new ArgumentException("Argument not a customer", "right");
            }
            Customer rightCustomer = (Customer)right;
            return _name.CompareTo(rightCustomer.Name);
        }

        #endregion

        public int CompareTo(Customer right)
        {
            return _name.CompareTo(right.Name);
        }

        private class RevenueComparer : IComparer
        {

            IComparer 成员#region IComparer 成员

            int IComparer.Compare(object left, object right)
            {
                if (!(left is Customer))
                {
                    throw new ArgumentException("Argument not a customer", "left");
                }
                if (!(right is Customer))
                {
                    throw new ArgumentException("Argument not a customer", "right");
                }
                Customer leftCustomer = (Customer)left;
                Customer rightCustomer = (Customer)right;
                return leftCustomer._revenue.CompareTo(rightCustomer._revenue);
            }

            #endregion
        }
    }

      现在我们就可以通过收入来对用户排序了：

Customer c1 = new Customer();
Customer c2 = new Customer();
Customer.RevenueCompare.Compare(c1, c2);

      另外我们还应当注意一下Equals()方法和==运算符。在排序时我们没有实现等于关系的必要。事实上，对于引用类型来说，判断大小依照的是对像的内容，而判断相等依照的是对像的地址。

      IComparable和IComparer是为类提供顺序关系的基本机制。IComparable适用于大多数的排序需求。当我们实现它时，也应该重载比较关系运算符。IComparable.CompareTo()使用System.Object类型对像做为参数，为此我们可以提供一个特定类型参数的重载来提高效率，减少错误。如果一个类型并未给我们提供需要的排序机制，那么我们可以通过ICompare来达到目的。

      译自   Effective C#:50 Specific Ways to Improve Your C#                      Bill Wagner著

      回到目录
 

评论: 1　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 刘强东微博透露京东商城将进军SNS领域(2010-03-21 11:19)
· 钟胜辉携CmsTop二次创业 专注垂直门户资讯领域(2010-03-21 11:09)
· Pwn2Own前夕抓紧补 谷歌为Chrome浏览器发布11项安全补丁(2010-03-21 08:21)
· 黑客大赛开始 iPhone成主要攻破目标(2010-03-21 08:12)
· 给Chrome的一封信(2010-03-21 07:35)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库