I am familiar with object oriented concepts but have never implemented anything beyond very simple examples. Now I have to rewrite a battery gas gauge application that is heavily tied to a specific gas gauge and specific I2C interface to work with multiple gas gauges and I2C interfaces. The lightbulb in my head flickered on and I thought this would be a perfect place to try out LVOOP.

First question was triggered by a comment from AQ on another thread:


It sounds like my problem is very similar. Currently I have a Battery base class that only has Get/Set property (private data) methods. I plan on having Battery A and Battery B both inherit from this base class. The Battery base class isn't meant to be used directly, so any other methods I implement there are meaningless and must be overriden. I do this by having the base class return errors for any vis that are supposed to be overriden in child classes. Labview doesn't directly support virtual (must inherit) vis so I was wondering if there is an "official NI recommended" way of accomplishing this?

Second question is a little more complicated. I believe I need to create an I2C Interface base class that Interface A (NI 8451) and Interface B will both inherit from. (Similar to the Battery classes.) I spent some time embedding I2C interface information in the battery classes so, for instance, a battery object could read data from the gas gauge, convert it to human readable format, and spit it out for the user. If we were tied to a single I2C iterface I could do that but it gets rather complicated trying to do that with different interfaces. Now, I'm thinking of keeping the Battery classes and Interface classes completely separate and having them interact within the application vi.

For example, suppose the user clicks a button to read a specific register. The battery object would send its I2C address and register location to the interface object, which would do the actual communication with the battery. The interface object returns the data and passes it to the battery object's 'Decode Data' vi, which might convert it to a cluster. (It seems a little odd to have a battery object that can't read it's own information, but what the heck...)

I *think* I'm on the right track but wanted to get some feedback before I invest too much time in this path. There are lots of things I still haven't figured out, like how to deal with the different data types from Battery A and Battery B. Currently my dynamic dispatch vis output variants and I have typedefs in each battery class defining its data. How do I find the class the object is instantiated from at runtime so I can convert the variant into the right data type? I'm also puzzling over how to present the data and options that are specific to each battery to the user. Sub panels?

[Note: It's amazing how much clearer problems become when I spend an hour trying to describe them to others.]

One way I saw at an NIWeek presentation that I liked and copied is to make all the 'virtual' methods raise an error if they are called directly. I can't remember who the presenter was (it was probably 2 years ago) -- the presentation was about processing manure I think -- would like to give credit for the idea.



Check out Tomi's article on LVOOP Plugin architectures -- it shows how to inspect the class for its runtime type.



You could also have a dynamic dispatch VI (a method called 'Battery.ConfigurationDialog' perhaps) that is designed to open its front panel when called and you could basically setup each panel based on the class. Make sure the code to open the front panel is inside the child class implementation and not part of the parent class.

Hi
This is the design your leaning towards:

I would probably use a composite aggregation, which means I would have to solve the creation of the correct I2C object internally in the battery create methods.
Using this way it makes it easier to use the battery class, as you don't have to worry about the communication interface.
Of cause it will be harder to develop the battery class but you top VI will be simpler.
For the I2C communication I would probably not do an active object design to start with, I might use a static attribute in the I2C-Implementation classes which I use to synchronise the read and write to the batteries so I don't run into any race conditions.
Good luck