This pattern was originally introduced as the Channeling Pattern in LabVIEW. It has since been identified as identical to the classical programming pattern known as the Template Method Pattern from the Gang of 4 book.
To provide a guaranteed pre-processing/post-processing around some dynamic central functionality. Allows child classes the ability to override some steps of an algorithm without giving them the ability to change out the entire algorithm.
You have a class hierarchy. And you have some algorithm that you want to implement on the parent class. There is a core step of the algorithm that needs to be dynamic dispatch so that each child class can provide its own behavior. But it is unsafe to call that step directly – there are pre-conditions that must be checked or post-conditions you want to enforce. So you need an interface that guarantees the core is only called from a particular entry point.
To make this pattern work, give the parent class a static dispatch VI that implements the algorithm. That way the child classes cannot override the algorithm itself and thereby avoid calling the pre-processing/post-processing. Make the core step of the algorithm a dynamic dispatch VI that the child classes can override. Let the dynamic dispatch VI be protected scope in the parent class. This forces all the children to use protected scope for their override VIs. No VI outside the class hierarchy will be able to call the core VIs directly.
This pattern does not prevent child classes from calling the step on themselves or other child classes without going through the algorithm. It does make sure that all the VIs outside the class hierarchy go through the algorithm VI.
The name of this pattern refers to the control of the flow of data – the data is channeled through the static VI to get to the dynamic VIs.
[Stephen Mercer] A customer asked me why all member VIs in classes aren’t dynamic dispatch. After all, the performance overhead of dynamic dispatching is pretty small compared to a regular subVI call. And the amount of overhead is a fixed constant amount. So it made sense to the customer to make all the VIs dynamic dispatch and only make static dispatch VIs if a performance problem actually arose. That would give maximum flexibility to the class. This pattern is one of several reasons not to make every VI dynamic dispatch. If the algorithm itself were dynamic dispatch, child classes might decide to override the algorithm and skip the pre/post processing.
This pattern is particularly useful for large programming teams where you might not know all the developers, or where child classes will be implemented by third parties. It lets the original author put compiler-enforceable guidelines into the code so that future programmers do not unwittingly write VIs that will create issues for the architecture.