Array of child class in private data of parent class

[natasftw]

---

@kaba2005 wrote:

Unfortunately the most LabVIEW Programmer are not familiar with OOP.  

---

What?  They don't enable you to make poor choices so they aren't familiar with the idea?

The strongest benefit of OOP is the ability to abstract things and decouple.  You can make some pretty amazing modular designs.

Here you are... breaking all of that by making a parent reliant upon children (making updating it later to add things a nightmare) and complaining that someone else doesn't understand OOP?  You'll probably gain more long-term by taking a step back to understand WHY that's a restriction rather than blasting other programmers for not enabling you.

[drjdpowell]

Note: the usual way to have a class contain itself is to have it contain a parent class and add child objects at runtime.  So the way to have a Device that is composed of multiple devices is to create a CompoundDevice child class that has an array of Devices.  At runtime, CompoudDevice can hold any Device subclass, including other CompoundDevices.

[PaulOfElora]

If I could ask a related question: I have multiple interface children (specific communication interfaces, each with their own unique data like addresses, connection ID's, etc.) and I have multiple hardware objects that each "Has A" (or "Uses A"?) particular interface child object "mapped" to it.  That is, each HW object is required to use "its own" unique child interface.  I guess 'Composition' ("Has A") as they say in LVOOPland is appropriate - dropping an Interface class object into the HW objects data cluster, to be specific.

So this "mapping" business happens via ini configuration files, in my nefarious scheme - "this HW object uses that interface child", etc.).  So I run DD methods to load the specific parameters from files for each required interface child.  BUT - here's where I'm foggy - how should one then "place" each interface child with the appropriate "using" HW object?  Kinda like, in these pandemic days, when I go to a curbside pickup for my order, I give them my "Name", they do a search for my "Name" and it "maps" to my specific "Order".

Making any sense at all?

[cbutcher]

Maybe I completely misunderstood (sorry - the analogy didn't help me) but I think this might help you: Get LV Class Default Value. 

There's also one that loads by name instead of path if your class (child that you want to load) is already in memory.

[PaulOfElora]

Ohhhhh and another few million neurons light up!  I saw that used in the "standard" LV Factory pattern, but I misunderstood what was doing... thanks CButcher!

[PaulOfElora]

Whoa, wait a minute.  A dimly formed notion is swirling about in the fog.  If, say, a Motor object "Has A" MotionController object, which in turn "Has A" communications interface (LVOOP-speak for "Composition" relationships), then once I load the appropriate CommI-F object into the appropriate MotionController object's data, then load that MotionController object into the Motor object's data - from then on there's no need for any fancy-pants "mapping" scheme.  They all "belong to each other", and henceforth I can handle the right Motor objects with the right data and the right methods, whether they be steppers, servos, reversible AC, etc. etc. or whether it's stepper motor 7 or 27.  Does this sound like I'm heading down a path towards mental health, or is it just a delusional fantasy?

[cbutcher]

---

@PaulOfElora wrote:

Whoa, wait a minute.  A dimly formed notion is swirling about in the fog.  If, say, a Motor object "Has A" MotionController object, which in turn "Has A" communications interface (LVOOP-speak for "Composition" relationships), then once I load the appropriate CommI-F object into the appropriate MotionController object's data, then load that MotionController object into the Motor object's data - from then on there's no need for any fancy-pants "mapping" scheme.  They all "belong to each other", and henceforth I can handle the right Motor objects with the right data and the right methods, whether they be steppers, servos, reversible AC, etc. etc. or whether it's stepper motor 7 or 27.  Does this sound like I'm heading down a path towards mental health, or is it just a delusional fantasy?

---

I suspect that although the sanity will depend on your implementation, this isn't a pipe-dream - it's the factory pattern you mentioned and it doesn't seem like you're miles away from the working mental model.

Generally you want your class (e.g. MotionController.lvclass) to have a private data member for the interface of the object it should have (CommInterface-Abstract.lvclass, or CommI-I.lvclass, maybe your F has this meaning?) but then you (during initialization of your MotionController object (note object != class)) use Get LV Class Default Value with the path to CommInterface-MyConcreteChildClass.lvclass.

This returns a LabVIEW Object, which is largely useless to you, except that you can pass it to "To More Specific Class" with the target/reference type being CommInterface-Abstract.lvclass (i.e. the parent of CommInterface-MyConcreteChildClass.lvclass, and the specific type that is stored in the MotionController.lvclass:MotionController.ctl private data). Then you bundle this and happily use it.

The wire type for your bundled object will be the parent interface, but the object type will be the specific child. This then uses Dynamic Dispatch VIs to implement specific functionality.

Note that if you don't care for an abstract "interface-like" class, you can do it with just one class, but this doesn't give dynamic dispatch or variable behaviour - so you might as well just use the specific class constant in that case! If you're going to the trouble of using a Factory pattern, you probably want something with "plugin-like" functionality as described above.

[PaulOfElora]

Excellent explanation CButcher, thanks! With your help I think I can design something that may be actually decent! paul

[jobaker]

How about this? Put the array above the parent class.

[Intaris]

I haven't noticed thios thread before, and ignoring the freshly re-animated corpse of a thread I offer the following:

What I think the OP is looking for is the "Composite Pattern".

There is Inggeitance, and there is composition, people get this.

But if you do Inheritance and COmposition in a certain way, you get "Composite Pattern" which can be really useful. I've used this in the past. The clue is placing the "composition" at a level allowing the groups of objects and the individual objecty to be treated as equivalent. Everything else is handled internally.

"Composite Pattern" is not simply "Composition". It relies on aspects of Inheritance AND Composition to give a very specific use case.