Factory pattern
Factory pattern is a basic design pattern in object-oriented programming that provides a way to initialize a parent object with data from different child classes based on some input value, such as an enum or string value. This may include dynamically loading new child classes into memory at runtime. A factory method or function creates different objects without exposing the instantiation logic to the client. The client then refers to the newly created object through a common interface that is provided by the parent class.
This pattern is generally used in applications that have a plug-in component, or some functionality that needs to be loaded dynamically at runtime. It requires the definition of a generic parent class, which encapsulates functionality that can be reused and extended by child classes.
Contents
Loading new child classes into memory at runtime
Some factory methods or functions utilize Get LV Class Default Value to dynamically load a child class into memory at runtime. This is done by providing the absolute path to a child class to Get LV Class Default Value, which will load the class into memory and return an object of that class as a generic LabVIEW object. This generic object can then be cast into the more specific parent class.
The error output of To More Specific Class is used to determine if the newly created object is a child of the parent class. Additional error handlers are often necessary to report broken or missing child classes to the client.
Distributing child classes
Child classes can be distributed as part of the application executable, as source files, or as separate libraries, such as a LabVIEW Library, LabVIEW Project Library, or Packed Project Library. If child classes are dynamically loaded from disk, it is also possible to add new child classes to an existing application without rebuilding the executable. In this case child classes must include all of their dependencies. This can result in a large number of files for each child class, in which case a LabVIEW Library or Packed Project Library can be used to store these files in a single container file.
Distributing child classes as part of the application
Child classes can be distributed with the application executable by including every child class in the Always Included section on the Source Files page of the build specification and by setting the Destination for each child class on the Source File Settings page.
Distributing child classes as separate libraries
Child classes can be distributed separately from the main application by placing source files or class libraries, such as a LabVIEW Library, LabVIEW Project Library, or Packed Project Library, into a pre-defined location that is used by the factory to create new objects. The benefit of this is the ability to dynamically add features after the application has been delivered and the ability for other developers to add more child classes to an application without having to rebuild the executable.
Best practice
- Child classes should be placed in a dedicated directory next to the application executable.
- Child classes should be distributed as LabVIEW Libraries, LabVIEW Project Libraries, or Packed Project Libraries.