Not Making Best use of LV OOPS Dynamic Dispatch concept

[Voyager7277]

Hello,

I am working on a project, which is simple driver development (HAL )for LIN communication. I have 2 different hardwares. 1. PLIN 2. NI XNET USB LIN device.

thinking of HAL, I chose to make driver lib using OOPs concept. But I believe am not making best of dynamic Dispatch concepts. Here are my queries:

1. I have created a Generic LIN.lvclass which is an Interface.(abstract)

2. Created 4 abstract methods Vis 1. Initialize 2. Send LIN cmd 3. Read Response 4.Close.

3. These above 4 methods will get override by both PLIN and NI XNET LIN child classes.

4. Both PLIN and NI XNET has different set of VIs.. 

So, I was facing an issue of mismatch of connector panes, for eg. Read Response.vi implementation (override by) PLIN and XNET will be different... and definitely, this will conflict with base class .i,e Generic LIN  interface.

So, How should I avoid this situation of conflicting connector pane whenever i override a method from Genric class to child classes having different input/output controls and indicator? Where am going wrong with the concept of dynamic dispatch?

So far, I have added PLIN related data in PLIN.ctl class control and XNET related data in XNET child class control. I still exploring OOPS in LabVIEW, basically want to adapt a skill like thinking in OOPS way...So that i make best use of OOPS concept.

snip for reference. Here, I know I can't override Read Response.vi from Generic class to XNET child class.. because of connector pane mismatch.

LVOOPSTo avoid connector pane conflict, I have added PLIN HW class data in PLIN.ctl and Same for XNET child class.

[tyk007]

The point of dynamic dispatch (and polymorphism) is that two objects can be treated the same in terms of their contract (ie. methods, simply put). This means the caller of those methods doesn't need to care which object it is - only that the contract is the same. This is useful for the purposes of extending behaviour for the caller without chaning that contract.

I can't really help you with regards to the details of LIN or XNET (not my area of expertise) but I can say that if your connector panes are different, then this is a big flag that the two objects can't really be treated the same by whomever uses them and perhaps polymorphism isn't the approach you want.

• You could try and generalize the method parameters for DD methods. This has a disadvantage that the caller may still need per-class specific logic for interpretation.
• If you are attempting to share common private logic or shared data, consider using composition instead or push that to the base class. 

[wiebe@CARYA]

You can avoid this problem by making each child return the same data type.

This data type can be either a variant (or string), or a data class. The data class can have different children for different data types.

However, at some point you do need to cast to specific data types, or make the data classes return a variant (or string), or log itself to file, or whatever.

[Mark_Yedinak]

I generally make the communication interface itself a glass that you pass in. This can be initialized outside of the class to handle the different interface types. Generalize the input and output data as much as possible Consider functionally what is being done and don't focus on the specific devices themselves. If you can get the majority of that defined in a common manner for your device types your dynamic dispatch will fall into place. Sometimes this may mean that you will lose small bits of functionality because it isn't supported by all of your specific devices. The children class can still implement the specialized method but it will not be supported by dynamic dispatch. If this is supported by most of the devices types you will use then it can be defined in the parent and the default method is a no-op. You would need to handle this gracefully so it doesn't cause an issue in your application.