RE: [opengoop] Interfaces

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

Here's an thought...

Could we define an interface (recursively) as being a cluster of interfaces
and strict VI refnums, we could apply the inheritance cluster scheme of
using the parents' interface clusters as the first elements of the child's
interface cluster.  A class could have in its data store an "interfaces"
cluster containing the interfaces that it implements.

Should an interface data structure be strictly typed or more flexible so
that generic utilities can operate on it?

-Jim


> -----Original Message-----
> From: Jim Kring [mailto:ji...@ji...] 
> Sent: Saturday, October 18, 2003 5:04 PM
> To: 'ope...@li...'
> Subject: [opengoop] Interfaces
> 
> 
> 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
>