(Similar title here. Different concept.)
Many OO languages provide an Interface construct that allows objects in unrelated class hierarchies to expose similar functionality that can be called via common methods. For example, a Car class and a Race class might both implement a Start method. Unless their common ancestor has a Start method (which may not be practical) there's no way for me to take advantage of dynamic dispatching. Interfaces allow an object to temporarily disguise itself as a different object so I can use a single vi on multiple objects.
Using the Car/Race example, I would like to be able to create an IStartable interface construct that defines a Start method. Car and Race, in implementing IStartable, create their own Start methods that will override IStartable.Start. I could then transform the Car and Race objects into an IStartable type and wire that into IStartable.Start. IStartable.Start would then automatically transform each object back into its original type and call its member Start vi.
A couple points:
- Classes need to be able to implement multiple interfaces.
- There needs to be a way for class designers to indicate which interfaces it implements. Setting that up in the class property dialog box seems like the best solution.
- There also needs to be a way for class designers to designate which member vis to use when overriding an Interface method. I can't think of a good way to do this in the vi itself, so I'd also manage these settings in the class properties dialog.
- The illustration uses a Type Cast prim even though the actual type is not being changed. It would need a new prim.
- I've toyed with the idea of hiding interfaces on the bd by having an 'Invoke Interface Method' node that would automatically do the transformation and call back into the class' overriding method, but I think that restricts developers too much.
Available in LabVIEW 2020 and later.