LabVIEW
OOP: Initializing device communication
@nikvl wrote:I'm really, really new to OOP but want to take the leap to integrating OOP into my programs.
What you're trying to do is starting to look like a HAL.
You might want to get a feel of how OO works out on something easy (and granted, boring).
A HAL in OO can bring anyone to their knees. It's not OO's fault, it is just an open end and not easy at all.
Just a warning; A HAL might not be what you're trying to make, but it sure has similar features.
@nikvl wrote:For now all the communication is serial but I don't know if in the future if other devices might be added, eg. USB
VISA is already OO-ish. Wrapping VISA in a class will very likely become utterly pointless.
VISA can do RS232, USB, TCP\IP, even GPIB and then some...
From experience, this will likely become another disappointing start in OO.
@nikvl wrote:
CommunicationInterface <-- Grandparent class (not to be confused with the OOP interface)
Methods: InitializeCommunication (dynamic dispatch)
CloseCommunication (dynamic dispatch)
- SerialCommunication <--Parent class
Attributes: Baudrate, bits, parity, etc
Methods: GetSerialSettings, WriteSerialSettings (the settings are bundled in a normal cluster)
- Device A <-- Grandchild class
Methods: InitializeCommunication (VI for overriding the grandparent class, reading and writing settings from parent)
So if I have a Device B and C that also uses serial communication, that will be the second grandchild.
Is the above structure suitable?
Probably not.
I'm not sure what this all means.
CommunicationInterface <-- Grandparent class
If you intend to make a Grandparent class, it seems very wrong. But I'm not sure if that's the plan.
Some UML would help.
@nikvl wrote:Both Device A and B have microcontrollers where it should be possible to read and write to its respective EEPROM. Would it be correct to make the EEPROM an Interface, so both can inherit from it?
I don't think so.
A class implements an interface.
Would you say:
Device A implements an EEPROM?
Or
Device A has an EEPROM?
You already said so ("Both Device A and B have microcontrollers where"). So the device parent (if all children have it) or some children (if not all children have it) should probably contain the EEPROM.
But this is all semantics.
You could also say "Device A uses an EEPROM". Then the EEPROM class becomes an input to Device methods.
Indeed, you could say "Device A implements EEPROM". But you didn't.
@nikvl wrote:
But the two EEPROMs are independent of each other (meaning I can read/write different parameters at separate times to either of the microcontollers), so do I make it a separate class instead?
You're mixing up things.
If there are two EEPROMS, you instantiate two objects of the same class. You never ever want to duplicate code. The two objects (instantiations of a class or one of it's children) can live in a array, cluster, map, set, or simply as constants on a diagram or some other class's private data. 1, 2 or any number of them.
Classes are what you make, objects is what the application uses.
Classes are the code and API, objects is the data in your application.
You really, really need to understand well this to succeed.
@nikvl wrote:
But then how do I get both devices to inherit from both Communication and EEPROM other than by making it an LV Interface?
I don't think that's the way to go.
You can make the EEPROM an interface and make Device A and Device B implement that interface.
Keep in mind that the EEPROM interface cannot have any private data!
I'd either make a "has a" or a "uses a" relation.
But you decide. What makes the most sense:
Device A is an EEPROM (inheritance; you ruled this out)
Device A implements an EEPROM (interface; a more complicated is a relation)
Device A has an EEPROM (containment; object lives in private data of class or parent)
Device A uses an EEPROM (dependency; input to methods)
All can be made, but the interface would be hard even for an experienced programmer.
@nikvl wrote:Secondly, if I know Device A should always be initialized first, and then only B or C (the user has to choose), do I still put all the VIs for override in an array to the grandparent dynamic dispatched vi in the main program? Or do I set Device A specifically for the first Initalize and then an array of B and C for a second Initalize?
If the objects are in an array, and A is first, and you execute the init in a for loop, you know A initializes first.
Nothing wrong with that.
It seems odd to have a scalar device (A) and an array of devices (B and C). You should think "lazy" (really: the least amount of work in the long run, aka efficient) and imagine the work both ways imply.
A scalar and array would mean duplicate code for every method. Once on A, once in a for loop.
Of course you can init A, then B, then C, then build an array. But you'd still be making more code then needed. Sometimes things need to be like that, for instance if A, B and C are different classes (childs of the same parent) and the init isn't dynamic dispatch. The static inits can have a different connector pane, and you can't call it in a for loop.
Hope it helps. It's worth the initial struggle.
Search LabVIEW like a graph! 