To have two independent classes share common functionality without putting that functionality into a common parent class.
Good object-oriented design requires each class to focus on its assigned task. A class shouldn’t have member VIs unrelated to its task. If you have two classes that have some shared functionality, the usual solution is to create a parent class that both of them inherit from. Sometimes, however, you already have a class hierarchy created and a new feature comes along. The new functionality needs to be added to two existing classes that either do not have a common ancestor or do have a common ancestor but that ancestor is several generations up and not every descendent of that ancestor should have the new functionality. In some languages you might try multiple inheritance. But even in languages that support multiple inheritance, delegation is generally a better solution.
This pattern applies best when you have a dynamic VI inherited from some ancestor and two descendent classes want to override that dynamic VI with exactly the same implementation. Delegation helps you avoid writing the implementation twice, once for each of the two classes.
An example of this pattern was made available by Christina Rogers in her refactoring of the Getting Started Window in creation of her Project Wizard class (http://www.eyesonvis.com/blog/2006/08/object-oriented-getting-started-window.htm l). As of LabVIEW 2012, this example is now included in the examples folder shipped with LabVIEW at [LabVIEW Path]\examples\lvoop\navigation ... It was deleted from LabVIEW in LabVIEW 2014 because it was judged to not be a sufficiently accessible piece of code to qualify as a shipping example. You will need to find it from an older source.
The general idea is this: Create a third class that has the new functionality. The new class is frequently something like “Function Helper” or “Function Assistant,” where “Function” is whatever functionality is to be delegated. Give that class all the data fields necessary to carry out the new functionality. Then add that third class as a data member to the two classes that need to share the functionality.
The two descendent classes override the ancestor’s dynamic VI. But they only put in a bit of code necessary to call the exact same method on their data member of the helper class. The actual work is entirely in that method of the helper class. Now there is only a single instance of the code, which makes bug fixing easier. The two descendent classes have delegated the work to a third class – thus the name of this pattern.
You might think, “Why not just have a common subVI that isn’t a member of either class?” The answer is that there may well be some state data associated with the helper object. It may have fields of its own which you would have to add to both of the caller classes and then keep in sync. By making it an object, you fully encapsulate this bit of functionality.
[Stephen Mercer] This pattern is not listed explicitly in the Gang of Four text. The idea occurs as an aspect of several other patterns. I think it is useful enough to warrant specific attention.
[David Staab] The goal of this pattern is to have a set of common methods that multiple disparate classes can access. In Java, you have to create a new class and put those methods in there. LV provides lots of options for how to achieve this goal, though, and you don't always have to use a class to provide that common access. I've done delegation for common methods of classes inside the same library (.lvlib), wherein I create a new folder in the library and add the common VIs to that folder. I usually mark the folder Private so only the classes in that library can get to those methods. This is an equally valid approach to achieving delegation without requiring a new class to encapsulate the delegate methods. It comes in very handy when you have objects that don't require constructor VIs yet, and you don't want to have to make a constructor just so you can instantiate a delegate object.