Should I store the type of an inherited class as its property rather than use `as` or `is`?

Question

say, if I want to intensively test the type of some inherited class, and good performance is desired, should I use enum store all possible types, and use enum equality to test the type instead of using is.

e.g.

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

or

    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

say, if I want to intensively test the type of some inherited class, and good performance is desired, should I use enum store all possible types, and use enum equality to test the type instead of using is?

Such a mechanism is usually called a "discriminated type", FYI.

The answer is: it depends on what your performance requirements are. Discriminated types have many drawbacks:

• They use much more memory; if you have a million instances of a discriminated type and the discriminator takes up four bytes, thats four megs of entirely unnecessary virtual memory right there. That memory is going to be copied around by the garbage collector if the objects live for a long time and the heaps need compacting.
• The information is entirely redundant; the object already knows what its type is. That is not only a waste of space but it is a potential bug opportunity; any time you have redundant information you have the potential for the information to become inconsistent due to a bug.
• This pattern is fragile; it is very easy to write a switch that forgets a case and dies horribly at runtime or does something crazy as a result.
• And that means that there is a huge maintenance burden for future programmers using this codebase; they have to ensure that they can introduce a new enum value without breaking any existing code, or live with never introducing a new type into the hierarchy.
• The pattern is also fragile because it works against deep type hierarchies; writing polymorphic code becomes more difficult when you have to remember that a ColorFoo and a FrobbyFoo and a BlobbyFoo are all kinds of Foo. What if you add a new kind of Foo?

They have the advantage that they are in fact slightly faster than doing a type test.

So, solve this problem the same way you would solve any other performance problem:

• Set meaningful customer-focussed performance goals for all performance aspects that are relevant to the customer, including time, memory, and so on.
• Write careful, realistic, meaningful benchmarks that test the program under realistic conditions that customers will actually experience.
• If your performance using the standard idioms like is does not meet your requirements, then evaluate if making the change to discriminated types does cause the program to meet your requirements. If it does, then consider the costs of doing so and make a decision accordingly. If it does not then you have a bigger problem to solve, so solve that problem first.

On the Roslyn team we have enormously restrictive performance requirements in every possible way and we therefore considered this question extremely carefully. We decided to go with a general strategy of using discriminated types throughout Roslyn. This means that we have to be extremely careful about the way we design our switches, our type hierarchies, and so on. We also have a dedicated performance team that verifies every day that our performance continues to be on track with customer requirements.

Our requirements are quite different from the vast majority of line-of-business developer's performance requirements; you should not use the Roslyn code as a model for ensuring good performance. Rather, you should use our methodology as a model for ensuring good performance: set goals, measure frequently, and only make architectural changes when doing so actually solves an existing problem.

Answer 2

If you want to intensively test the type of some inherited class, I would use an enum, or as Eric Lippert called it a "Discriminated type". Eric identified 5 drawbacks of this technique, but I disagree with most of the drawbacks. Below I will address each one:

1. They use much more memory. There is no need for the instances to take up any more memory if the base class defines an abstract property that is defined in the child classes without taking up memory. Below is an example:

   abstract class MyBase
   {
       // Define each child class as a new MyType enum
       public abstract MyType Type { get; }
   }
   class MyChild1 : MyBase
   {
       public override MyType Type
       {
           get { return MyType.Child1; }
       }
   }
   

   EDIT: Adding additional example. Above is an example of not using additional memory. Below additional memory would be used because the "Discriminated type" is saved as a field on the base class instead of being set in code on the child class. If the Type Property is set as abstract and defined in code on the child classes then no additional memory is used.

   class MyBase
   {
       protected MyBase(MyType type) { this.type = type; }
       MyType type;
       public MyType Type { get { return type; } }
   }
   class MyChild1 : MyBase
   {
       public MyChild1() : base(MyType.Child1) { }
   }
   

2. The information is entirely redundant. This is true, but having the enum and the abstract property will call out to a developer that the child class is a "Discriminated type" and that they need to address other code.

3. This pattern is fragile. Yes, the pattern is fragile, but so is using "AS" and "IS", and if you need logic based on the instance type, then I prefer the "Discriminated type" pattern.
4. And that means that there is a huge maintenance burden for future programmers. In my opinion the "Discriminated Type" pattern is less of a burden than the "AS" and "IS" pattern, and is more self documenting and the code is easier to read and understand.
5. The pattern is also fragile because it works against deep type hierarchies. I believe this is a good thing, because if you need to use this type of pattern, it would be better not to use deep type hierarchies.

In short, if this type of pattern is really needed, and you have the choice between using the "Discriminated type" pattern and an "AS"/"IS" pattern, I would choose the former because it is faster, easier to read, and more self-documenting.