我应该将继承类的类型存储为其属性,而不是使用`as`或`is`？

Question

比方说,如果我想集中测试一些继承类的类型,并且需要良好的性能,我应该使用enum存储所有可能的类型,并使用枚举相等来测试类型而不是使用is.

例如

switch (myObject.Type)
      {
      case myType.type1:
                 myObject as myInheritedObject1;
                 ...
                 break;
      case myType.type2:
                 myObject as myInheritedObject2;
                 ...
                 break;
      case myType.type3:
                 myObject as myInheritedObject3;
                 ...
                 break;
         ...
     }

要么

    var tmp = myObject as myInheritedObject1;
    if (tmp != null)
      {
      }
    else 
      {
        tmp = myObject as myInheritedObject2;
        if (tmp != null)
        {
        }
          else 
            {
             tmp = myObject as myInheritedObject3;
             if (tmp != null)
             {
             }
      }   }}

Answer 1

比方说,如果我想集中测试一些继承类的类型,并且需要良好的性能,我应该使用枚举存储所有可能的类型,并使用枚举相等来测试类型而不是使用is？

这种机制通常被称为"歧视型",即FYI.

答案是:这取决于您的性能要求.歧视类型有许多缺点:

• 他们使用更多的记忆; 如果你有一百万个有区别类型的实例,并且鉴别器占用四个字节,那就是四个完全不必要的虚拟内存.如果对象长时间存在并且堆需要压缩,那么内存将被垃圾收集器复制.
• 这些信息完全是多余的; 对象已经知道它的类型是什么.这不仅浪费空间,而且是潜在的错误机会; 如果您有冗余信息,您可能会因为错误而导致信息不一致.
• 这种模式很脆弱 ; 编写一个switch忘记案例并在运行时可怕地死亡或者做一些疯狂的事情是非常容易的.
• 这意味着使用此代码库的未来程序员将面临巨大的维护负担; 他们必须确保他们可以在不破坏任何现有代码的情况下引入新的枚举值,或者从不在层次结构中引入新类型.
• 该模式也很脆弱,因为它适用于深层次的层次结构; 当你必须记住ColorFoo和FrobbyFoo以及BlobbyFoo是各种Foo时,编写多态代码会变得更加困难.如果你添加一种新的Foo怎么办？

它们的优势在于它们实际上比进行类型测试略快.

因此,解决此问题的方法与解决任何其他性能问题的方法相同:

• 为与客户相关的所有性能方面(包括时间,内存等)设置有意义的以客户为中心的性能目标.
• 编写仔细,逼真,有意义的基准测试,在客户真实体验的现实条件下测试程序.
• 如果您使用标准习语的表现is不符合您的要求,那么评估是否对有区别的类型进行更改会导致程序满足您的要求.如果确实如此,那么考虑这样做的成本并做出相应的决定.如果没有,那么你有一个更大的问题要解决,所以首先解决这个问题.

在Roslyn团队中,我们以各种可能的方式限制了性能要求,因此我们非常仔细地考虑了这个问题.我们决定采用在整个Roslyn中使用歧视类型的一般策略.这意味着我们必须非常小心我们设计交换机的方式,类型层次结构等等.我们还拥有一支专业的绩效团队,每天都会根据客户要求确认我们的绩效.

我们的要求与绝大多数业务线开发人员的性能要求完全不同; 您不应该使用Roslyn代码作为确保良好性能的模型.相反,您应该使用我们的方法作为确保良好性能的模型:设定目标,经常测量,并且只有在这样做时才进行体系结构更改才能真正解决现有问题.