LabVIEW
Array of child class in private data of parent class
@kaba2005 wrote:
As I want to use multiple DMM in real world, I would have to put an array of DMM.lvclass in my Parents class private data (Measurement Device).
Why? I don't follow that logic. Your parent class is to represent only a single device.
Nothing says you cannot have multiple instances (objects) of the Measurement Device class. You can easily store each object in an array, cluster, variant attribute, etc. You just use whatever you need to get the exact instance you need (index, unbundle, get attribute, etc).
Hi,
you're right. The parent class represents just a single device. The DMM was just an example. In my case classes an source code still exists and works fine. I want to add our own Measurement rig (19" case design backplane and multiple cards for different signals like SENT, PSI5, PWM, ...).
So, multiple objects of the Measurement Device.class is not a solution, because the main source code has to be modified to e.g. read multiple devices.
Anyway, I found the answer: You can not define classes in Labview recursively! Maybe it is possible to define the reference to an object in the private data...
Unfortunately the most LabVIEW Programmer are not familiar with OOP. 
Thank you guys!
Regards
KB
I'm with the above posters: you can certainly consider an architecture with multiple measurement devices in an array.
It sounds like what you want is a class like "Measurement Rig", for which you instantiate a single object, and that this object has some knowledge about a range of different devices that it contains (DMMs, Power supplies, etc).
In this case, the key point would be that a "DMM" or a "Measurement Device" is not a "Measurement Rig", whilst you could reasonably claim that a "DMM" is a "Measurement Device". So by having a Measurement Rig contain an array of Measurement Devices, which do not inherit from Measurement Rig, you avoid "recursive" definition of classes (I'm not sure this really is recursion so much as a cycle of references, but anyway...) and have a simplish structure that represents your setup.
Since LabVIEW has only the equivalent of public, single inheritance, you always want a child to satisfy the '<child> is a <parent>' relationship.
How would such a structure look in UML? It sounds like a circular reference to me.
Usually an object knows nothing of the other objects unless it's an owner or manager, and a single instrument is neither. If you really want to break the isolation principle of OOP you can have a named Queue of base objects in the top class and add to the queue in a child Create function. Since it's named it'll be the same queue for all objects and they can all know of each other.
As mentioned the normal solution is to have an InstrumentManager/Container which knows of all instruments.
/Y
@Ben wrote:
Inheritance - Is a kind of
Composition - is composed of
I'm not a fan of circular definitions. The more common terminology is:
Inheritance = is a (ex: a dog is a mammal)
Composition = has a (ex: a dog has a tail)
So what the OP is proposing is a DMM has a DMM. Nope, that makes no sense to me.
