[opengoop] Interfaces

[Jim K. <ji...@ji...>]

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