Hello All,
I haven't seen this discussed within the context of LabVIEW/GOOP circles =
so
I thought that I would plant the seed.
First, please correct me if I make any mistakes, as I'm not an OOP =
expert...
Interfaces are a useful OOP pattern that allows one to implement
multiple-inheritance-like features with a Single-Inheritance framework. =
An
interface is a collection of methods and their signatures (input/output =
data
types). For OpenGOOP we could define an interface as a set of VIs, each
with a specific method name and connector pane interface. An object
implements the interface if it has all the public methods that the =
interface
defines and the connector panes of the required VIs match the interface. =
If
a class uses an interface, it could have the interface set by passing it =
a
reference to an object that implements the interface. There could be a
generic VI called "Object Get Signature.vi" That returns a list of =
public
methods and VI References (Strict VI References that have been Typecast =
to
Generic VI References, allowing them to be stored in an array since
different Strict Refnums are not of the same data type). This allows a
class method that receives an object reference to inspect the object's
interface to see if it implements a specific interface. It then =
populates
its own private data with the VI References of the VIs that implement =
the
interface, typecasting them back to Strict VI Refnums (so that it can =
use
them with Call By Reference - note that this only works if the =
References
were originally opened as strict).
For example, let's define an interface called Driver. Driver consists =
of
three methods: Accelerate, Decelerate, and Turn (we'll not worry about =
their
inputs/outputs, for this example). The Car class needs a Driver. In =
order
to tell the Car who its driver is at run-time, we call "Car Set =
Driver.vi"
passing it a reference to an object that implements the Driver interface
(Again, by "implements the Driver interface" I mean that it has, but is =
not
limited to, methods named Accelerate, Decelerate, and Turn). We could =
then
do interface type checking inside of "Car Set Driver.vi" or wait until =
Car
tries to call the interface VIs and see if an error occurs. The former =
is
better, but might take a little more work to programmatically inspect =
the
interface VI connector panes. Can a set of generic utility VIs be =
created
for interface checking, or any other useful task in this design pattern?
Any thoughts?
-Jim
|
