I have an application where I am performing an operation on a series of elements and the exact nature of the operation depends on the type of the element being operated upon. For reasons of encapsulation, it's not appropriate for the element to implement the operation; this means it can't be a virtual method on the element type and so 'standard' polymorphism doesn't work. I posed a previous question related to this and was informed that this was known as the Visitor Pattern.
I had previously always implemented this using an
private void ReconcileTips()
foreach (var step in _definition.Steps)
private void ReconcileTips(IBulkDispenseDefinition bulkDispense)
bulkDispense.TipType = ReconcileTip(bulkDispense.TipType);
private void ReconcileTips(ImportScreenDefinition importScreen)
foreach (var usage in importScreen.ReagentUsages)
usage.TipType = ReconcileTip(usage.TipType);
private void ReconcileTips(BuildScreenDefinition buildScreen)
foreach (var function in buildScreen.Functions)
function.TipType = ReconcileTip(function.TipType);
if (x is TypeA) Do((TypeA)x) else...
Are there any gotchas with the dynamic dispatching that I haven't considered? I believe this is equivalent to performing a series of if (x is TypeA) Do((TypeA)x) else..., but I could be wrong.
The main gotcha would be if a type implements more than one interface in your visitor pattern - the compiler will probably pick the one you want, but it may not be the same choice you'd make if you use
if (x is TypeA)/
else if (x is TypeB) logic, as you'd control the order the checks occur.
Is this actually cleaner and easier to understand than a long if/elseif method?
I personally think so. This provides a very clean, fairly decently performing dispatch determined by the runtime type, and "just works." Hard to beat simple, short, clean code. Just make sure to (potentially) handle the case where you get a runtime error from the wrong type being passed in.