Provide a way to initialize the value on a parent wire with data from many different child classes based on some input value, such as a selector ring value, enum, or string input. This may include dynamically loading new child classes into memory. Ideally new child classes can be created and used without editing the framework.
Motivation Data comes from many sources – user interface, network connection, hardware – in a raw form. This data frequently comes in types, and the data is to be handled generically but each type has a specific behavior at the core of the handling. Such a problem cries out for the use of classes and dynamic dispatching. We want to write an algorithm around some common parent type and then let dynamic dispatching choose the correct subVI implementation for the parts of the algorithm that are type specific. The hard part is in initializing the right class from the input data.
Any application using LabVIEW classes generally has a framework that is written using the parent class, and then at run time, child classes travel on the wires through the framework. This pattern provides a mechanism for dynamically selecting the child classes, including dynamically loading them into memory after the program starts running, if necessary.
The basic idea is this: Use some bit of data to identify the path to the class you are interested in loading. Use the Get LV Class Default Instance.vi function to load the class into memory and get an instance of that class.
Once you have used the factory to get a particular class of data, you are free to use it as you would any other class. Commonly, you would wire the chosen class instance to an Init method of the class which would take your data as an input. The advantage of this system is that the child class is only loaded into memory if someone actually wants to instantiate that child. If you have a great many possible types of data, this can save on memory and load time for your application. The name of this pattern comes from the fact that a single VI serves as a factory to produce all the myriad child types.
Once loaded into memory, a class will stay in memory as long as its parent class is running or there are any objects of that class type still in memory. Since objects can lurk all over the place – as the operate value of controls and indicators, as the last value in an uninitialized shift register, etc – it is basically impossible to dynamically unload a class once it is loaded. You should not attempt any architecture that is predicated on being able to unload and reload a class.
[Stephen Mercer] An example of this pattern was made available by Christina Rogers in her refactoring of the Getting Started Window in the Init From XML methods. Information about this example is available here:
Note that her example predates the introduction of Get LV Class Default Instance.vi. She used a method for loading classes into memory that works fine, but only works in the development environment, not in the runtime engine.