Strategy Pattern with Type Reflection affecting Performances?

I am building graphs. A graph consists of nodes linked each other with links (indeed my dear). In order to assign a given behavior to each node, I implemented the strategy pattern.

class Node {
    public BaseNodeBehavior Behavior {get; set;}
}

As a result, in many parts of the application, I am extensively using type reflection to know which behavior a node is.

if (node.Behavior is NodeDataOutputBehavior)
    workOnOutputNode(node) ....

My graph can get thousands of nodes.

• Is type reflection greatly affecting performances ?
• Should I use something else than the strategy pattern ?

I'm using strategy because I need behavior inheritance. For example, basically, a behavior can be Data or Operator, a Data behavior can IO, Const or Intermediate and finally an IO behavior can be Input or Output.

So if I use an enumeration, I wont be able to test for a node behavior to be of data kind, I will need to test it to be [Input, Output, Const or Intermediate]. And if later I want to add another开发者_Go百科 behavior of Data kind, I'm screwed, every data-testing method will need to be changed.

if (node.Behavior is NodeDataOutputBehavior) is not reflection and is very fast.

Using the Visitor pattern for the different node behaviours would remove the type check. However, I would do this to get a cleaner design, rather than for performance, as I doubt there would be any significant performance difference.

The Visitor pattern works well if the types of node behaviour are static at compile time. When you add a new node behaviour, you add a new method to the Visitor interface, which means the compiler catches cases where that behaviour is not handled.

With ad hoc type checking, you have to manually inspect your code to determine where you need to add new handlers for new behaviour types.

• Wikipedia, Visitor Pattern