views:

66

answers:

2

Hello !

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 behavior of Data kind, I'm screwed, every data-testing method will need to be changed.

+2  A: 

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

Darin Dimitrov
+1 Thank you, helped a lot ! :-)
Aurélien Ribon
I would say it is type reflection/type identification...Anyway this is not a good OO design. You should use polymorphism when possible. E.g. if you print the node based on the node type, you should rather add print to node interface and have all nodes implement that interface, but each concrete type/strategy in its way.
Gabriel Ščerbák
I started my application by using polymorphism with Node, having a DataNodes, DataIONodes, etc etc... But what I want to change a Node from DataIntermediate to DataOutput ? Its a mess, every Parents/children must be swapped with a new node, attributes must be copied, etc etc. That's why the strategy pattern stands for : to be able to easily change an object behavior.
Aurélien Ribon
A: 

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.

mdma